MySQL 8 MHA and ProxySQL on RockyLinux 8 - 4번째 글

Last Updated on 6월 25, 2024 by Jade(정현호)

안녕하세요. 
이번 글은 RockyLinux8 환경에서 MySQL 8버전을 사용하면서 MHA(Master High Availability) 구성 및 설정하는 내용 그리고 VIP 대신 ProxySQL 을 사용하는 구성으로 내용이 설명되어 있습니다.

MHA + MySQL 글의 4번째 글이며, MHA+ProxySQL 구성에 관한 내용의 첫 번째 글입니다.       

MHA 개요

MHA 는 Master High Availability 약자로 소스(Master, Source) 인스턴스의 고가용성을 위해 Yoshinori Matsunobu(현 Facebook)에 의해 개발되었으며 GPL v2 라이센스 기반의 오픈소스입니다.

MHA에 의해서 장애 발생시 자동 Fail-Over(Master 승격)를 지원하고 리플리카 인스턴스 중 가장 최신의 리플리카 인스턴스를 소스 인스턴스로 승격시켜 고가용성을 유지시키는 역할을 하게 됩니다.

MHA(Master High Availability) 개요 및 상세한 기본 정보는 이전 포스팅을 참조하시면 됩니다.

MySQL MHA(Master High Availability) 1 - MHA 기능 설명 및 아키텍처 설명

MySQL HA솔루션인 MHA에 관한 내용으로 MHA 기능 설명 및 아키텍처에 대한 설명을 합니다.

이번 글에서는 MHA 자체에 대한 개요 및 기본 기능 소개는 이전 포스팅에서 대신하고 바로 설정 및 구성에 대한 내용을 진행하도록 하겠습니다.
         

구성 환경

포스팅에서 사용하는 구성 환경 정보는 다음과 같습니다.

• OS : RockyLinux 8.8(x86_64)
• MySQL 버전 : 8.0.34
    경로: /usr/local/mysql
• MHA : 0.58(+over)
• ProxySQL : proxysql-2.5.5-1
    VIP 대신 ProxySQL을 사용하여 Read Write Split으로 사용
• IP 설정 내역
   Server1 - 192.168.56.63 / Hostname: mha1
   Server2 - 192.168.56.64 / Hostname: mha2
   Server3 - 192.168.56.65 / Hostname: mha3
   MHA Manager - 192.168.56.62
• 사용 OS 유저명 : mysql
• cnf 설정 파일
     /home/mysql/mha/etc/app1.cnf 
• 매니저 및 Remote 서버 정보, 로그 디렉토리
    /home/mysql/mha/app1


[참고1] 글에서 Master(마스터) , Primary(프라이머리) 서버(또는 노드)에 대해서 소스 인스턴스(또는 DB) 로 표현하고 있으며, Slave(슬레이브), Secondary는 리플리카 인스턴스(DB)로 표현하고 있습니다.

[참고2] 이전 MySQL 5.7버전 기반의 MHA 포스팅글과 동일(유사)한 내용이 있을 수 있어서 일부 내용은 기존 글의 링크로 대체하였습니다.

MySQL MHA(Master High Availability) 2 - 설치 및 구성

안녕하세요 이번 포스팅은 MySQL 의 고가용성 솔루션인 MHA에 대한 설치 및 구성 그리고 사용에 관한 두 번째 포스팅 글입니다.

사전 환경 구성

MHA 를 설치 및 구성하기 전에 OS 및 DB에 대해서 사전 환경 구성을 진행하도록 하겠습니다.

DB 기본 구성 및 복제 설정

MHA 포스팅 1편 에서 설명 드린 것처럼 데이터에 손실 방지나 최소화하기 위해서는 Semi Sync(Lossless Replication) 이 권장되고 있습니다.

Semi Sync Replication 은 아래 포스팅을 참조하시면 됩니다.

MySQL Replication(복제) 구성 및 설정 - Semi Sync - after_sync/after_commit

Semi-sync Replication 은 MySQL 5.5 버전에서 도입된 Sync 형태의 복제 방식입니다. 전달 방식에 따라서 after_commit(ver 5.5) 과 after_sync(ver 5.7.2) 방식으로 나눠지게 됩니다.

자세한 내용은 아래 포스팅을 참고하시면 됩니다.

• MySQL 복제구성 - Async 구성 및 Semi Sync
• MySQL 복제구성 - Semi-sync 구성 및 설정

MySQL 설정 변경 - my.cnf 수정

다음은 MySQL 복제 구성과 MHA 설정에 필요한 파라미터에 대한 기본 파라미터 내역입니다.
포스팅에서는 소스 인스턴스 1대, 리플리카 인스턴스 2대 구성입니다.

# Server 1
[mysqld]
server-id=8943453
    # -> server-id는 master와 slave가 달라야 합니다
### Replication
log-bin=/usr/local/mysql/data/binlog
    # -> Binlog의 파일명을 기재합니다.
sync_binlog=1
binlog_cache_size=2M
max_binlog_size=512M
binlog_expire_logs_seconds=2592000
log_bin_trust_function_creators=ON
report_host=mha1
    # -> 각 DB의 호스트네임으로 show slave hosts 에서 정보로 활용(필수 파라미터는 아님)
relay_log_purge=OFF
binlog_format=ROW
log_slave_updates=ON
read_only=ON


# Server 2
[mysqld]
server-id=45673453
    # -> server-id는 master와 slave가 달라야 합니다     
### Replication Option
log-bin=/usr/local/mysql/data/binlog
    # -> Binlog의 파일명을 기재합니다.
sync_binlog=1
binlog_cache_size=2M
max_binlog_size=512M
binlog_expire_logs_seconds=2592000
log_bin_trust_function_creators=ON
report_host=mha2
    # -> 각 DB의 호스트네임으로 show slave hosts 에서 정보로 활용(필수 파라미터는 아님)
relay_log_purge=OFF
binlog_format=ROW
log_slave_updates=ON
read_only=ON


# Server 3
[mysqld]
server-id=3657657
    # -> server-id는 복제 환경내에서 겹치면 안 됩니다.
### Replication Option
log-bin=/usr/local/mysql/data/binlog
    # -> Binlog의 파일명을 기재합니다.
binlog_cache_size=2M
max_binlog_size=512M
binlog_expire_logs_seconds=2592000
log_bin_trust_function_creators=ON
report_host=mha3
    # -> 각 DB의 호스트네임으로 show slave hosts 에서 정보로 활용(필수 파라미터는 아님)
relay_log_purge=OFF
binlog_format=ROW
log_slave_updates=ON
read_only=ON


# 으로 된 설명(주석) 은 복사에서 제외하고 사용하시면 됩니다.

• 설정한 파라미터에 따라서 DB 인스턴스 재시작이 필요할 수도 있습니다.
• 후술할 ProxySQL과 연관되어 모든 인스턴스 my.cnf 파일에 read_only=on 으로 활성화가 설정되어 있습니다. 해당 부분은 운영 정책이나 환경에 따라 달라집니다.
• MHA 에서는 relay_log_purge 기능 비활성화(0,off,false) 이 권장이며, fail-over 나 switch-over 시 relay log의 purge가 수행됩니다. 그 외 별도로 purge 가 필요한 경우 MHA 내에 제공되는 스크립트를 통해서 수행할 수 있습니다. 해당 내용은 다음 챕터에서 다루고 있습니다.
• 위의 내용은 MySQL 설정에서 일부분 내용만 나타내고 있습니다.
• 위의 설정에서의 server-id 나 수치는 예시 임으로 사용하는 환경에 맞춰서 설정합니다.

복제 설정

복제 설정하기전에 복제 계정이 필요 합니다. 생성되어 있지 않다면 다음과 같이 생성합니다.
(계정명과 비밀번호는 예시입니다.)

mysql> create user 'repl'@'%' identified by 'repl';
mysql> grant replication slave,replication client on *.* to 'repl'@'%';

리플리카 인스턴스에서 복제를 설정하기 위해서 소스 인스턴스에서 binlog 파일 정보와 log pos 정보를 확인합니다.

mysql> show master statusG
*************************** 1. row ***************************
File: binlog.000020
Position: 154
Binlog_Do_DB: 
Binlog_Ignore_DB: 
Executed_Gtid_Set: 

• 리플리카 인스턴스에서 Replication 설정 및 시작

mysql> change replication source to source_host='mha1', source_port=3306,
source_user='repl',source_password='repl',
source_log_file='binlog.000008',source_log_pos=851;

mysql> start replica;

mysql> show replica statusG

* 복제 유저명 repl 계정명은 예시입니다.

• 소스 인스턴스에서 조회

mysql> show slave hostsG
*************************** 1. row ***************************
Server_id: 35675434
Host: mha3
Port: 3306
Master_id: 1
Slave_UUID: 706aaace-11d5-11eb-8127-0800279c8b61
*************************** 2. row ***************************
Server_id: 4564234
Host: mha2
Port: 3306
Master_id: 1
Slave_UUID: 6e5b28b4-3666-11eb-a44f-080027bf7f98

소스 및 리플리카 인스턴스 모두 MySQL 설치 직후 복제를 구성하는 예시임으로 소스 인스턴스로 부터 초기데이터를 로드하지 않았지만, 실제 계속 사용중인 DB환경이라면 소스 인스턴스에서 mysqldump 등을 통해 초기 데이터 복제와 소스 인스턴스의 binlog 파일 정보 등을 확인 해야합니다.

MHA 전용 DB 계정 생성

MHA 매니저 서버에서는 소스, 리플리카 인스턴스 모든 DB에 접속할 수 있어야 합니다.

기본적으로 MySQL의 관리 계정인 root 유저를 사용하며, 별도의 계정 생성 및 권한 부여를 하여 사용할 수도 있습니다.

포스팅에서는 별도로 계정을 생성하여 진행하였으며, 기본 관리자 계정인 root 계정을 사용해도 됩니다.

생성된 계정을 통해서 STOP REPLICA, CHANGE MASTER(CHANGE REPLICATION SOURCE), RESET REPLICA와 같은 필요한 모든 관리 명령을 실행하게 되며 그에 따라서 관리자 권한이 필요 합니다.

• 계정 생성

mysql> CREATE USER mha@'%' IDENTIFIED BY 'mha';
mysql> GRANT ALL PRIVILEGES ON *.* TO mha@'%';

* 계정명과 비밀번호는 예시입니다.
* mysql 스키마를 포함한 전체 복제 구성이라면 소스 인스턴스에서 계정 생성시 리플리카 인스턴스에서도 동일하게 생성됩니다.
* mysql 스키마를 복제에서 제외하였다면 리플리카 인스턴스에서 별도로 계정을 생성합니다.
            

SSH 키 생성/인증 설정

MHA로 관리되는 모든 서버에는 SSH를 통해서 접속할 수 있어야 하며, MHA 매니저 서버에서 소스 인스턴스 서버, 리플리카 인스턴스 서버에 비밀번호 입력 필요 없이 접속 가능한 환경이 구성되어 있어야 합니다.

포스팅에서는 해당 계정을 MySQL 인스턴스가 사용하는 mysql 계정을 같이 사용하였습니다. MHA를 위한 별도의 OS 계정을 생성하여 사용해도 됩니다.

모든 서버에서 SSH 키 생성

매니저 서버 및 MySQL 인스턴스 서버에서 다음과 같이 ssh키를 생성합니다.

• 키 생성

[mysql]$ ssh-keygen -t rsa -b 4096

Generating public/private rsa key pair.
Enter file in which to save the key (/mysql/.ssh/id_rsa): [엔터] <!--
Enter passphrase (empty for no passphrase): [엔터] <!--
Enter same passphrase again: [엔터] <!--
Your identification has been saved in /mysql/.ssh/id_rsa.
Your public key has been saved in /mysql/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:8//1111111111111 mysql@mha1
The key's randomart image is:
+---[RSA 4096]----+
|   . .oooooooooo+|
|  . . oooooo    o|
|   . ooo000000.+o|
|  . .. .    ..*..|
|   E.000000000o. |
|     0000000000. |
|      . . o  ..  |
|           .  .. |
|            .o.o+|
+----[SHA256]-----+

공개키 전송(Copy)

생성한 SSH키 중에서 공개키를 각 서버로 전송합니다.

• 매니저 서버에서 -> 1,2,3 번 서버로
• 1번 서버에서 -> 2,3번 서버로
• 2번 서버에서 -> 1,3번 서버로
• 3번 서버에서 -> 1,2번 서버로

• 키 전송 예시

매니저 서버-> 1번 서버로 공개키 복사

$ ssh-copy-id -i mha1

mysql@mha1's password: [패스워드입력]

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'acs'"
and check to make sure that only the key(s) you wanted were added.

전송이 완료되었다면 패스워드 없이 접속이 되는지 확인합니다.

[mysql]$ ssh mha1 date
Sun Oct 22 16:59:04 KST 2023

위와 같은 방법으로 공개키를 다른 서버 모두 복사(전송)합니다.
        

MHA 구성

포스팅에서는 MHA은 Node 설치 후 Manager 순으로 설치를 하겠습니다.

MHA Node 설치

설치를 진행하기전에 필요한 사전 OS 패키지를 설치하도록 하겠습니다.

OS 패키지 설치

Manager 서버 및 MySQL 서버 모두에서 공통으로 설치를 합니다.

[root]# dnf config-manager --set-enabled powertools

[root]# dnf install git perl-DBD-MySQL 
perl-Config-Tiny perl-Log-Dispatch 
perl-Parallel-ForkManager perl-Class-Load 
perl-Time-HiRes perl-CPAN perl-Module-Install

그 외 서버 설정에 따라서 방화벽(firewalld) 에서의 MySQL 포트 오픈이나 SELinux 비활화성등은 환경에 따라서 진행을 합니다.

MHA Node는 매니저 서버 와 소스 서버와 리플리카 서버 모두에서 설치합니다.

파일 다운로드 

Node의 github내 소스에서 fix 사항이 추가로 반영된 부분이 있어서 포스팅에서는 Node와 Manager 모두 git 으로 직접 다운받아서 진행하였습니다.

[root]# mkdir -p /root/pkg
[root]# cd /root/pkg
* 경로는 임의의 경로입니다.

[root]# git clone https://github.com/yoshinorim/mha4mysql-node.git

설치

[root]# cd mha4mysql-node

[root]# perl Makefile.PL
[root]# make; make install

MHA Manager 설치

MHA Manager 는 매니저 서버에만 설치합니다.
설치는 root 유저로 진행하였습니다.

파일 다운로드

[root]# mkdir -p /root/pkg
[root]# cd /root/pkg
[root]# git clone https://github.com/yoshinorim/mha4mysql-manager.git

설치

[root]# cd mha4mysql-manager
[root]# perl Makefile.PL
[root]# make;make install

설치 후속 작업

설치 후에 몇 가지 후속 작업을 진행하도록 하겠습니다.

심볼릭 링크 생성

매니저 서버를 제외하고, 소스와 리플리카 서버에서 다음과 같이 심볼릭 링크를 설정합니다.

mysql 와 mysqlbinlog 파일이 다음 경로에 없다면 root 유저로 심볼릭 링크를 생성합니다.

MHA에서 mysql을 찾는 기본 경로는 /usr/bin/mysql 이고 여기에 없으면 /usr/local/bin/mysql 를 사용합니다.

RPM과 같은 패키지로 mysql 관련 패키지가 설치되어있을 경우 /usr/bin/mysql 바이너리 버전이 낮거나 다른 이유로 변경하고자 한다면 해당 패키지를 삭제 후 사용하는 바이너리로 심볼릭 링크를 설정합니다.

/usr/bin/mysql 바이너리 버전이 사용중인 DB버전과 버전 차이가 크지 않거나 그대로 사용하고자 한다면 mysql 바이너리 교체나 심볼릭 링크 설정은 생략해도 됩니다.

mysqlbinlog 바이너리도 /usr/bin/mysqlbinlog 로 심볼릭 링크를 설정합니다.

•생성

[root]# ln -s /usr/local/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
[root]# ln -s /usr/local/mysql/bin/mysql /usr/bin/mysql
또는
[root]# ln -s /usr/local/mysql/bin/mysql /usr/local/bin/mysql

MHA 관련 디렉토리 생성

포스팅에서는 MHA에 대한 실행과 cnf 파일, 로그 기록 등을 "mysql" OS 유저로 사용하였습니다.
(MHA 별도 OS 유저 생성하지 않음)

• 매니저 서버에서만 수행

[root]# mkdir -p /home/mysql/mha/etc
[root]# mkdir -p /home/mysql//mha/scripts

[root]# cd /root/pkg/mha4mysql-manager
* 경로는 manager 설치 경로로 설치하는 환경에 따라서 다릅니다.

[root]# cp conf/* /home/mysql/mha/etc
[root]# cp scripts/* /home/mysql/mha/scripts/
[root]# mkdir -p /home/mysql/mha/app1

[root]# chown -R mysql:mysql /home/mysql/mha

• 매니저, 소스, 리플리카에서 수행

모든 서버에서 수행합니다.

[root]# mkdir -p /home/mysql/mha/app1
[root]# chown -R mha:mysql /home/mysql/mha

MHA 설정

MHA 매니저 서버에서 모니터링 하고 장애 조치가 되는 MySQL의 Replication Group(Set)은 다음의 이미지와 같이 1개 이상이 될 수도 있습니다.

/home/mha/etc/masterha_default.cnf 파일은 공통 설정(기본 설정 파일) 파일로 여러 그룹이 공통적으로 사용할 수 있습니다.

예를 들어 계정정보(아이디/패스워드)나 로그와 같은 디렉토리 경로가 같다면 /home/mha/etc/masterha_default.cnf 파일에 설정하면 중복되는 내용을 줄일 수 있습니다.
또는 기본 설정 파일로 사용할 수 있습니다.

포스팅에는 app1.conf 를 별도로 만들어서 사용하도록 하겠습니다.

파일명 : /home/mha/etc/app1.cnf

매니저서버에서 cnf 파일 설정(app1.cnf)

[root]# su - mysql

[mysql]# cd /home/mha/etc/
[mysql]# cp app1.cnf app1.cnf.ori

[mysql]# vi app1.cnf

[server default]
# user&password is DB User
user=mha
password=mha
# ssh_user is OS User
ssh_user=mysql
# repl_user&repl_password is DB User
repl_user=repl
repl_password=repl
manager_workdir=/home/mysql/mha/app1
manager_log=/home/mysql/mha/app1/app1_manager.log

remote_workdir=/home/mysql/mha/app1
master_binlog_dir=/usr/local/mysql/data

secondary_check_script=/usr/local/bin/masterha_secondary_check -s mha2 -s mha3 --user=mysql --master_host=mha1 --master_ip=mha1 --master_port=3306
# --user=mysql is os ssh user

[server1]
hostname=mha1
candidate_master=1

[server2]
hostname=mha2
candidate_master=1

[server3]
hostname=mha3
candidate_master=1

master_binlog_dir=/usr/local/mysql/data 는 사용중인 환경에 맞게 binlog 파일이 있는 경로를 입력해 줍니다.

이전 MySQL 5.7 / MHA 포스팅 글에서는 VIP를 사용하여 진행하였습니다.

이번 포스팅에서는 VIP를 사용하지 않음으로 VIP사용에 관한 구성이나 변경을 진행하지 않았습니다.

VIP사용에 대한 정보가 필요하다면 이전 포스팅을 참조하시면 됩니다.

MySQL MHA(Master High Availability) 3 - VIP 설정 - MHA 모니터링 - Takeover - Failover

이번 포스팅은 MHA 설치 및 구성이 완료된 이후 VIP스크립트 생성 및 설정, MHA 모니터링, Takeover 및 장애에 대한 Failover 등을 확인해 보도록 하겠습니다.

MHA 시작 및 모니터링

여기까지 설치 및 설정 완료하였다면 MHA 매니저 시작 그리고 모니터링 및 여러 가지 체크 기능을 사용할 수 있는 단계까지 진행된 상태입니다.
      

MHA 실행 명령어 설명

MHA 매니저와 MHA 노드를 설치하면 "/usr/local/bin" 디렉토리에 여러 실행 명령어가 설치되게 됩니다.

주요 실행 바이너리를 살펴보면 내용은 다음과 같습니다.

• masterha_check_ssh : SSH 접속 체크
• masterha_manager Manager 실행(모니터링 시작) - 장애 발생시 failover 수행됨
  • nohup masterha_manager --conf=/home/mysql/mha/etc/app1.cnf &
  • Manager 실행(모니터링 시작) - 장애 발생시 failover 수행됨
• masterha_stop : Manager 중지
  • masterha_stop --conf=/etc/masterha/app1.cnf : Manager 중지 종료
• masterha_master_switch : TakeOver(relocate) 수행
• masterha_check_repl : 복제 현황 조회(소스, 리플리카 정보 등) 
• masterha_check_status : Status 확인하기

포스팅 환경에서는 MHA 기능 수행은 위에서 생성한 OS유저 인 mysql 로 수행합니다.

압축된 0.58 버전 파일을 사용할 경우 masterha_check_repl 실행시 MySQL 버전 또는 버전 표기에 따라서 에러가 발생할 수 있습니다.

• 발생되는 에러 내역

$ masterha_check_repl --conf=/home/mysql/mha/etc/app1.cnf
Mon .. 2023 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon .. 2023 - [info] Reading application default configuration from /home/mysql/mha/etc/app1.cnf..
Mon .. 2023 - [info] Reading server configuration from /home/mysql/mha/etc/app1.cnf..
Mon .. 2023 - [info] MHA::MasterMonitor version 0.58.
Mon .. 2023 - [error][/usr/local/share/perl5/MHA/MasterMonitor.pm, ln427] Error happened on checking configurations. 
    ..             Redundant argument in sprintf at /usr/local/share/perl5/MHA/NodeUtil.pm line 203.
Mon .. 2023 - [error][/usr/local/share/perl5/MHA/MasterMonitor.pm, ln525] Error happened on monitoring servers.
Mon .. 2023 - [info] Got exit code 1 (Not master dead).

git clone 으로 직접 다운로드 받은 MHA Node파일에는 masterha_check_repl 바이너리에 대한 fix가 포함되어 있습니다.
          

MySQL8 버전관련 소스 수정 사항

MySQL8 버전에서는 5.7 버전에 비해서 복제에 관련된 용어의 변경이 있습니다.

MySQL 8 버전에서는 master 를 source 로, slave를 replica 로 용어를 변경 하였습니다. 그에 따라서 복제 설정에 관한 명령어와 파라미터 등이 수정이 되었습니다.

기존 master 와 slave 로 들어간 명령어와 파라미터를 사용시에는 아직까지 remove(obsolete) 단계는 아니고 deprecated 단계이기 때문에 warning 메세지만 발생되고 있지만 향후 remove(obsolete)를 고려하고 출력되는 내용을 고려하여 복제 수행 명령어 일부를 수정하였습니다.

• 참고 : https://blog.naver.com/theswice/222489176002

포스팅에서는 압축에 관한 부분은 제외하고 변경된 부분만 수정하였고 압축 복제 기능까지 추가하여 사용이 필요하신 분은 참고한 소스를 보시면 됩니다.

3개의 파일에 대해서 다음과 같이 수정하였습니다.

/usr/local/share/perl5/MHA/Server.pm

• Original

339 rules, temporarily executing CHANGE MASTER to dummy host, and
345 "%s: SHOW SLAVE STATUS returned empty result. To check replication filtering rules, temporarily executing CHANGE MASTER to a dummy host.",
348 $dbhelper->execute("CHANGE MASTER TO MASTER_HOST='dummy_host'");

• Modify

339 # rules, temporarily executing CHANGE REPLICATION SOURCE to dummy host, and
345 "%s: SHOW SLAVE STATUS returned empty result. To check replication filtering rules, temporarily executing CHANGE REPLICATION SOURCE to a dummy host.",
348 $dbhelper->execute("CHANGE REPLICATION SOURCE TO SOURCE_HOST='dummy_host'");

/usr/local/share/perl5/MHA/ServerManager.pm

• Original

1294 " All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='%s', MASTER_PORT=%d, MASTER_AUTO_POSITION=1, MASTER_USER='%s', MASTER_PASSWORD='xxx';",
1307 " All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='%s', MASTER_PORT=%d, MASTER_LOG_FILE='%s', MASTER_LOG_POS=%d, MASTER_USER='%s', MASTER_PASSWORD='xxx';",
1354 $log->info(" Executed CHANGE MASTER.");
1356 # After executing CHANGE MASTER, relay_log_purge is automatically disabled.

• Modify

1294 " All other slaves should start replication from here. Statement should be: CHANGE REPLICATION SOURCE TO SOURCE_HOST='%s', SOURCE_PORT=%d, SOURCE_AUTO_POSITION=1, SOURCE_USER='%s', SOURCE_PASSWORD='xxx';",
1307 " All other slaves should start replication from here. Statement should be: CHANGE REPLICATION SOURCE TO SOURCE_HOST='%s', SOURCE_PORT=%d, SOURCE_LOG_FILE='%s', SOURCE_LOG_POS=%d, SOURCE_USER='%s', SOURCE_PASSWORD='xxx';",
1354 $log->info(" CHANGE REPLICATION SOURCE.");
1356 # After executing CHANGE REPLICATION SOURCE, relay_log_purge is automatically disabled.

/usr/local/share/perl5/MHA/DBHelper.pm

• Original

71 "CHANGE MASTER TO MASTER_HOST='%s', MASTER_PORT=%d, MASTER_USER='%s', MASTER_PASSWORD='%s', MASTER_LOG_FILE='%s', MASTER_LOG_POS=%d";
73 "CHANGE MASTER TO MASTER_HOST='%s', MASTER_PORT=%d, MASTER_USER='%s', MASTER_LOG_FILE='%s', MASTER_LOG_POS=%d"; 
75 "CHANGE MASTER TO MASTER_HOST='%s', MASTER_PORT=%d, MASTER_USER='%s', MASTER_PASSWORD='%s', MASTER_AUTO_POSITION=1";
77 "CHANGE MASTER TO MASTER_HOST='%s', MASTER_PORT=%d, MASTER_USER='%s', MASTER_AUTO_POSITION=1";
87 use constant Stop_IO_Thread_SQL     => "STOP REPLICA IO_THREAD";
88 use constant Start_IO_Thread_SQL    => "START REPLICA IO_THREAD";
89 use constant Start_Slave_SQL        => "START REPLICA";
90 use constant Stop_Slave_SQL         => "STOP REPLICA";
91 use constant Start_SQL_Thread_SQL   => "START REPLICA SQL_THREAD";
92 use constant Stop_SQL_Thread_SQL    => "STOP REPLICA SQL_THREAD";

• Modify

71 "CHANGE REPLICATION SOURCE TO SOURCE_HOST='%s', SOURCE_PORT=%d, SOURCE_USER='%s', SOURCE_PASSWORD='%s', SOURCE_LOG_FILE='%s', SOURCE_LOG_POS=%d";
73 "CHANGE REPLICATION SOURCE TO SOURCE_HOST='%s', SOURCE_PORT=%d, SOURCE_USER='%s', SOURCE_LOG_FILE='%s', SOURCE_LOG_POS=%d";
75 "CHANGE REPLICATION SOURCE TO SOURCE_HOST='%s', SOURCE_PORT=%d, SOURCE_USER='%s', SOURCE_PASSWORD='%s', SOURCE_AUTO_POSITION=1";
77 "CHANGE REPLICATION SOURCE TO SOURCE_HOST='%s', SOURCE_PORT=%d, SOURCE_USER='%s', SOURCE_AUTO_POSITION=1";
87 use constant Stop_IO_Thread_SQL     => "STOP REPLICA IO_THREAD";
88 use constant Start_IO_Thread_SQL    => "START REPLICA IO_THREAD";
89 use constant Start_Slave_SQL        => "START REPLICA";
90 use constant Stop_Slave_SQL         => "STOP REPLICA";
91 use constant Start_SQL_Thread_SQL   => "START REPLICA SQL_THREAD";
92 use constant Stop_SQL_Thread_SQL    => "STOP REPLICA SQL_THREAD";

수정한 파일은 다음 링크에서 다운로드 받을 수 있습니다.
• Download Link
        

masterha_manager

이제 장애 발생시 Failover 가 동작 할 수 있도록 MHA 매니저를 시작하도록 하겠습니다.

매니저 시작 및 모니터링 시작

[mysql]$ nohup masterha_manager \
--conf=/home/mysql/mha/etc/app1.cnf \
--last_failover_minute=1 &

MHA가 마스터 DB 모니터링 중에 장애가 감지되어 failover 가 발생된 이후 일정 시간내에 장애에 대해서는 failover 가 진행되지 않습니다.

계속된 문제로 failover 가 Ping pong 형태로 반복되는 것을 고려하여 장애가 발생하여 failover 가 한번 처리된 후 일정 시간안에는 failover가 되지 않으며 기본 값은 8시간입니다.

이와 관련된 수행 옵션이 있으며 last_failover_minute 옵션입니다

포스팅에서는 반복적으로 테스트를 위하여 1분으로 지정하고 수행하였습니다.

실제 사용시에도 장애 이후 다음 failover 시간의 gap이 8시간이 너무 크다고 생각된다면 last_failover_minute 를 통해 조절하시면 됩니다
                 

장애조치 - Failover

소스 인스턴스(서버)장애가 발생될 경우 MHA에 의해 MySQL의 장애조치(Failover) 수행 동작을 확인해 보도록 하겠습니다.

소스 서버에서 kill 명령어나 서비스 명령어(systemctl)로 MySQL DB 인스턴스를 종료하여 장애를 발생시키도록 하겠습니다.

manager 프로세스 유무 확인

인스턴스 장애를 발생시키기 전에 매니저 프로세스 기동 여부를 확인해보도록 하겠습니다.

[mysql]$ ps -ef| grep masterha | grep -v grep
mysql <.. 중략 ..> perl /usr/local/bin/masterha_manager <.. 중략 ..>

소스 MySQL 중지

MySQL 구성에 따라서 각각 다른 방법으로 소스 MySQL 인스턴스를 종료하도록 하겠습니다.

[root]# systemctl stop mysqld

or

[mysql]# /../../mysql.server stop

MHA failover 로그 및 확인

.. 20:44:45 2023 - [warning] Got error on MySQL connect: 2002 (Can't connect to MySQL server on '192.168.56.63' (115))
.. 20:44:45 2023 - [warning] Connection failed 3 time(s)..Monitoring server mha3 is reachable, Master is not reachable from mha3. OK.
.. 20:44:46 2023 - [info] Master is not reachable from all other monitoring servers. Failover should start.
.. 20:44:50 2023 - [warning] Got error on MySQL connect: 2002 (Can't connect to MySQL server on '192.168.56.63' (115))
.. 20:44:50 2023 - [warning] Connection failed 4 time(s)..
.. 20:44:50 2023 - [warning] Master is not reachable from health checker!
.. 20:44:50 2023 - [warning] Master mha1(192.168.56.63:3306) is not reachable!
.. 20:44:50 2023 - [warning] SSH is NOT reachable.
.. 20:44:50 2023 - [info] Connecting to a master server failed. Reading configuration file 
                    /etc/masterha_default.cnf and /home/mysql/mha/etc/app1.cnf again, 
                    and trying to connect to all servers to check server status..
.. 20:44:50 2023 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
.. 20:44:50 2023 - [info] Reading application default configuration from /home/mysql/mha/etc/app1.cnf..
.. 20:44:50 2023 - [info] Reading server configuration from /home/mysql/mha/etc/app1.cnf..
.. 20:44:51 2023 - [info] GTID failover mode = 0
.. 20:44:51 2023 - [info] Dead Servers:
.. 20:44:51 2023 - [info]   mha1(192.168.56.63:3306)
.. 20:44:51 2023 - [info] Alive Servers:
.. 20:44:51 2023 - [info]   mha2(192.168.56.64:3306)
.. 20:44:51 2023 - [info]   mha3(192.168.56.65:3306)
.. 20:44:51 2023 - [info] Alive Slaves:
.. 20:44:51 2023 - [info]   mha2(192.168.56.64:3306)  Version=8.0.34 (oldest major version between slaves) log-bin:enabled
.. 20:44:51 2023 - [info]     Replicating from mha1(192.168.56.63:3306)
.. 20:44:51 2023 - [info]     Primary candidate for the new Master (candidate_master is set)
.. 20:44:51 2023 - [info]   mha3(192.168.56.65:3306)  Version=8.0.34 (oldest major version between slaves) log-bin:enabled
.. 20:44:51 2023 - [info]     Replicating from mha1(192.168.56.63:3306)
.. 20:44:51 2023 - [info]     Primary candidate for the new Master (candidate_master is set)
.. 20:44:51 2023 - [info] Checking slave configurations..
.. 20:44:51 2023 - [info] Checking replication filtering settings..
.. 20:44:51 2023 - [info]  Replication filtering check ok.
.. 20:44:51 2023 - [info] Master is down!
.. 20:44:51 2023 - [info] Terminating monitoring script.
.. 20:44:51 2023 - [info] Got exit code 20 (Master dead).
.. 20:44:51 2023 - [info] MHA::MasterFailover version 0.58.
.. 20:44:51 2023 - [info] Starting master failover.
.. 20:44:51 2023 - [info]
.. 20:44:51 2023 - [info] * Phase 1: Configuration Check Phase..
.. 20:44:51 2023 - [info]
.. 20:44:53 2023 - [info] GTID failover mode = 0
.. 20:44:53 2023 - [info] Dead Servers:
.. 20:44:53 2023 - [info]   mha1(192.168.56.63:3306)
.. 20:44:53 2023 - [info] Checking master reachability via MySQL(double check)...
.. 20:44:53 2023 - [info]  ok.
.. 20:44:53 2023 - [info] Alive Servers:
.. 20:44:53 2023 - [info]   mha2(192.168.56.64:3306)
.. 20:44:53 2023 - [info]   mha3(192.168.56.65:3306)
.. 20:44:53 2023 - [info] Alive Slaves:
.. 20:44:53 2023 - [info]   mha2(192.168.56.64:3306)  Version=8.0.34 (oldest major version between slaves) log-bin:enabled
.. 20:44:53 2023 - [info]     Replicating from mha1(192.168.56.63:3306)
.. 20:44:53 2023 - [info]     Primary candidate for the new Master (candidate_master is set)
.. 20:44:53 2023 - [info]   mha3(192.168.56.65:3306)  Version=8.0.34 (oldest major version between slaves) log-bin:enabled
.. 20:44:53 2023 - [info]     Replicating from mha1(192.168.56.63:3306)
.. 20:44:53 2023 - [info]     Primary candidate for the new Master (candidate_master is set)
.. 20:44:53 2023 - [info] Starting Non-GTID based failover.
.. 20:44:53 2023 - [info]
.. 20:44:53 2023 - [info] ** Phase 1: Configuration Check Phase completed.
.. 20:44:53 2023 - [info]
.. 20:44:53 2023 - [info] * Phase 2: Dead Master Shutdown Phase..
.. 20:44:53 2023 - [info]
.. 20:44:53 2023 - [info] Forcing shutdown so that applications never connect to the current master..
.. 20:44:53 2023 - [warning] master_ip_failover_script is not set. Skipping invalidating dead master IP address.
.. 20:44:53 2023 - [warning] shutdown_script is not set. Skipping explicit shutting down of the dead master.
.. 20:45:04 2023 - [info] * Phase 2: Dead Master Shutdown Phase completed.
.. 20:45:04 2023 - [info]
.. 20:45:04 2023 - [info] * Phase 3: Master Recovery Phase..
.. 20:45:04 2023 - [info]
.. 20:45:04 2023 - [info] * Phase 3.1: Getting Latest Slaves Phase..
.. 20:45:04 2023 - [info]
.. 20:45:04 2023 - [info] The latest binary log file/position on all slaves is binlog.000013:157
.. 20:45:04 2023 - [info] Latest slaves (Slaves that received relay log files to the latest):
.. 20:45:04 2023 - [info]   mha2(192.168.56.64:3306)  Version=8.0.34 (oldest major version between slaves) log-bin:enabled
.. 20:45:04 2023 - [info]     Replicating from mha1(192.168.56.63:3306)
.. 20:45:04 2023 - [info]     Primary candidate for the new Master (candidate_master is set)
.. 20:45:04 2023 - [info]   mha3(192.168.56.65:3306)  Version=8.0.34 (oldest major version between slaves) log-bin:enabled
.. 20:45:04 2023 - [info]     Replicating from mha1(192.168.56.63:3306)
.. 20:45:04 2023 - [info]     Primary candidate for the new Master (candidate_master is set)
.. 20:45:04 2023 - [info] The oldest binary log file/position on all slaves is binlog.000013:157
.. 20:45:04 2023 - [info] Oldest slaves:
.. 20:45:04 2023 - [info]   mha2(192.168.56.64:3306)  Version=8.0.34 (oldest major version between slaves) log-bin:enabled
.. 20:45:04 2023 - [info]     Replicating from mha1(192.168.56.63:3306)
.. 20:45:04 2023 - [info]     Primary candidate for the new Master (candidate_master is set)
.. 20:45:04 2023 - [info]   mha3(192.168.56.65:3306)  Version=8.0.34 (oldest major version between slaves) log-bin:enabled
.. 20:45:04 2023 - [info]     Replicating from mha1(192.168.56.63:3306)
.. 20:45:04 2023 - [info]     Primary candidate for the new Master (candidate_master is set)
.. 20:45:04 2023 - [info]
.. 20:45:04 2023 - [info] * Phase 3.2: Saving Dead Master's Binlog Phase..
.. 20:45:04 2023 - [info]
.. 20:45:04 2023 - [warning] Dead Master is not SSH reachable. Could not save it's binlogs. 
                   Transactions that were not sent to the latest slave (Read_Master_Log_Pos to the tail of the dead master's binlog) were lost.
.. 20:45:04 2023 - [info]
.. 20:45:04 2023 - [info] * Phase 3.3: Determining New Master Phase..
.. 20:45:04 2023 - [info]
.. 20:45:04 2023 - [info] Finding the latest slave that has all relay logs for recovering other slaves..
.. 20:45:04 2023 - [info] All slaves received relay logs to the same position. No need to resync each other.
.. 20:45:04 2023 - [info] Searching new master from slaves..
.. 20:45:04 2023 - [info]  Candidate masters from the configuration file:
.. 20:45:04 2023 - [info]   mha2(192.168.56.64:3306)  Version=8.0.34 (oldest major version between slaves) log-bin:enabled
.. 20:45:04 2023 - [info]     Replicating from mha1(192.168.56.63:3306)
.. 20:45:04 2023 - [info]     Primary candidate for the new Master (candidate_master is set)
.. 20:45:04 2023 - [info]   mha3(192.168.56.65:3306)  Version=8.0.34 (oldest major version between slaves) log-bin:enabled
.. 20:45:04 2023 - [info]     Replicating from mha1(192.168.56.63:3306)
.. 20:45:04 2023 - [info]     Primary candidate for the new Master (candidate_master is set)
.. 20:45:04 2023 - [info]  Non-candidate masters:
.. 20:45:04 2023 - [info]  Searching from candidate_master slaves which have received the latest relay log events..
.. 20:45:04 2023 - [info] New master is mha2(192.168.56.64:3306)
.. 20:45:04 2023 - [info] Starting master failover..
.. 20:45:04 2023 - [info]
From:
mha1(192.168.56.63:3306) (current master)
 +--mha2(192.168.56.64:3306)
 +--mha3(192.168.56.65:3306)

To:
mha2(192.168.56.64:3306) (new master)
 +--mha3(192.168.56.65:3306)
.. 20:45:04 2023 - [info]
.. 20:45:04 2023 - [info] * Phase 3.4: New Master Diff Log Generation Phase..
.. 20:45:04 2023 - [info]
.. 20:45:04 2023 - [info]  This server has all relay logs. No need to generate diff files from the latest slave.
.. 20:45:04 2023 - [info]
.. 20:45:04 2023 - [info] * Phase 3.5: Master Log Apply Phase..
.. 20:45:04 2023 - [info]
.. 20:45:04 2023 - [info] *NOTICE: If any error happens from this phase, manual recovery is needed.
.. 20:45:04 2023 - [info] Starting recovery on mha2(192.168.56.64:3306)..
.. 20:45:04 2023 - [info]  This server has all relay logs. Waiting all logs to be applied..
.. 20:45:04 2023 - [info]   done.
.. 20:45:04 2023 - [info]  All relay logs were successfully applied.
.. 20:45:04 2023 - [info] Getting new master's binlog name and position..
.. 20:45:04 2023 - [info]  binlog.000005:157
.. 20:45:04 2023 - [info]  All other slaves should start replication from here. 
        Statement should be: CHANGE REPLICATION SOURCE TO SOURCE_HOST='mha2 or 192.168.56.64',
         SOURCE_PORT=3306, SOURCE_LOG_FILE='binlog.000005', SOURCE_LOG_POS=157, 
         SOURCE_USER='repl', SOURCE_PASSWORD='xxx';
.. 20:45:04 2023 - [warning] master_ip_failover_script is not set. Skipping taking over new master IP address.
.. 20:45:04 2023 - [info] Setting read_only=0 on mha2(192.168.56.64:3306)..
.. 20:45:04 2023 - [info]  ok.
.. 20:45:04 2023 - [info] ** Finished master recovery successfully.
.. 20:45:04 2023 - [info] * Phase 3: Master Recovery Phase completed.
.. 20:45:04 2023 - [info]
.. 20:45:04 2023 - [info] * Phase 4: Slaves Recovery Phase..
.. 20:45:04 2023 - [info]
.. 20:45:04 2023 - [info] * Phase 4.1: Starting Parallel Slave Diff Log Generation Phase..
.. 20:45:04 2023 - [info]
.. 20:45:04 2023 - [info] -- Slave diff file generation on host mha3(192.168.56.65:3306) started, pid: 22366. 
                    Check tmp log /home/mysql/mha/app1/mha3_3306_20231025204451.log if it takes time..
.. 20:45:15 2023 - [info]
.. 20:45:15 2023 - [info] Log messages from mha3 ...
.. 20:45:15 2023 - [info]
.. 20:45:04 2023 - [info]  This server has all relay logs. No need to generate diff files from the latest slave.
.. 20:45:15 2023 - [info] End of log messages from mha3.
.. 20:45:15 2023 - [info] -- mha3(192.168.56.65:3306) has the latest relay log events.
.. 20:45:15 2023 - [info] Generating relay diff files from the latest slave succeeded.
.. 20:45:15 2023 - [info]
.. 20:45:15 2023 - [info] * Phase 4.2: Starting Parallel Slave Log Apply Phase..
.. 20:45:15 2023 - [info]
.. 20:45:15 2023 - [info] -- Slave recovery on host mha3(192.168.56.65:3306) started, pid: 22368. 
                    Check tmp log /home/mysql/mha/app1/mha3_3306_20231025204451.log if it takes time..
.. 20:45:18 2023 - [info]
.. 20:45:18 2023 - [info] Log messages from mha3 ...
.. 20:45:18 2023 - [info]
.. 20:45:15 2023 - [info] Starting recovery on mha3(192.168.56.65:3306)..
.. 20:45:15 2023 - [info]  This server has all relay logs. Waiting all logs to be applied..
.. 20:45:15 2023 - [info]   done.
.. 20:45:15 2023 - [info]  All relay logs were successfully applied.
.. 20:45:15 2023 - [info]  Resetting slave mha3(192.168.56.65:3306) and starting replication from the new master mha2(192.168.56.64:3306)..
.. 20:45:15 2023 - [info]  CHANGE REPLICATION SOURCE.
.. 20:45:15 2023 - [info]  Slave started.
.. 20:45:18 2023 - [info] End of log messages from mha3.
.. 20:45:18 2023 - [info] -- Slave recovery on host mha3(192.168.56.65:3306) succeeded.
.. 20:45:18 2023 - [info] All new slave servers recovered successfully.
.. 20:45:18 2023 - [info]
.. 20:45:18 2023 - [info] * Phase 5: New master cleanup phase..
.. 20:45:18 2023 - [info]
.. 20:45:18 2023 - [info] Resetting slave info on the new master..
.. 20:45:18 2023 - [info]  mha2: Resetting slave info succeeded.
.. 20:45:18 2023 - [info] Master failover to mha2(192.168.56.64:3306) completed successfully.
.. 20:45:18 2023 - [info]

----- Failover Report -----

app1: MySQL Master failover mha1(192.168.56.63:3306) to mha2(192.168.56.64:3306) succeeded

Master mha1(192.168.56.63:3306) is down!

Check MHA Manager logs at mha-manager:/home/mysql/mha/app1/app1_manager.log for details.

Started automated(non-interactive) failover.
The latest slave mha2(192.168.56.64:3306) has all relay logs for recovery.
Selected mha2(192.168.56.64:3306) as a new master.
mha2(192.168.56.64:3306): OK: Applying all logs succeeded.
mha3(192.168.56.65:3306): This host has the latest relay log events.
Generating relay diff files from the latest slave succeeded.
mha3(192.168.56.65:3306): OK: Applying all logs succeeded. 
     Slave started, replicating from mha2(192.168.56.64:3306)
mha2(192.168.56.64:3306): Resetting slave info succeeded.
Master failover to mha2(192.168.56.64:3306) completed successfully.

* 가로 길이에 따른 일부 내용은 개행 되어있습니다.

로그를 살펴보면 1번 DB 인스턴스의 문제를 정상적으로 감지하여 failover를 수행하였고 출력되는 내용 중에서도 소스를 수정한 내용이 반영되어 MySQL8 버전의 복제 구문이 출력되는 것을 확인할 수 있습니다.

.. 20:45:04 2023 - [info]  All other slaves should start replication from here. 
        Statement should be: CHANGE REPLICATION SOURCE TO SOURCE_HOST='mha2 or 192.168.56.64',
         SOURCE_PORT=3306, SOURCE_LOG_FILE='binlog.000005', SOURCE_LOG_POS=157, 
         SOURCE_USER='repl', SOURCE_PASSWORD='xxx';

2번, 3번 인스턴스에서도 정보를 확인해보도록 하겠습니다.

• 2번 서버에서 read_only 여부 및 복제 설정 초기화 확인

mysql> select @@read_only;
+-------------+
| @@read_only |
+-------------+
|           0 |
+-------------+

mysql> show replica status\G
Empty set (0.00 sec)

• 3번 서버에서 복제 소스 인스턴스 정보 확인

mysql> show replica status\G
*************************** 1. row ***************************
             Replica_IO_State: Waiting for source to send event
                  Source_Host: mha2 <!!---
                  Source_User: repl
                  Source_Port: 3306
                Connect_Retry: 60
              Source_Log_File: binlog.000005
          Read_Source_Log_Pos: 157
< ... 중략 ... >

Failover 후속 작업

MHA에 의해서 Failover가 완료된 후 진행이 필요한 예상되는 몇 가지 작업을 수행하도록 하겠습니다.


복제 정상화 및 manager 모니터링 활성화

다시 정상화를 위해서 MySQL 1번 인스턴스(이전 Source 인스턴스)는 2번 인스턴스를 Source 로 설정한 Replica 인스턴스로 구성을 진행합니다.

1번 서버에서 먼저 종료된 MySQL를 기동합니다.

[root]# systemctl start mysqld

or

[mysql]# /../../mysql.server start

복제 설정하는 정보는 Failover 가 수행될 때 MHA Manager 로그에서 확인할 수 있습니다.

[info] All other slaves should start replication from here. 
Statement should be: CHANGE REPLICATION SOURCE TO SOURCE_HOST='mha2 or 192.168.56.64',
SOURCE_PORT=3306, SOURCE_LOG_FILE='binlog.000005', SOURCE_LOG_POS=157, 
SOURCE_USER='repl', SOURCE_PASSWORD='xxx';

위의 정보 그대로 1번 MySQL DB 인스터스에서 실행하여 복제 설정 및 시작합니다.

-- 복제 설정
mysql> CHANGE REPLICATION SOURCE TO SOURCE_HOST='mha2', SOURCE_PORT=3306, 
SOURCE_LOG_FILE='binlog.000005', SOURCE_LOG_POS=157, 
SOURCE_USER='repl', SOURCE_PASSWORD='repl';


-- 복제 시작
mysql> start replica;


-- 복제 상태 확인
mysql> show replica status\G

새로운 소스에서 리플리카 정보 확인

Failover 수행에 따른 프로모션된 새로운 소스 인스턴스에 다음과 같이 수행하여 2개의 리플리카 인스턴스의 정보 출력되는 확인합니다.

mysql> show replicas;

or

mysql> show slave hosts;


출력결과)
+-----------+------+------+-----------+--------------------------------------+
| Server_Id | Host | Port | Source_Id | Replica_UUID                         |
+-----------+------+------+-----------+--------------------------------------+
|   8943453 | mha1 | 3306 |  45673453 | 3176baa6-6a87-11ee-acaa-0800272b0290 |
|   3657657 | mha3 | 3306 |  45673453 | bbe867df-6a89-11ee-82ad-080027c21292 |
+-----------+------+------+-----------+--------------------------------------+

매니저 기동(모니터링 수행)

다시 DB 상태를 모니터링하고 장애 시 Failover가 될 수 있도록 매니저 프로세스를 시작합니다.

[mysql]$ nohup masterha_manager \
--conf=/home/mysql/mha/etc/app1.cnf \
--last_failover_minute=1 &

masterha_master_switch

서버의 메인터넌스나 DB의 업그레이드나 작업 등으로 사용자 정의 Failover(Takeover)를 수행해야 할 경우가 있으며 이럴 때 masterha_master_switch 명령어를 사용하여 Failover를 진행할 수 있습니다.

masterha_master_switch에 대한 내용은 이전 MHA 포스팅을 참조하시면 됩니다.

MySQL MHA(Master High Availability) 3 - VIP 설정 - MHA 모니터링 - Takeover - Failover

이번에는 사용자 임의의 Failover 를 수행해보도록 하겠으며 명령어는 masterha_master_switch 입니다. masterha_master_switch 명령어를 통해서 예약된 작업 등의 사유로 계획된 take over(relocate) 를 할 수 있습니다.

purge_relay_logs

MHA에서는 relay_log_purge 기능 비활성화(0,off,false) 이 권장이며, fail-over 나 switch-over 시 relay log의 purge가 수행됩니다.

그 외 별도로 purge 가 필요한 경우 MHA 내에 제공되는 스크립트를 통해서 수행할 수 있습니다.

관련된 내용은 이전 MHA 포스팅에서 확인할 수 있습니다.

MySQL MHA(Master High Availability) 3 - VIP 설정 - MHA 모니터링 - Takeover - Failover

스크립트는 /usr/local/bin/purge_relay_logs 이며 실행 방법은 다음과 같으며, MySQL이 실행되는 서버에서 직접 실행합니다.

이번 MySQL8 버전에서의 MHA 글에서는 VIP구성없이 ProxySQL를 통한 Client Side HA를 구성하는 내용으로 진행하였습니다.

이번 글은 여기에서 마무리하고 이어서 ProxySQL를 사용하여 Failover 시 Client 레벨에서의 HA 등을 살펴보도록 하겠습니다.

• 이어지는 다음 글

MySQL 8 MHA and ProxySQL on RockyLinux 8 - 5번째 글

이번 글은 MySQL 8 버전에서 구성한 MHA 환경에서 ProxySQL을 연계하여 고가용성 구성을 하는 내용을 설명합니다.

Reference

Reference URL
• github.com/mha-manager/Configuration
• githubusercontent.com/mha-manager/Parameters
• blog.naver.com/theswice/222489176002


관련된 다른 글

MySQL MHA(Master High Availability) 1 - MHA 기능 설명 및 아키텍처 설명

MySQL HA솔루션인 MHA에 관한 내용으로 MHA 기능 설명 및 아키텍처에 대한 설명을 합니다.

MySQL Orchestrator - HA(High Availability) - 1 - 기능 설명 및 설치

이번 포스팅은 MySQL/MariaDB의 HA 고가용성 솔루션인 Orchestrator 에 대해서 설치 및 여러 설정 등에 대해서 확인해보려고 하며 포스팅은 연재글로 되어 있습니다.

MySQL - InnoDB Cluster(클러스터) - (1) - 아키텍처 - 그룹 복제(Group Replication)

이번 포스팅에서는 InnoDB Cluster(클러스터) 에 대해서 InnoDB 의 아키텍처 및 구성 및 설정에 관해서 확인해보도록 하겠습니다.

MySQL Replication(복제) 구성 및 설정 - Async - Semi Async

리플리케이션(Replication)은 DB의 내용을 복제함을 의미하며 복제 대상인 Master가 1개 또는 다수에 대해서 Slave(Standby)가 복제를 하여 사용하는 것을 의미합니다.

Jade(정현호)

Principal DBA(MySQL, AWS Aurora, Oracle)
핀테크 서비스인 핀다에서 데이터베이스를 운영하고 있어요(at finda.co.kr)
Previous - 당근마켓, 위메프, Oracle Korea ACS / Fedora Kor UserGroup 운영중

Database 외에도 NoSQL , Linux , Python, Cloud, Http/PHP CGI 등에도 관심이 있습니다
purityboy83@gmail.com / admin@hoing.io

hoing.io