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

Last Updated on 4월 26, 2021 by 태랑(정현호)



[먼저] 해당 포스팅은 MHA 의 2번째 글로 아래 포스팅에서 이어지는 글 입니다.


업데이트 일자 : 2021/03/10



MHA 구성 환경 내역



이번 포스팅에서는 총 4개 서버 를 통해 설치 및 구성 하였습니다.





OS : Centos 7.8

Mysql : 5.7.31
Mysql S/W : /usr/local/mysql


IP 설정 내역
Master Server - 192.168.56.51 / Hostname: acs
Slave Server1 - 192.168.56.52 / Hostname: acs2
Slave Server2 - 192.168.56.56 / Hostname: acs3

MHA Manager - 192.168.56.104 / hostname : mgr
Master DB VIP - 192.168.56.50


conf 파일 위치 : /etc/masterha/
script 위치 : /masterha/scripts/

MHA 매니저/Remote 서버 실행 정보 저장 디렉토리 및 로그 디렉토리
/masterha/app1/



/etc/hosts 설정 내역 - 모든 서버 공통

192.168.56.51 acs

192.168.56.52 acs2
192.168.56.56 acs3

192.168.56.104 mgr
192.168.56.50 mha-master-vip


* 본문 내용과 작성된 스크립트 내부에서 대부분 위의 호스트네임을 사용 합니다



* 각 노드에 MySQL 은 설치된 상태 에서 진행된 시나리오 입니다.
설치 방법은 아래 포스팅을 참조하시면 됩니다.


우분투 환경에 Mysql 5.7 설치 - APT,Binary Unzip,소스컴파일 설치 가이드[Link]

CentOS 환경에서 Mysql 5.7 YUM 으로 설치[Link]

CentOS 환경에서 Mysql 5.7 소스컴파일 및 Binary Unzip 설치 가이드[Link]







MySQL Replication 구성



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


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






Semi-sync Replication 은 Mysql 5.5 버전에서 도입된 sync 형태의 복제 방식 입니다.



Semi-sync Replication 방식은 Master 에서 Slave 로 전달된 Relay log의 기록이 완료 되었다는 메세지(신호)를 받고나서 처리중인 transaction의 결과를 요청한 application(client)에 결과를 반환해주는 방식 입니다.



그래서 Master 장애시 복제에 대해서 손실 방지 혹은 손실의 최소화를 할 수 있습니다


포스팅에서는 설명의 간략화를 위해 async로 설명 합니다
자세한 내용은 아래 포스팅을 꼭 참조해주세요

Mysql Replication 1 - Async 구성 및 Semi Sync 설명[Link]
Mysql Replication 2 - Semy Sync 구성 및 설정[Link]






MySQL 설정 변경 - my.cnf 수정

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

[root]# vi /etc/my.cnf



# Master 설정


[mysqld]

server-id=1
# -> server-id는 master와 slave가 달라야 합니다
### Replication
log-bin=/usr/local/mysql/logs/binlog
# -> Binlog의 파일명을 기재 합니다.
sync_binlog=1
binlog_cache_size=2M
binlog_format=ROW

max_binlog_size=512M
expire_logs_days=7
log-bin-trust-function-creators=1
report-host=acs
# -> 각 DB의 호스트네임으로 show slave hosts 에서 정보로 활용
relay-log=/usr/local/mysql/logs/relay_log
relay-log-index=/usr/local/mysql/logs/relay_log.index
relay_log_purge=off
expire_logs_days=7
log_slave_updates=ON





# Slave 설정

[mysqld]
server-id=2
# -> server-id는 master와 slave가 달라야 합니다
### Replication Option
log-bin=/usr/local/mysql/logs/binlog
# -> Binlog의 파일명을 기재 합니다.
sync_binlog=1
binlog_cache_size=2M
binlog_format=ROW

max_binlog_size=512M
log-bin-trust-function-creators=1
report-host=acs2
# -> 각 DB의 호스트네임으로 show slave hosts 에서 정보로 활용
relay-log=/usr/local/mysql/logs/relay_log
relay-log-index=/usr/local/mysql/logs/relay_log.index
relay_log_purge=off
expire_logs_days=7
log_slave_updates=ON
read_only





# Slave 설정

[mysqld]
server-id=3
# -> server-id는 master와 slave가 달라야 합니다
### Replication Option
log-bin=/usr/local/mysql/logs/binlog
# -> Binlog의 파일명을 기재 합니다.
binlog_cache_size=2M
binlog_format=ROW

max_binlog_size=512M
log-bin-trust-function-creators=1
report-host=acs3
# -> 각 DB의 호스트네임으로 show slave hosts 에서 정보로 활용
relay-log=/usr/local/mysql/logs/relay_log
relay-log-index=/usr/local/mysql/logs/relay_log.index
relay_log_purge=off
expire_logs_days=7
log_slave_updates=ON
read_only



* 포스팅에서는 마스터1대 , 슬레이브 2대의 구성 입니다.
* relay_log_purge 는 비활성화 하며, fail-over나 Switch-over시 MHA 에 의해 purge 되고 별도의 log purge 는 중간에서 설명이 되어 있습니다.




MySQL 재시작


위 설정을 추가 하고 master/slave 모두 mysql을 재시작 합니다.


[root]# systemctl restart mysqld





Replication 전용 유저 생성


(마스터,슬레이브 - 모든 DB)


[root]# mysql --login-path=dba

mysql> create user 'repl_user'@'%' identified by 'repl_user';
mysql> grant replication slave on *.* to 'repl_user'@'%';
mysql> flush privileges;



[참조] --login-path 는 mysql 5.6부터 추가된 기능으로 접속정보,계정정보를 암호화해 저장해서 사용하는 기능 입니다

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







Replication 설정

마스터에서 binlog 파일 정보와 log pos 정보를 확인 합니다.


= 마스터에서 조회
mysql> show master status\G
*************************** 1. row ***************************
File: binlog.000020
Position: 154
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:




=Slave 에서 Replication 설정 및 시작
mysql> CHANGE MASTER TO MASTER_HOST='acs', MASTER_USER='repl_user',
MASTER_PASSWORD='repl_user',
MASTER_LOG_FILE='binlog.000020',
MASTER_LOG_POS=154;

mysql> start slave;

mysql> show slave status\G






== 마스터에서 조회
mysql> show slave hosts\G
*************************** 1. row ***************************
Server_id: 3
Host: acs3
Port: 3306
Master_id: 1
Slave_UUID: 706aaace-11d5-11eb-8127-0800279c8b61
*************************** 2. row ***************************
Server_id: 2
Host: acs2
Port: 3306
Master_id: 1
Slave_UUID: 6e5b28b4-3666-11eb-a44f-080027bf7f98
2 rows in set (0.00 sec)



* master / slave 모두 MySQL 설치 직후 Replication 임으로 master에서 초기데이터를 옴기지 않았지만, 계속 사용 중인 master 라면 mysqldump 등을 통해 초기 데이터 복제가 필요 합니다.






MySQL DB 접속계정(mha) 생성

MHA 매니저 서버에서는 master,slave 서버 모든 서버에 접속 할 수 있어야 합니다.

해당 계정을 통해 복제 모니터링 및 기타 상태 필요한 쿼리를 수행 하게 됩니다.




Master 에서 수행

[root]# mysql --login-path=dba

mysql> CREATE USER ‘mha’@'%' IDENTIFIED BY 'mha';

mysql> GRANT ALL PRIVILEGES ON *.* TO ‘mha’@'%';
mysql> FLUSH PRIVILEGES;


* mysql Database(Schema) 이 Replication 포함되었거나 전체 복제라면 master 에서 계정 생성시 slave 에서도 동일하게 생성 됩니다.

* mysql 을 Replication 에서 제외 하였다면 slave 에서 유저를 별도로 생성 하면 됩니다



생성 확인 - Slave 에서 조회

mysql> select user,host from mysql.user where user='mha';





OS 유저 생성 및 SSH 키 인증 설정



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


먼저 모든 서버에 공통으로 유저를 생성 합니다.




OS 유저 생성 및 설정

그룹 생성 및 유저를 아래와 같이 추가 합니다.

[root]# useradd -g mysql mha
[root]# passwd mha
Changing password for user mha.
New password: [패스워드 입력]
Retype new password: [패스워드 입력]

[root]# su - mha




PATH 관련 환경 변수를 추가(모든 노드의 mha 유저)


[mha]$ echo "export PATH=$PATH:/usr/local/bin:/usr/local/mysql/bin" >> ~/.bash_profile

[mha]$ source ~/.bash_profile


* /usr/local/mysql/bin 위치는 소스컴파일이나 Binary unzip 으로 설치 하였을때 위치 입니다.
RPM/YUM 패키지로 설치 하였을 경우 /usr/local/bin 만 추가 해주시면 됩니다.






모든 서버에서 생성 SSH 키 생성

생성 명령어 :  ssh-keygen -t rsa -b 4096

[mha]$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/mha/.ssh/id_rsa): [엔터]
Created directory '/home/mha/.ssh'.
Enter passphrase (empty for no passphrase): [엔터]
Enter same passphrase again: [엔터]
Your identification has been saved in /home/mha/.ssh/id_rsa.
Your public key has been saved in /home/mha/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:J52+2342342sdfsdfasdfasfasdfasf mha@xxxx
The key's randomart image is:
+---[RSA 4096]----+
|xxxxxxxx ..      |
|.xxxxxx..        |
| o.xxxxxxx       |
|+xxxxxxxxx .     |
|=..xxxxxx +      |
|+.. . o.++       |
|.xxxxxxxxxxx     |
|  xxxxxxxxxxxx   |
|    xxxxxxxx     |
+----[SHA256]-----+




공개키 전송(Copy)

생성 한 공개키(.pub)를 모든 서버로 전송 해야 합니다.

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




ssh-copy-id 를 이용하면 되며 아래와 같이 수행 합니다.
명령어 예시 : 매니저 서버-> 1번 서버로 공개키 복사


[mha]$ ssh-copy-id -i acs
mha@acs'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.




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

[mha]$ ssh acs
Last login: Fri Dec 2020

[mha@acs ~]$ hostname
acs <-- 정상적으로 접속이 확인됨





1번 서버에서는 매니저서버로 부터 전송 받은 키는 authorized_keys 파일에 입력되어 있습니다.

[mha]$ cd .ssh
[mha]$ cat authorized_keys
ssh-rsa XXXXXXXXXX== mha@mgr


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





OS 유저 - mha 유저 sudouser 설정



* 마스터, 슬레이스 서버에서 설정

VIP 에 대한 페일오버 및 IP assign 을 위해 필요시 mha 유저가 root 권한을 수행 할 수 있도록 sudouser 를 설정 해야 합니다.



[root]# visudo

아래 내용 추가 합니다.

mha ALL=(ALL) NOPASSWD:/sbin/ifconfig




[mha]$ifconfig -a
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.56.51 netmask 255.255.255.0 broadcast 192.168.56.255

* 포스팅 환경에서 public nic은 enp0s3 입니다.






가상 IP(VIP) 설정 테스트 

mha 유저로 vip 가동 여부를 확인 하는 절차로 마스터서버와 슬레이브 노드 모두에서 한번씩은 테스트를 진행 합니다. 

VIP UP

[mha]$ sudo ifconfig enp0s3:0 192.168.56.50 up

* 192.168.56.50 가 VIP  입니다.



[mha]$ ifconfig -a
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.56.51 netmask 255.255.255.0 broadcast 192.168.56.255


enp0s3:0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.56.50 netmask 255.255.255.0 broadcast 192.168.56.255
ether 08:00:27:d4:f8:ed txqueuelen 1000 (Ethernet)




VIP down

[mha]$ sudo ifconfig enp0s3:0 192.168.56.50 down






MHA 설치



필요 패키지 설치

[root]# yum install perl-DBD-MySQL \
perl-Config-Tiny perl-Log-Dispatch \
perl-Parallel-ForkManager \
perl-Log-Dispatch perl-Time-HiRes \
perl-CPAN perl-Module-Install




# MHA 매니저 설치
(mha4mysql-manager-0.58)


매니저 서버에서만 설치 합니다.

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

[root]# wget https://github.com/yoshinorim/mha4mysql-manager/releases/download/v0.58/mha4mysql-manager-0.58.tar.gz


[root]# tar zxvf mha4mysql-manager-0.58.tar.gz
[root]# cd mha4mysql-manager-0.58


[root]# perl Makefile.PL

*** Module::AutoInstall version 1.06
*** Checking for Perl dependencies…
[Core Features]
- DBI …loaded. (1.627)
- DBD::mysql …loaded. (4.023)
- Time::HiRes …loaded. (1.9725)
- Config::Tiny …loaded. (2.14)
- Log::Dispatch …loaded. (2.41)
- Parallel::ForkManager …loaded. (1.18)
- MHA::NodeConst …missing.
==> Auto-install the 1 mandatory module(s) from CPAN? [y] y


[root]# make;make install






# MHA Node 설치
(mha4mysql-node-0.58)

매니저 서버 와 Master & Slave Mysql Server 모두에서 설치 합니다.


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

[root]# wget https://github.com/yoshinorim/mha4mysql-node/releases/download/v0.58/mha4mysql-node-0.58.tar.gz

[root]# tar zxvf mha4mysql-node-0.58.tar.gz

[root]# cd mha4mysql-node-0.58

[root]# perl Makefile.PL

[root]# make;make install





심볼릭 링크 생성

대상 : 마스터 서버, 슬레이스 서버 (매니저 서버 제외)

mysql 와 mysqlbinlog 파일이 아래 경로에 없다면 root 유저로 심볼릭 링크를 설정 해줍니다.


[root]# ls -al /usr/bin/mysqlbinlog
[root]# ls -al /usr/local/bin/mysql

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





필요 디렉토리 생성 및 파일 복사


= 매니저 서버에서 수행

[root]# mkdir -p /etc/masterha

[root]# mkdir -p /masterha/scripts

[root]# cd /root/pkg/mha4mysql-manager-0.58/samples
 * /root/pkg/mha4mysql-manager-0.58 경로는 설치파일의 압축 해제 경로 입니다
=> tar zxvf mha4mysql-manager-0.58.tar.gz


[root]# cp conf/* /etc/masterha/
[root]# cp scripts/* /masterha/scripts/




# 매니저, 마스터,슬레이브 - 모든 서버에서 실행 

[root]# mkdir -p /masterha/app1

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





MHA 설정



아래 이미지 처럼 1개의 매니저 서버에서 모니터링 하고 장애 조치가 되는 MySQL의 Replication Group 은 1개 이상이 될 수도 있습니다.





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


예를들어 아이디/패스워드나 디렉토리 나 로그의 경로 가 같다면 /etc/masterha_default.cnf 파일에 설정하면 중복되는 내용을 줄일 수 있습니다.

또는 기본 설정 파일로 사용할 수 있습니다.


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

/etc/masterha/app1.cnf




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

[root]# cd /etc/masterha/
[root]# cp app1.cnf app1.cnf.ori
[root]# chown root:mysql app1.cnf
[root]# chmod 775 app1.cnf

[root]# vi app1.cnf

[server default]
user=mha
password=mha
ssh_user=mha
repl_user=repl_user
repl_password=repl_user
manager_workdir=/masterha/app1
manager_log=/masterha/app1/app1.log

remote_workdir=/masterha/app1
master_binlog_dir=/usr/local/mysql/logs

secondary_check_script=/usr/local/bin/masterha_secondary_check -s acs -s acs2 -s acs3 --user=mha --master_host=acs --master_ip=acs --master_port=3306
# --user=mha  는 DB유저를 의미 합니다.

master_ip_failover_script=/masterha/scripts/master_ip_failover
master_ip_online_change_script=/masterha/scripts/master_ip_online_change


[server1]
hostname=acs
candidate_master=1

[server2]
hostname=acs2
candidate_master=1

[server3]
hostname=acs3
candidate_master=1

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





VIP 설정 변경 및 스크립트 생성



먼저 master_ip_failover / master_ip_online_change 파일 수정이 필요 합니다


장애가 감지 되면 master_ip_failover 이 사용되며 
사용자 정의 takeover(relocate) 시 master_ip_online_change 이 사용 됩니다





master_ip_failover 수정

* 매니저 노드에서 수행
[mha]$ cd /masterha/scripts/

[mha]$ cp -ar master_ip_failover master_ip_failover.ori
[mha]$ vi master_ip_failover



== 변경 전 - 86 라인
## Creating an app user on the new master
print "Creating app user on the new master..\n";
FIXME_xxx_create_user( $new_master_handler->{dbh} );
$new_master_handler->enable_log_bin_local();
$new_master_handler->disconnect();

## Update master ip on the catalog database, etc
FIXME_xxx;




== 변경 후
## Creating an app user on the new master
## print "Creating app user on the new master..\n";
## FIXME_xxx_create_user( $new_master_handler->{dbh} );
## $new_master_handler->enable_log_bin_local();
## $new_master_handler->disconnect();

## Update master ip on the catalog database, etc
## FIXME_xxx;



== mha_change_vip.sh 추가
## Update master ip on the catalog database, etc
## FIXME_xxx;

system("/bin/bash /masterha/scripts/mha_change_vip.sh $new_master_ip"); <-- 추가

$exit_code = 0;






master_ip_online_change 수정

* 매니저 노드에서 수행
[mha]$ cd /masterha/scripts

[mha]$ cp -ar master_ip_online_change master_ip_online_change.ori
[mha]$ vi master_ip_online_change



= 변경 전 - 149 라인
## Drop application user so that nobody can connect. Disabling per-session binlog beforehand
$orig_master_handler->disable_log_bin_local();
print current_time_us() . " Drpping app user on the orig master..\n";
FIXME_xxx_drop_app_user($orig_master_handler);



= 변경 후 , 주석 처리
## Drop application user so that nobody can connect. Disabling per-session binlog beforehand
## $orig_master_handler->disable_log_bin_local();
## print current_time_us() . " Drpping app user on the orig master..\n";
## FIXME_xxx_drop_app_user($orig_master_handler);





= 변경 전 - 244 라인
## Creating an app user on the new master
print current_time_us() . " Creating app user on the new master..\n";
FIXME_xxx_create_app_user($new_master_handler);
$new_master_handler->enable_log_bin_local();
$new_master_handler->disconnect();



= 변경 후 , 주석 처리
## Creating an app user on the new master
## print current_time_us() . " Creating app user on the new master..\n";
## FIXME_xxx_create_app_user($new_master_handler);
## $new_master_handler->enable_log_bin_local();
## $new_master_handler->disconnect();





== mha_change_vip.sh 추가
## Update master ip on the catalog database, etc

system("/bin/bash /masterha/scripts/mha_change_vip.sh $new_master_ip"); <-- 추가

$exit_code = 0;
};






mha_change_vip.sh 파일 생성

[mha]$ cd /masterha/scripts
[mha]$ vi mha_change_vip.sh

* 아래 내용으로 스크립트를 작성 합니다.
* 포스팅에서 사용하는 Nic은 enp0s3 이고 vip 의 호스트네임은 mha-master-vip 입니다.
* 사용하는 환경에 따라 Nic 이름의 변경이 필요 합니다.

#!/bin/bash
## Fail-Over VIP Change

V_NEW_MASTER=`cat /etc/hosts | grep $1 | awk '{print $2}'`
V_EXIST_VIP_CHK=`ping -c 1 -W 1 mha-master-vip | grep "packet loss" | awk '{print $6}'`
V_VIP_IP=`cat /etc/hosts | grep mha-master-vip | awk '{print $1}'`

if [ $V_EXIST_VIP_CHK = "0%" ]
then

echo "VIP IS Alive, VIP Relocate $V_NEW_MASTER "
/bin/ssh mha-master-vip /bin/sudo /sbin/ifconfig enp0s3:0 down &

ssh $V_NEW_MASTER /bin/sudo /sbin/ifconfig enp0s3:0 $V_VIP_IP
ssh $V_NEW_MASTER /sbin/arping -c 5 -D -I enp0s3 -s $V_VIP_IP $V_VIP_IP

VIP_NOHUP_PS=`ps -ef| grep "ifconfig enp0s3:0" | grep ssh | grep -v grep | awk '{print $2}'` && kill -9 $VIP_NOHUP_PS


elif [ $V_EXIST_VIP_CHK = "100%" ]
then

echo "VIP IS dead, VIP Relocate $V_NEW_MASTER "
/bin/ssh $V_NEW_MASTER /bin/sudo /sbin/ifconfig enp0s3:0 $V_VIP_IP
/bin/ssh $V_NEW_MASTER /sbin/arping -c 5 -D -I enp0s3 -s $V_VIP_IP $V_VIP_IP

fi


[mha]$ chmod 755 mha_change_vip.sh



# VIP 회수 및 가동 여부를 확인을 위해 각 노드별로 한번씩 수행을 합니다.

[mha]$ ./mha_change_vip.sh 192.168.56.51
[mha]$ ping -c 5 mha-master-vip

[mha]$ ./mha_change_vip.sh 192.168.56.52
[mha]$ ping -c 5 mha-master-vip

[mha]$ ./mha_change_vip.sh 192.168.56.56
[mha]$ ping -c 5 mha-master-vip




MHA  사용법 - 모니터링 및 체크



여기 까지 설정 및 생성 등을 완료 하였다면 MHA 를 통해 모니터링 및 여러 가지 체크 기능을 사용할 수 있는 단계 까지 준비된 상태 입니다.


먼저 사용 할 수 있는 주요 명령어 를 살펴 보면 아래와 같습니다.

masterha_check_ssh : SSH 접속 체크
masterha_manager Manager 실행(모니터링 시작) - 장애 발생시 failover 수행됨
masterha_stop : Manager 중지
masterha_master_switch : TakeOver(relocate) 수행
masterha_check_repl : 복제 현황(Master/Slave 노드 정보등)
masterha_check_status : Status 확인하기


* MHA 기능 수행은 위에서 생성한 OS유저 인 mha 로 수행 합니다.
* 실행은 매니저 서버에서 합니다



한가지씩 살펴 보도록 하겠습니다.



masterha_check_ssh

• SSH 접속 체크 를 합니다.


[mha]$ masterha_check_ssh --conf=/etc/masterha/app1.cnf 
Sat 2020 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Sat 2020 - [info] Reading application default configuration from /etc/masterha/app1.cnf..
Sat 2020 - [info] Reading server configuration from /etc/masterha/app1.cnf..
Sat 2020 - [info] Starting SSH connection tests..
Sat 2020 - [debug]
Sat 2020 - [debug] Connecting via SSH from mha@acs(192.168.56.51:22) to mha@acs2(192.168.56.52:22)..
Sat 2020 - [debug] ok.
Sat 2020 - [debug] Connecting via SSH from mha@acs(192.168.56.51:22) to mha@acs3(192.168.56.56:22)..
Sat 2020 - [debug] ok.
Sat 2020 - [debug]
Sat 2020 - [debug] Connecting via SSH from mha@acs2(192.168.56.52:22) to mha@acs(192.168.56.51:22)..
Sat 2020 - [debug] ok.
Sat 2020 - [debug] Connecting via SSH from mha@acs2(192.168.56.52:22) to mha@acs3(192.168.56.56:22)..
Sat 2020 - [debug] ok.
Sat 2020 - [debug]
Sat 2020 - [debug] Connecting via SSH from mha@acs3(192.168.56.56:22) to mha@acs(192.168.56.51:22)..
Sat 2020 - [debug] ok.
Sat 2020 - [debug] Connecting via SSH from mha@acs3(192.168.56.56:22) to mha@acs2(192.168.56.52:22)..
Sat 2020 - [debug] ok.
Sat 2020 - [info] All SSH connection tests passed successfully.




masterha_check_repl

• Replication 에 대해서 Master/Slave 노드 정보 등을 체크 하게 됩니다.


[mha]$ masterha_check_repl --conf=/etc/masterha/app1.cnf


[info] Reading application default configuration from /etc/masterha/app1.cnf..
[info] Reading server configuration from /etc/masterha/app1.cnf..
[info] MHA::MasterMonitor version 0.58.
[info] Alive Servers:
[info] acs(192.168.56.51:3306)
[info] acs2(192.168.56.52:3306)
[info] acs3(192.168.56.56:3306)

[info] Alive Slaves:
[info] acs2(192.168.56.52:3306) Version=5.7.31-log log-bin:enabled
[info] Replicating from acs(192.168.56.51:3306)
[info] Primary candidate for the new Master (candidate_master is set)
[info] acs3(192.168.56.56:3306) Version=5.7.31-log log-bin:enabled
[info] Replicating from acs(192.168.56.51:3306)
[info] Primary candidate for the new Master (candidate_master is set)
[info] Current Alive Master: acs(192.168.56.51:3306)
[info] Checking slave configurations..

[info] All SSH connection tests passed successfully.
[info] Checking MHA Node version..
[info] Version check ok.

Testing mysqlbinlog output.. done.
Cleaning up test file(s).. done.
Mon Dec 14 03:37:11 2020 - [info] Slaves settings check done.
Mon Dec 14 03:37:11 2020 - [info]

acs(192.168.56.51:3306) (current master)
+--acs2(192.168.56.52:3306)
+--acs3(192.168.56.56:3306)

[info] Checking replication health on acs2..
[info] ok.
[info] Checking replication health on acs3..
[info] ok.
[info] Checking master_ip_failover_script status:
[info] OK.
[warning] shutdown_script is not defined.
[info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.



masterha_check_status

• 매니저 프로세스 체크


# 매니저 프로세스 구동되어 있을 경우
[mha]$ masterha_check_status --conf=/etc/masterha/app1.cnf
app1 (pid:14926) is running(0:PING_OK), master:acs


# 매니저 프로세스 실행중이지 않을 때
[mha]$ masterha_check_status --conf=/etc/masterha/app1.cnf
app1 is stopped(2:NOT_RUNNING).




masterha_manager

• 매니저 기동 및 모니터링 시작

[mha]$ nohup masterha_manager --conf=/etc/masterha/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 를 통해 조절하시면 됩니다




실행 후 로그 

[mha]$ cd /masterha/app1
[mha]$ tail -100f app1.log


[info] MHA::MasterMonitor version 0.58.

[info] Alive Servers:
[info] acs(192.168.56.51:3306)
[info] acs2(192.168.56.52:3306)
[info] acs3(192.168.56.56:3306)

[info] Alive Slaves:
[info] acs2(192.168.56.52:3306) Version=5.7.31-log log-bin:enabled
[info] Replicating from acs(192.168.56.51:3306)
[info] Primary candidate for the new Master (candidate_master is set)
[info] acs3(192.168.56.56:3306) Version=5.7.31-log log-bin:enabled
[info] Replicating from acs(192.168.56.51:3306)
[info] Primary candidate for the new Master (candidate_master is set)
[info] Current Alive Master: acs(192.168.56.51:3306)
[info] Checking slave configurations..


[info] Starting SSH connection tests..
[info] All SSH connection tests passed successfully.
[info] Checking MHA Node version..

[info] HealthCheck: SSH to acs is reachable.
[info] Master MHA Node version is 0.58.

[info] Checking recovery script configurations on acs(192.168.56.51:3306)..
[info] Executing command: save_binary_logs --command=test ….
[info] Connecting to mha@192.168.56.51(acs:22)..

Binlog found at /usr/local/mysql/logs, up to binlog.000020
[info] Binlog setting check done.
[info] Connecting to mha@192.168.56.52(acs2:22)..

acs(192.168.56.51:3306) (current master)
+--acs2(192.168.56.52:3306)
+--acs3(192.168.56.56:3306)


[info] Checking master_ip_failover_script status:
[info] /masterha/scripts/master_ip_failover …
[info] OK.
[warning] shutdown_script is not defined.
[info] Set master ping interval 3 seconds.
[info] Set secondary check script: /usr/local/bin/masterha_secondary_check
-s acs -s acs2 -s acs3 --user=mha --master_host=acs --master_ip=acs --master_port=3306
Mon Dec 14 03:52:31 2020 - [info] Starting ping health check on acs(192.168.56.51:3306)..
Mon Dec 14 03:52:31 2020 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..





Master 의 VIP 기동

Master 서버 에서 VIP 를 생성 합니다.


[mha]$ sudo ifconfig enp0s3:0 192.168.56.50 up

또는

[mha]$ sudo ifconfig enp0s3:0 mhm-master-vip up




[mha]$ ifconfig -a
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.56.51 netmask 255.255.255.0 broadcast 192.168.56.255


enp0s3:0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.56.50 netmask 255.255.255.0 broadcast 192.168.56.255






장애 상황 테스트 

마스터 서버에서 kill 이나 systemctl 로 mysql 를 종료 합니다.

= 매니저 서버 모니터링 프로세스 유무 확인
[mha]$ ps -ef| grep masterha
mha perl /usr/local/bin/masterha_manager <중략>


= 마스터 서버, MySQL 중지
[root]# systemctl stop mysqld




= MHA 모니터링 로그

reachable, Master is not reachable from acs2. OK.
reachable, Master is not reachable from acs3. OK.
[info] Master is not reachable from all other monitoring servers. Failover should start.

[warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.56.51' (111))

[warning] Connection failed 2 time(s)..
[warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.56.51' (111))
[warning] Connection failed 3 time(s)..
[warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.56.51' (111))
[warning] Connection failed 4 time(s)..

[warning] Master is not reachable from health checker!
[warning] Master acs(192.168.56.51:3306) is not reachable!

[info] Dead Servers:
[info] acs(192.168.56.51:3306)
[info] Alive Servers:
[info] acs2(192.168.56.52:3306)
[info] acs3(192.168.56.56:3306)

[info] Alive Slaves:

[info] acs2(192.168.56.52:3306) Version=5.7.31-log (oldest major version between slaves) log-bin:enabled
[info] Replicating from acs(192.168.56.51:3306)
[info] Primary candidate for the new Master (candidate_master is set)
[info] acs3(192.168.56.56:3306) Version=5.7.31-log (oldest major version between slaves) log-bin:enabled
[info] Replicating from acs(192.168.56.51:3306)
[info] Primary candidate for the new Master (candidate_master is set)
[info] Replication filtering check ok.
[info] Master is down!
[info] Terminating monitoring script.
[info] Got exit code 20 (Master dead).
[info] MHA::MasterFailover version 0.58.
[info] Starting master failover.

[info] * Phase 1: Configuration Check Phase..
[info] GTID failover mode = 0
[info] Dead Servers:
[info] acs(192.168.56.51:3306)
[info] Checking master reachability via MySQL(double check)…
[info] ok.
[info] Alive Servers:
[info] acs2(192.168.56.52:3306)
[info] acs3(192.168.56.56:3306)
[info] Alive Slaves:
[info] acs2(192.168.56.52:3306) Version=5.7.31-log  log-bin:enabled
[info] Replicating from acs(192.168.56.51:3306)
[info] Primary candidate for the new Master (candidate_master is set)
[info] acs3(192.168.56.56:3306) Version=5.7.31-log  log-bin:enabled
[info] Replicating from acs(192.168.56.51:3306)
[info] Primary candidate for the new Master (candidate_master is set)
[info] * Phase 3: Master Recovery Phase..
[info]
[info] * Phase 3.1: Getting Latest Slaves Phase..
[info]
[info] The latest binary log file/position on all slaves is binlog.000020:154
[info] Latest slaves (Slaves that received relay log files to the latest):
[info] acs2(192.168.56.52:3306) Version=5.7.31-log (oldest major version between slaves) log-bin:enabled
[info] Replicating from acs(192.168.56.51:3306)
[info] Primary candidate for the new Master (candidate_master is set)
[info] acs3(192.168.56.56:3306) Version=5.7.31-log (oldest major version between slaves) log-bin:enabled
[info] Replicating from acs(192.168.56.51:3306)
[info] Primary candidate for the new Master (candidate_master is set)
[info] The oldest binary log file/position on all slaves is binlog.000020:154
[info] Oldest slaves:
[info] acs2(192.168.56.52:3306) Version=5.7.31-log (oldest major version between slaves) log-bin:enabled
[info] Replicating from acs(192.168.56.51:3306)
[info] Primary candidate for the new Master (candidate_master is set)
[info] acs3(192.168.56.56:3306) Version=5.7.31-log (oldest major version between slaves) log-bin:enabled
[info] Replicating from acs(192.168.56.51:3306)
[info] Primary candidate for the new Mast
[info] New master is acs2(192.168.56.52:3306)
[info] Starting master failover..


From:
acs(192.168.56.51:3306) (current master)
+--acs2(192.168.56.52:3306)
+--acs3(192.168.56.56:3306)

To:
acs2(192.168.56.52:3306) (new master)
+--acs3(192.168.56.56:3306)



[info] Executing master IP activate script:
Set read_only=0 on the new master.


Getting new master's binlog name and position..
binlog.000073:30820278
All other slaves should start replication from here.
Statement should be: CHANGE MASTER TO MASTER_HOST='acs2 or 192.168.56.52',
MASTER_PORT=3306, MASTER_LOG_FILE='binlog.000073', MASTER_LOG_POS=30820278,
MASTER_USER='repl_user', MASTER_PASSWORD='xxx';


VIP IS Alive,VIP Relocate acs2
ARPING 192.168.56.50 from 192.168.56.50 enp0s3
Sent 5 probes (5 broadcast(s))
Received 0 response(s)
[info] OK.



[info] Master failover to acs2(192.168.56.52:3306) completed successfully.
[info]



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

app1: MySQL Master failover acs(192.168.56.51:3306) to acs2(192.168.56.52:3306) succeeded


Master acs(192.168.56.51:3306) is down!

Check MHA Manager logs at wmp:/masterha/app1/app1.log for details.

Started automated(non-interactive) failover.
Invalidated master IP address on acs(192.168.56.51:3306)
The latest slave acs2(192.168.56.52:3306) has all relay logs for recovery.
Selected acs2(192.168.56.52:3306) as a new master.
acs2(192.168.56.52:3306): OK: Applying all logs succeeded.
acs2(192.168.56.52:3306): OK: Activated master IP address.
acs3(192.168.56.56:3306): This host has the latest relay log events.
Generating relay diff files from the latest slave succeeded.
acs3(192.168.56.56:3306): OK: Applying all logs succeeded. Slave started, replicating from acs2(192.168.56.52:3306)
acs2(192.168.56.52:3306): Resetting slave info succeeded.
Master failover to acs2(192.168.56.52:3306) completed successfully.



장애가 발생시 정상적으로 failover 가 이루어지면 위와 같은 내역으로 수행되게 됩니다.

현재 failover 에 의해서 New Master 서버는 2번째(acs2) 가 되었으며 3번째(acs3) 서버는 2번 서버를 마스터로 바라보면서 복제가 수행 중입니다.


그리고 장애가 발생되어 failover가 되게 되면 매니저서버에서 구동중인 매니저 프로세스(모니터링) 은 종료되게 됩니다([info] Terminating monitoring script.)


다시 모니터링을 하기 위해서는 1번 서버 마스터 서버의 정상화 후 설정을 해야 합니다.


다시 정상화를 위해서 1번 서버를 현재 마스터 서버인 2번 서버로 설정하여 정상적으로 replication  설정을 해야 합니다.




1번 서버 신규 마스터로 복제 설정

먼저 종료된 mysql 를 기동 합니다.

[root]# systemctl start mysqld
[root]# mysql --login-path=dba



CHANGE MASTER 실행

CHANGE MASTER 를 하기 위해서 MASTER_LOG_FILE, MASTER_LOG_POS 정보가 필요 합니다. 해당 정보는 failover 로그에서 "All other slaves should start replication from here" 항목에서 확인 할 수 있습니다.

All other slaves should start replication from here. 
Statement should be: CHANGE MASTER TO MASTER_HOST='acs2 or 192.168.56.52', 
MASTER_PORT=3306, MASTER_LOG_FILE='binlog.000073', MASTER_LOG_POS=30820278, 
MASTER_USER='repl_user', MASTER_PASSWORD='xxx';


위의 로그 상의 정보로 CHANGE MASTER 를 실행 합니다.

mysql> CHANGE MASTER TO MASTER_HOST='acs2',
MASTER_USER='repl_user',
MASTER_PASSWORD='repl_user',
MASTER_LOG_FILE='binlog.000073',
MASTER_LOG_POS=30820278;

mysql> start slave;

mysql> show slave status\G

Slave_IO_State: Waiting for master to send event
Master_Host: acs2
Master_User: repl_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000073
Read_Master_Log_Pos: 30820278
Relay_Log_File: relay_log.000002
Relay_Log_Pos: 317
Relay_Master_Log_File: binlog.000052
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
<중략>





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

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






app1.log 로그 내역

[mha]$ tail -100f app1.log

<중략>
Mon Dec 14 05:33:23 2020 - [info] Slaves settings check done.
Mon Dec 14 05:33:23 2020 - [info]
acs2(192.168.56.52:3306) (current master)
+--acs(192.168.56.51:3306)
+--acs3(192.168.56.56:3306)
<중략>






masterha_master_switch

사용자 임의의 Take-Over(Relocate) 수행

switch 명령어를 통해서 예약된 작업 등의 사유로 계획된 take over(relocate) 를 할 수 있습니다.


중요한점은 switch 시 매니저의 모니터링을 중지 해야 합니다.


acs2(192.168.56.52:3306) (current master)
+--acs(192.168.56.51:3306)
+--acs3(192.168.56.56:3306)


현재 마스터는 두번째 서버 입니다(acs2)
마스터를 1번으로 relocate 하도록 하겠습니다.





매니저(모니터링) 종료 

[mha]$ masterha_stop --conf=/etc/masterha/app1.cnf

[mha]$ masterha_check_status --conf=/etc/masterha/app1.cnf
app1 is stopped(2:NOT_RUNNING).




take over 수행

=매니저 서버에서 수행

take over 전에 replication 상태를 한번 체크 합니다.
[mha]$ masterha_check_repl --conf=/etc/masterha/app1.cnf

take over(switch) 를 실행 합니다(acs2 -> acs )
[mha]$ masterha_master_switch --master_state=alive \

--conf=/etc/masterha/app1.cnf --new_master_host=acs \
--interactive=0



옵션 설명

--master_state=alive | dead

master 서버가 장애로 인하여 수동적인 failover 를 하는 것이라면 --master_state=dead 라고 옵션을 사용해야 합니다.
master 서버가 정상이라면 alive 라고 입력 합니다.


--new_master_host=호스트명

새로운 마스터가 될 호스트명 입력


--interactive=0 | 1

1번은 대화형으로 진행(default) 이며, 0번은 비대화식




take over 실행 로그 

[info] Starting online master switch..

[info] * Phase 1: Configuration Check Phase..

[info] Reading application default configuration from /etc/masterha/app1.cnf..

[info] Reading server configuration from /etc/masterha/app1.cnf..

[info] Current Alive Master: acs2(192.168.56.52:3306)

[info] Alive Slaves:
[info] acs(192.168.56.51:3306) Version=5.7.31-log (oldest major version between slaves) log-bin:enabled
[info] Replicating from acs2(192.168.56.52:3306)
[info] Primary candidate for the new Master (candidate_master is set)
[info] acs3(192.168.56.56:3306) Version=5.7.29-log (oldest major version between slaves) log-bin:enabled
[info] Replicating from acs2(192.168.56.52:3306)
[info] Primary candidate for the new Master (candidate_master is set)

[info] Checking MHA is not monitoring or doing failover..

[info] Checking replication health on acs..
[info] ok.
[info] Checking replication health on acs3..
[info] ok.
[info] acs can be new master.

From:

acs2(192.168.56.52:3306) (current master)
+--acs(192.168.56.51:3306)
+--acs3(192.168.56.56:3306)

To:

acs(192.168.56.51:3306) (new master)
+--acs3(192.168.56.56:3306)


Mon Dec 14 05:46:45 2020 - [info] Checking whether acs(192.168.56.51:3306) is ok for the new master..

All other slaves should start replication from here.
Statement should be:
CHANGE MASTER TO MASTER_HOST='acs or 192.168.56.51',
MASTER_PORT=3306, MASTER_LOG_FILE='binlog.000088',
MASTER_LOG_POS=1195, MASTER_USER='repl_user',
MASTER_PASSWORD='xxx';

VIP IS Alive,VIP Relocate acs
ARPING 192.168.56.50 from 192.168.56.50 enp0s3
Sent 5 probes (5 broadcast(s))
Received 0 response(s)


[info] * Phase 5: New master cleanup phase..

[info] acs: Resetting slave info succeeded.
[info] Switching master to acs(192.168.56.51:3306) completed successfully.


이렇게 하면 1번 서버가 마스터서버가 되었으며, 3번 서버(슬레이브)는 1번 서버를 마스터로 복제를 수행되게 됩니다.

다시 정상화 하기 위해서는 2번 서버를 1번 마스터 서버를 바라보고 복제가 수행될 수 있도록 설정을 해야 합니다.





2번 서버에서 새로운 마스터로 복제 설정

마스터의 정보를 확인 하기 위해서는 failover 와 마찬가지로 로그상에서 "All other slaves should start replication from here" 항목을 참조하시면 됩니다.

All other slaves should start replication from here. 
Statement should be: 
CHANGE MASTER TO MASTER_HOST='acs or 192.168.56.51', 
MASTER_PORT=3306, MASTER_LOG_FILE='binlog.000088', 
MASTER_LOG_POS=1195, MASTER_USER='repl_user', 
MASTER_PASSWORD='xxx';


위의 로그를 참조하여 CHANGE MASTER 를 수행 합니다.
mysql> CHANGE MASTER TO MASTER_HOST='acs',
MASTER_USER='repl_user',

MASTER_PASSWORD='repl_user',
MASTER_LOG_FILE='binlog.000088',

MASTER_LOG_POS=1195;
mysql> start slave;
mysql> show slave status\G





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

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





purge_relay_logs



MHA 에서는 relay_log_purge 기능의 비활성화(0,off,false) 권장이고 fail-over 나 switch-over 시 purge가 수행됩니다. 그외 별도로 purge 가 필요한 경우 MHA 내에 제공되는 스크립트를 통해서 간단하게 수행할 수 있습니다.

스크립트는 /usr/local/bin/purge_relay_logs 이며 실행 방법은 아래와 같습니다

/usr/local/bin/purge_relay_logs \
--user=mha --password=mha \
--disable_relay_log_purge --port=3306

* mysql 을 접속 할 수 있는 OS 유저로 수행


스크립트는 아래의 내용이 수행되게 됩니다.

relay_log_purge 기능 활성화 및 FLUSH LOGS 를 수행합니다.
1. Executing SET GLOBAL relay_log_purge=1;
2. FLUSH LOGS;


위의 명령어 수행 후 다시 relay_log_purge 기능 비활성화로 변경합니다.

3. SET GLOBAL relay_log_purge=0;


명령어를 커맨드 라인에서 수행해도 되고 스크립트로 만들어서 수행 및 crontab 에 등록하여 주기적으로 relay 로그를 삭제 할수도 있습니다

root 유저로 생성하면 되며 파일명 및 경로는 아래와 같습니다.
/etc/masterha/clean_relay_log.sh

파일명 이나 경로는 예시임으로 다른 경로와 파일명을 사용하여도 됩니다.

#!/bin/bash
CRL_USER=mha
CRL_PASSWORD=mha
CRL_PORT=3306
log_dir='/masterha/app1'
work_dir='/masterha/app1'
purge='/usr/local/bin/purge_relay_logs'
if [ ! -d $log_dir ]
then
   mkdir $log_dir -p
fi
$purge --user=$CRL_USER --password=$CRL_PASSWORD --disable_relay_log_purge --port=$CRL_PORT  >> $log_dir/purge_relay_logs.log 2>&1


* 스크립트내 CRL_USER 와 CRL_PASSWORD 변수에 DB 계정과 패스워드를 입력하면 됩니다.


• 생성후 실행 권한 부여
[root]# chmod 755 /etc/masterha/clean_relay_log.sh


• crontab 에 등록시 - 6시간 마다 예시
0 6 * * * /etc/masterha/clean_relay_log.sh





conclusion



MySQL MHA(Master High Availability) 는 장애시 사람이 일일이 수 작업으로 하기 힘든 작업에 대해서 자동화로 수행되도록 개발되었습니다.


Master 서버의 장애시 빠르게 대응하여 수초 안으로 failover 가 이루어지며 1대 N 구조안 다수의 슬레이브인 환경에서 서버 별 복제의 Gap 차이의 복구 및 Replication 정보 수정등의 작업을 자동적으로 수행하게 됩니다.


많은 곳에서 오래전부터 사용하던 툴로 안정성이나 기능면에서는 매우 좋다고 생각 됩니다.

MySQL Replication 환경에서는 이런류의 가용성 솔루션을 사용하는 것이 빠른 장애 처리와 복구에 많은 도움이 될거라고 생각 됩니다.


Ref link.
https://github.com/yoshinorim/mha4mysql-manager
https://github.com/yoshinorim/mha4mysql-node

https://github.com/yoshinorim/mha4mysql-manager/wiki
https://www2.slideshare.net/matsunobu/automated-master-failover


Book
DBA를 위한 MySQL 운영 기술



연관된 글

 

“MySQL MHA(Master High Availability) 2 - 설치 및 구성” 에 대한 4 댓글

  1. 안녕하세요.
    다른 게시글들 보다 더 이해하기 쉽게 설명해 주시고 작성해주셔서 감사합니다.
    이번 기회를 통해 MHA에 대하여 제가 잘못 알고있던 아키텍쳐들도 있었는데 다시 테스트를 해보면서 기존에 몰랐던 새로운 설정들도 천천히 정독하면서 알아가야 겠습니다^^
    추가로 윗글에 추천해주신 책을 구매하여 MySQL에 대해 더 접근하고 공부하는 계기가 되었으면 좋곘네요

    감사합니다.

  2. 와~ 저도 삽질 많이 하면서 구축했는데 여기에 꼭 필요한 내용들이 많이 담겨있네요~
    공유 감사합니다~

답글 남기기