Last Updated on 3월 31, 2022 by Jade(정현호)
안녕하세요
이번 포스팅에서는 Orchestrator 에서 VIP 를 사용하는 부분 과 Takeover 시 Slave 의 Replication Auto Start 관련 한 내용을 확인 해 보도록 하겠습니다.
아래 이전 글에서 이어지는 연재 글로 설치 및 구성 환경은 이전 글을 참조하시면 됩니다.
• Orchestrator 1 - 기능 설명 및 설치
• Orchestrator 2 - 리팩토링 Failover Automated Recovery
Contents
사전 선행 작업
포스팅에서 진행하는 내역을 위해서는 몇 가지 선행적으로 수행해야 할 내역이 있습니다. 그 중에서는 꼭 진행해야 하는 내역과 옵션 적인 부분으로 나뉘게 됩니다.
일반 유저 생성
orchestrator 실행 및 vip 의 up/down 을 할 별도의 일반 유저를 생성 하여 진행 하도록 하겠습니다.
일반 유저의 생성은 필수는 아니며, root 유저로 사용하여도 됩니다.
다만 아래에서 진행하는 ssh 키 생성 및 ssh 키 전송은 root 유저도 작업이 필요 합니다
유저 생성
orchestrator 및 모든 MySQL DB 서버 에서 생성하도록 하겠습니다. 포스팅에서는 생성시 gid 및 uid 에 대해서 모든 서버가 맞추기 위해서 3000 으로 명시적으로 생성하였습니다.
orchestrator 및 모든 MySQL DB 서버 에서 생성을 합니다.
~]# groupadd -g 3000 orchestrator ~]# useradd -g orchestrator -u 3000 orchestrator ~]# passwd orchestrator Changing password for user orchestrator. New password: [패스워드입력]
* 유저명은 꼭 orchestrator 으로 사용하지 않아도 됩니다. 사용하기 편한 유저 명을 생성하여 사용하면 됩니다
sudo 권한
일반 유저로 사용하면서 root 권한이 필요함으로 필요한 명령어 에 대해서 sudo 를 설정 하도록 하겠습니다.
orchestrator 서버와 MySQL 인스턴스 서버에서 각각 다른 내용으로 설정을 진행 하도록 하겠으며 경로 와 파일을 공통적으로 동일하게 아래와 같이 생성하도록 하겠습니다.
/etc/sudoers.d/orchestrator
• orchestrator 서버
~]# vi /etc/sudoers.d/orchestrator orchestrator ALL= NOPASSWD:/bin/systemctl start orchestrator,/bin/systemctl restart orchestrator,/bin/systemctl stop orchestrator
• MySQL 인스턴스 서버
~]# vi /etc/sudoers.d/orchestrator orchestrator ALL=(ALL) NOPASSWD:/sbin/ifconfig
orchestrator 서버에서 설정한 내용은 systemctl 명령어에 대한 sudo 사용을 설정한 것이고, MySQL 인스턴스 서버에는 ifconfig 명령어 에 대해서 sudo 를 설정한 것 입니다.
환경 변수 및 SSH 키 전송
환경 변수 설정
위에서 생성한 orchestrator 에 대해서 환경 변수 를 설정 하도록 하겠습니다.
-- orchestrator 로 유저 변경 ~]# su - orchestrator -- 환경 변수 추가 ~]$ echo "export PATH=\$PATH:/usr/local/mysql/bin" \ >> ~/.bash_profile -- 환경 변수 추가,orchestrator 서버에서만 실행 합니다 ~]$ echo "export ORCH_HOME=/usr/local/orchestrator" \ >> ~/.bash_profile -- 환경변수 적용 ~]$ source ~/.bash_profile
중간에 기술된 /usr/local/mysql/bin 은 MySQL 설치 경로 및 실행파일의 위치에 PATH 를 설정한 것 입니다.
설치한 환경에 따라서 경로가 다르거나 rpm 으로 설치시 PATH 설정이 불필요 할 수 있습니다.
ORCH_HOME 환경변수는 orchestrator 서버에서만 추가 합니다
SSH Key 생성
SSH Key는 orchestrator 서버에서만 생성한 일반 유저 orchestrator 에서 실행 하면 됩니다.
* 해당 작업은 일반유저를 생성하지 않고 root 유저로 사용시에도 필요한 작업입니다
* 기존의 키가 생성되어 있다면 키 생성 과정은 생략 하여도 됩니다
생성 명령어 : ssh-keygen -t rsa -b 4096
[orchestrator ~]$ ssh-keygen -t rsa -b 4096 Generating public/private rsa key pair. Enter file in which to save the key (/home/orchestrator/.ssh/id_rsa): [엔터] Created directory '/home/orchestrator/.ssh'. Enter passphrase (empty for no passphrase): [엔터] Enter same passphrase again: [엔터] Your identification has been saved in /home/orchestrator/.ssh/id_rsa. Your public key has been saved in /home/orchestrator/.ssh/id_rsa.pub. The key fingerprint is: SHA256:J52+2342342sdfasf orchestrator@xxxx The key's randomart image is: +---[RSA 4096]----+ |xxxxxxxx .. | |.xxxxxx.. | | o.xxxxxxx | |+xxxxxxxxx . | |=..xxxxxx + | |+.. . o.++ | |.xxxxxxxxxxx | | xxxxxxxxxxxx | | xxxxxxxx | +----[SHA256]-----+
공개키 전송(Copy)
생성 한 공개키(.pub)를 MySQL 모든 서버로 전송 합니다. vip 를 up/down 을 위해서 패스워드 없이 ssh 접속을 하기 위한 설정 입니다.
orchestrator 서버에서 -> MySQL 인스턴스 서버로 키를 전송 하면 됩니다.
* 해당 작업은 일반유저를 생성하지 않고 root 유저로 사용시에도 필요한 작업입니다
ssh-copy-id 를 이용하면 되며 아래와 같이 수행 합니다.
orchestrator 서버에서 acs 호스트 서버로 전송을 의미 합니다
명령어 : ssh-copy-id -i 전송할_서버_호스트(또는 IP)
~]$ ssh-copy-id -i acs orchestrator@acs's password: [orchestrator의 패스워드 입력] 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.
공개키 전송이 완료 되었다면 패스워드 없이 접속이 되는지 확인 해봅니다.
~]$ ssh acs date Sat Aug 21 20:00:00 KST 2021 ~]$ ssh acs hostname acs
위와 같은 방법으로 다른 MySQL 서버에도 키를 전송 합니다.
추가 패키지 설치
MySQL 서버에서 root 유저로 아래 2개 패키지를 설치 합니다. 해당 패키지 설치는 꼭 필요한 패키지 입니다.
* RHEL/CentOS/Oracle Linux 의 RPM 계열의 패키지 명으로 데비안 계열은 패키지명이 다릅니다.
~]# yum -y install iproute net-tools
* 패키지는 이미 설치 되어있을 수 있습니다.
login-path 설정
포스팅에서 사용되는 스크립트에서는 login-path 를 사용한 환경 기준으로 작성되어 있습니다.
login-path 에 대한 자세한 내용은 아래 포스팅을 참조하시면 됩니다.
orchestrator 서버에서 위에서 생성한 orchestrator 일반 유저에서 login-path 를 설정하도록 하겠습니다.
일반 유저를 생성하지 않고 OS root 유저로 사용한다면 OS root 유저에서 login-path 를 설정하면 됩니다.
MySQL 인스턴스 서버에서는 하지 않아도 됩니다.
~]$ mysql_config_editor set \ --login-path=orchuser \ --host=127.0.0.1 \ --user=orchestrator \ --port=3307 --password Enter password: *****
포스팅에서는 orchestrator 의 백엔드(Repository) 에 사용되는 MySQL DB의 포트를 3307로 사용 중입니다.
그래서 위의 login-path 생성시 3307 포트를 기재하여 생성을 진행 하였습니다.
테이블 및 VIP, 호스트 정보 입력
VIP 의 up/down 및 노드간 VIP Relocate 를 수행하기 위한 호스트 와 vip 정보 등을 담고 있는 테이블 생성 과 데이터 입력을 진행하도록 하겠습니다.
테이블 과 데이터 입력은 orchestrator 의 백엔드(Repository) 에 사용되는 MySQL DB 에서 진행 하도록 하겠습니다.
포스팅에서는 login-path 를 설정한 orchestrator 유저에서 MySQL 에 접속하였으나, 다른 방법으로 접속 및 테이블생성,적재 를 진행하여도 됩니다.
-- OS orchestrator 에서 --login-path 로 접속
orchestrator ~]$ mysql --login-path=orchuser
mysql> use orchestrator;
mysql> create table db_ha_vip
(id bigint unsigned not null auto_increment,
clustername varchar(100),
hostname varchar(100),
vip varchar(100),
net varchar(100),
subnet varchar(100),
master_yn varchar(10),
chg_dt datetime,
primary key(id),
unique index ix_clustername_hostname (clustername,hostname));
-- 호스트 와 vip 정보 입력
mysql> insert into db_ha_vip (clustername,hostname,vip,net,subnet,master_yn,chg_dt)
values ('acs_cluster','acs','192.168.56.38','enp0s3','255.255.255.0','Y',now());
mysql> insert into db_ha_vip (clustername,hostname,vip,net,subnet,master_yn,chg_dt)
values ('acs_cluster','acs2','192.168.56.39','enp0s3','255.255.255.0','N',now());
mysql> insert into db_ha_vip (clustername,hostname,vip,net,subnet,master_yn,chg_dt)
values ('acs_cluster','acs3','192.168.56.40','enp0s3','255.255.255.0','N',now());
테이블과 데이터에 대해서 설명 드리면
clustername 은 임의로 지정한 Group명을 넣으면 됩니다. 호스트간에 공통적인 그룹명을 지정하는 의미 입니다.
net 은 Public IP 가 사용되는 ethernet device 를 입력하면 됩니다 해당 device 에 VIP 가 할당 되게 됩니다.
master_yn 에는 현재 기준의 Master VIP 에 Y 를 입력 하면 됩니다.
subnet 의 경우 255.255.255.0(C class) 가 아닐 경우 또는 netmask 를 명시적으로 입력하지 않았을 경우 다른 netmask 로 설정되는 경우가 있어서 명시적으로 입력 하였습니다.
* 위의 테이블과 데이터는 orchestrator 의 공식 가이드 테이블은 아니며 포스팅에서 사용 되는 별도 작성 스크립트를 위한 테이블 과 데이터 입니다.
* 작성하고 사용하는 스크립트에 따라서 테이블의 사용 유무와 내용은 달라 지게 됩니다.
Automated Replication Start
이전 포스팅에서 다룬 Master Promote(Takeover) 관련하여 Slave 를 Master 로 승력 시키고, 기존 Master 인스턴스는 Slave 되는 과정에서 Slave 로 변경 된 이후 아래 이미지와 같이 Replication Start 를 별도로 수행(UI 상에서 또는 명령어 등) 해야 했습니다.
관련 포스팅 항목
• Master Refactoring(Promote)
해당 과정에 대해서 Takeover(마스터 <-> 슬레이브 교체) 시 별다른 조작 없이 Slave 인스턴스의 복제도 바로 시작 할 수 있도록 구성을 하도록 하겠습니다.
자동 복제 시작 스크립트
스크립트 다운로드
다운 로드 받으시거나 서버에서 wget 으로 직접 받으시면 됩니다
• takeover_replication_start.txt
다운로드 받은 파일에서 orchestrator 서버에 /usr/local/orchestrator 경로에 업로드 를 합니다.
파일을 업로드 하였거나 작성 하였다면 실행권한을 부여 합니다.
~]$ cd /usr/local/orchestrator ~]$ chmod 755 takeover_replication_start.sh
파일 수정 및 확인
업로드가 되었다면 스크립트에 대해서 수정 과 확인 해야 할 부분이 있습니다.
1) MySQL 실행 파일 경로
export PATH=$PATH:/usr/local/mysql/bin
orchestrator 에서 백엔드(Repository) 로 사용하는 MySQL 의 실행파일이 있는 bin 디렉토리 위치를 지정하거나 RPM(YUM) 으로 설치시에는 지정하지 않아도 되는 부분 입니다.
2) 로그 경로
failuretype= .../log/detected_failuretype.log
스크립트 상의 읽어 들이는 로그의 경로는 /usr/local/orchestrator/log 로 포스팅에서는 해당 경로를 계속 사용하고 있습니다.
로그 경로 변경에 대해서는 이전 포스팅을 참조하시면 됩니다.
3) login-path
작성 된 스크립트에서 Repository DB(MySQL) 접속시 login-path 사용으로 작성되어 있습니다.
mysql --login-path=orchuser
orchestrator.conf.json 파일 수정
작성된 스크립트를 orchestrator 에서 실행하게 하기 위해서는 orchestrator.conf.json 에서 hooking 되도록 설정을 해야 합니다.
conf.json 파일에서 hooking 을 설정할 수 있는 항목이 아래와 같이 몇 가지가 있습니다.
- OnFailureDetectionProcesses
- PreGracefulTakeoverProcesses
- PreFailoverProcesses
- PostFailoverProcesses
- PostUnsuccessfulFailoverProcesses
- PostIntermediateMasterFailoverProcesses
- PostGracefulTakeoverProcesses
각 파라미터 이름에서 대략 알 수 있는 것 처럼 특정 상황에서 해당 파라미터에 해당 하는 동작을 수행하게 됩니다.
기본적으로 conf.json 에는 로그를 남기는 동작이 이미 설정되어 있습니다.
"echo 'Will recover from {failureType} on {failureCluster}' >> /usr/local/orchestrator/log/recovery.log"
{} 중괄호 로 묶여 있는 것은 Hooks arguments 로써 orchestrator 가 동작시 인자값으로 사용할 수 있는 제공되는 argument 입니다.
Hooks arguments 종류는 공식 문서 - configuration-recovery.md 에서 2. Command line text replacement 항목에서 확인 하실 수 있습니다.
그래서 Takeover 나 장애시 Failover(recovery) 될 때 실행되는 파라미터 항목에 Hooks arguments 를 인자값으로 받는 스크립트를 작성하여 등록 하여 사용하면 되는 것 입니다.
실제 사용시 Hooks arguments 를 이용하여 추가적인 스크립트를 사용하거나 응용하여 수정하시면 더욱 유용하게 orchestrator 를 사용 하실 수 있습니다.
2개 파라미터를 수정하도록 하겠습니다.
- OnFailureDetectionProcesses
- PostGracefulTakeoverProcesses
• OnFailureDetectionProcesses
"OnFailureDetectionProcesses": [
"echo 'Detected {failureType} on {failureCluster}. Affected replicas: {countSlaves}' >> /usr/local/orchestrator/log/recovery.log"
],
TO(아래와 같이 수정)
"OnFailureDetectionProcesses": [
"date +\"%Y%m%d %H:%M:%S\" >> /usr/local/orchestrator/log/recovery.log",
"echo 'Detected {failureType} on {failureCluster}. Affected replicas: {countSlaves}' >> /usr/local/orchestrator/log/recovery.log",
"echo '{failureType}' > /usr/local/orchestrator/log/detected_failuretype.log"
],
• PostGracefulTakeoverProcesses
"PostGracefulTakeoverProcesses": [
"echo 'Planned takeover complete' >> /usr/local/orchestrator/log/recovery.log"
],
TO(아래와 같이 수정)
"PostGracefulTakeoverProcesses": [
"echo 'Planned takeover complete' >> /usr/local/orchestrator/log/recovery.log",
"/usr/local/orchestrator/takeover_replication_start.sh {failedHost} >> /usr/local/orchestrator/log/recovery.log"
],
기존의 파라미터에 추가로 hooking 할 내용을 추가시에 콤마(,) 를 꼭 넣어야 합니다.
원 설정
.... >> /usr/local/orchestrator/log/recovery.log"
설정 추가시
.... >> /usr/local/orchestrator/log/recovery.log",
설정이 완료 되었다면 configuration 파일을 reload 합니다.
이제 Takeover(Promote) 를 진행하면 아래와 같이 UI 나 커멘드로 start replication 을 하지 않아도 위에서 설정한 스크립트에 의해서 복제가 시작 되게 됩니다.
VIP(가상 IP) 설정
Master 인스턴스와 Slave(Replica) 인스턴스에서 사용할 VIP 를 동작시킬 스크립트 및 설정을 진행하도록 하겠습니다
VIP 정책
Orchestrator 나 MHA 와 같은 HA 툴의 경우 Failover 등의 가용성 기능을 제공을 하지만 VIP 리소스 에 대한 기능은 제공하지 않아 별도의 스크립트 등으로 구현 해서 사용 해야 합니다.
물론 위에서와 같이 hooking 이 되는 파라미터 나 스크립트 내 호출 함수 등에 대한 정보, 사용시 수정 해야할 사항 등은 정보가 제공되지만 VIP 를 Assign 하고 Relocate 하는 등의 실제 동작하는 부분에 해당하는 스크립트나 프로그램은 별도로 작성이 필요로 합니다.
VIP 를 동작하고 Relocate 하는 과정에서 운영 정책에 따라서 같이 기동할 것 인지 아니면 기존 VIP는 종료 할 것인지 등의 정책적인 부분도 있어서 동작에 대한 부분은 각 상황에 맞게 별도 작성해서 사용하는 것도 있을 것도 같습니다.
포스팅에서는 VIP 에 대한 정책을 아래와 같이 구성하였습니다.
• VIP 종류 - 2가지
- Master VIP
- Slave(Replica) VIP
• VIP 수 - 호스트별 생성
- Master 노드 1, 슬레이브 노드2 일 경우 VIP 는 3개 존재
• 가상 디바이스 번호
- 가상 IP 를 할당 시 사용하는 디바이스 번호로 마스터 VIP는 0 을, Slave VIP 는 1 로 사용 하였습니다.
- 예시 : 마스터 VIP - enp0s3:0 / 슬레이브 VIP - enp0s3:1
• Master <-> Slave Relocate 시
- Relocate 시 VIP 도 서로 스위치 형태로 변경
- 예) acs 노드(master) <-> acs2 노드(slave) relocate 시
acs 노드 VIP 는 acs2 노드로 이동
acs2 노드 VIP 는 acs 노드로 이동
• Master 가 장애 발생하여 Failover 시
- 장애 발생 시 승격(Promote) 되는 슬레이브 호스트로 VIP 이동
- 장애 발생 된 Master 제외 하고 Slave 가 2개 이상시
-> 승격(Promote) 되는 슬레이브 호스트의 VIP 는 제거됨
- 장애 발생 된 Master 제외 하고 Slave 가 1개 일 경우
-> 승격(Promote) 되는 슬레이브 호스트의 VIP 는 유지 됨
-> 마스터 VIP 와 Slave VIP 가 동시에 Assign 된 상태
- 장애 발생 된 Master 가 복구 되어 Slave 노드로 클러스터에 추가시
-> 별도의 스크립트나 조회를 통해서 Slave VIP 를 Assign 함
• Slave 노드 가 장애 발생 시
- 서버의 재부팅 없이 MySQL 인스턴스만 종료 된 경우
-> 에러를 조치 하고 MySQL 재시작 및 복제 재시작
-> VIP 는 존재하기 때문에 VIP 에 대한 조치는 별도로 없음
- 서버가 재부팅 된 경우
-> 서버 재시작 이후 MySQL 재시작 및 복제 재시작
-> 별도의 스크립트나 조회를 통해서 Slave VIP 를 Assign 함
작성된 스크립트 와 설정은 위와 같은 룰로 수행되게 됩니다. 이중에서 더 자세히 설명할 부분은 Master 인스턴스의 장애시 상황 일 것 같습니다.
아래와 같이 Slave 2개 이상인 상황에서 마스터 변경시에는 남은 1개의 Slave 가 있기 때문에 승격도 호스트의 VIP 를 제거를 하게 됩니다
마스터 1, 슬레이브1 로 구성된 경우 마스터 인스턴스 장애가 발생하여 Master VIP 를 Failover 후에 승격된 호스트에서 Assign 되어 있는 Slave VIP 를 제거 하게 되면 Slave IP 를 통해서 접속하는 Client 가 접속이 불가한 상태가 발생될수 있기 때문에 이와 같이 승격 후 Slave 노드가 없는 경우에는 Slave VIP 존재 하는 상태에서 Master VIP 를 기동 하게 됩니다.
이와 같은 VIP 룰은 포스팅 테스트 시스템에서 설정한 룰이며, VIP 에 대한 정책은 운영 정책 과 상황에 따라서 정책을 수립 하시면 됩니다
스크립트 다운로드 및 설정
스크립트 다운로드
다운 로드 받으시거나 서버에서 wget 으로 직접 받으시면 됩니다
• vip_change.txt
다운로드 받은 파일에서 orchestrator 서버에 /usr/local/orchestrator 경로에 업로드 를 합니다.
파일을 업로드 하였거나 작성 하였다면 실행권한을 부여 합니다.
~]$ cd /usr/local/orchestrator ~]$ chmod 755 vip_change.sh
1) MySQL 실행 파일 경로
export PATH=$PATH:/usr/local/mysql/bin
orchestrator 에서 백엔드(Repository) 로 사용하는 MySQL 의 실행파일이 있는 bin 디렉토리 위치를 지정하거나 RPM(YUM) 으로 설치시에는 지정하지 않아도 되는 부분 입니다.
2) 로그 경로
failuretype= .../log/detected_failuretype.log
스크립트 상의 읽어 들이는 로그의 경로는 /usr/local/orchestrator/log 로 포스팅에서는 해당 경로를 계속 사용하고 있습니다.
3) login-path
작성 된 스크립트에서 Repository DB(MySQL) 접속시 login-path 사용으로 작성되어 있습니다.
mysql --login-path=orchuser
conf.json hooking 추가 설정
위에서 orchestrator.conf.json 파일을 수정하여 hooking 을 설정한 부분에 대해서 추가적으로 더 설정하도록 하겠습니다
스크립트에서 사용하는 파라미터 아래 3개 입니다.
- OnFailureDetectionProcesses
- PreGracefulTakeoverProcesses
- PostFailoverProcesses
OnFailureDetectionProcesses 는 위에서 이미 설정하였기 때문에 생략 하고 PreGracefulTakeoverProcesses 과 PostFailoverProcesses 를 설정하도록 하겠습니다.
• PreGracefulTakeoverProcesses
"PreGracefulTakeoverProcesses": [
"echo 'Planned takeover about to take place on {failureCluster}. Master will switch to read_only' >> /usr/local/orchestrator/log/recovery.log"
],
TO (아래와 같이 수정)
"PreGracefulTakeoverProcesses": [
"echo 'Planned takeover about to take place on {failureCluster}. Master will switch to read_only' >> /usr/local/orchestrator/log/recovery.log",
"echo 'planned_takeover' > /usr/local/orchestrator/log/planned_takeover.log"
],
• PostFailoverProcesses
"PostFailoverProcesses": [
"echo '(for all types) Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Successor: {successorHost}:{successorPort}' >> /usr/local/orchestrator/log/recovery.log"
],
TO (아래와 같이 수정)
"PostFailoverProcesses": [
"echo '(for all types) Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Successor: {successorHost}:{successorPort}' >> /usr/local/orchestrator/log/recovery.log",
"/usr/local/orchestrator/vip_change.sh {failedHost} {successorHost} >> /usr/local/orchestrator/log/vip_change.log"
],
설정이 완료 되었다면 conf.json 파일을 reload 합니다.
VIP Relocate 확인
이제 Promote(승격, Takeover) 및 마스터 DB 인스턴스를 종료하여 정상적으로 Automated Recovery(Failover) 와 VIP Relocate 가 실행되는지 확인 해 보도록 하겠습니다.
Promote(Takeover)
Slave 인스턴스와 마스터 인스턴스 간의 Takeover 를 수행해보도록 하겠습니다.
Takeover 시 인스턴스의 role이 변경됨에 따라 VIP 도 서로간의 switch 형태로 변경 됩니다.
아래는 포스팅 테스트 시스템의 /etc/hosts 의 설정 내역 입니다.
192.168.56.41 acs
192.168.56.42 acs2
192.168.56.46 acs3
192.168.56.104 orch-server
192.168.56.38 acs-ha-vip
192.168.56.39 acs2-ha-vip
192.168.56.40 acs3-ha-vip
마스터인 acs 호스트와 슬레이브인 acs2 호스트 간에 Takeover 를 실행 하도록 하겠습니다
IP 192.168.56.38 와 192.168.56.39 가 서로 변경 될 것입니다
Recovery(Failover)
장애가 발생된 MySQL 인스턴스를 다시 원복(acs 호스트를 마스터 인스턴스로) 후 이번에는 마스터 인스턴스의 장애(shutdown) 을 발생 시켜보도록 하겠습니다.
~]# systemctl stop mysqld ~]# ps -ef | grep mysqld | grep -v mysqld ~]#
failover 되면 정해진 룰에 따라서 장애 발생시 Failover 가 수행 되며, Master VIP 가 Relocate 가 된 것을 확인 할 수 있습니다.
Master VIP : 192.168.56.38
Assign VIP
장애가 복구 된 후 이전의 MySQL 인스턴스를 복제 설정하여 복제 Set(클러스터) 에 포함 후에 해당 DB 인스턴스에 접속하기 위한 Slave VIP 가 다시 Assign 이 필요 합니다.
별도의 조회나 명령어 등으로 if-up 을 할 수도 있고 여러 방법으로 VIP 를 할당 할 수는 있습니다.
포스팅에서는 아래의 스크립트를 통해서 Slave VIP 할당을 사용하였습니다.
스크립트
다운 로드 받으시거나 서버에서 wget 으로 직접 받으시면 됩니다
• mysql_inst_vip_up.txt
* 해당 스크립트는 여러 방법 중 하나의 입니다.
여기 까지 MySQL Orchestrator 에 대해서 마스터 DB의 승격(Promote) 시 Slave 의 자동 복제 시작(Automated Replication Start) 과Orchestrator 에서 VIP 사용에 대해서 확인 해보았습니다.
다음 포스팅에서는 Orchestrator 인증 설정 및 Proxy 를 통한 접속에 대해서 확인 해보도록 하겠습니다.
이어지는 다음 글
관련된 다른 글
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
안녕하세요 해당 툴은 처음 접하였는데 디테일하고 친절한 설명 덕분에 도움이 많이 되었습니다. 감사합니다.
혹시 DB분야에서 MHA만큼 HA 구성으로 자주 사용되고 있는지 궁금합니다!
초보자에게도 이해하기 쉽도록 포스팅 해주셔서 다시 한번 감사드립니다!!
사실 HA에 대한 사용 통계 정보가 어디나와있는것은 없어서 얼만큼인 차이라고 명확한 정보는 알수 없지만 MHA가 더 많이 사용될걸로 예상이 됩니다.