MySQL Orchestrator - HA(High Availability) - 3 - VIP 설정 - 자동 Replication 설정

Share

Last Updated on 3월 31, 2022 by Jade(정현호)

안녕하세요 
이번 포스팅에서는 Orchestrator 에서 VIP 를 사용하는 부분 과 Takeover 시 Slave 의 Replication Auto Start 관련 한 내용을 확인 해 보도록 하겠습니다. 


아래 이전 글에서 이어지는 연재 글로 설치 및 구성 환경은 이전 글을 참조하시면 됩니다.
  • Orchestrator 1 - 기능 설명 및 설치
  • Orchestrator 2 - 리팩토링 Failover Automated Recovery


사전 선행 작업

포스팅에서 진행하는 내역을 위해서는 몇 가지 선행적으로 수행해야 할 내역이 있습니다. 그 중에서는 꼭 진행해야 하는 내역과 옵션 적인 부분으로 나뉘게 됩니다.
     

일반 유저 생성

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 를 통한 접속에 대해서 확인 해보도록 하겠습니다.


이어지는 다음 글




관련된 다른 글

 

 

 

 



2
0
글에 대한 당신의 생각을 기다립니다. 댓글 의견 주세요!x