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

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

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

About Orchestrator

MySQL Orchestrator 는 MySQL 에 대한 복제 상태의 토폴로지 구성, 장애에 대한 고가용성 지원, 시각화 기능 을 지원하는 오픈소스 MySQL 고가용성 솔루션 입니다. 




포스팅 시점에서 작성된 Languages 분포도는 아래와 같으며 주요 언어는 Go 언어로 작성되어 있습니다.

Go 70.6%  JavaScript 13.3%
Python 9.8%  Shell 5.2%
CSS 0.8%  Ruby 0.2%
Dockerfile 0.1%


Orchestrator 는 크게 3가지의 기능 및 특징을 가지고 있습니다.

• Discovery
     디스커버리는 복제 구성이 된 MySQL 에 대해서 적극적으로 탐색하고 매핑을 하며 복제 상태 및 MySQL 기본 정보를 읽게 됩니다. 
     또한 장애 발생 시에도 복제의 문제를 포함하여 정보를 파악하며 해당 정보를 토폴로지에 반영하여 시각화를 하게 됩니다.


• Refactoring
     Orchestrator 는 MySQL 의 복제 규칙을 이해 하며, binlog file:position, GTID,Pseudo GTID, Binlog Server 등의 정보를 알고 있습니다.
     구성된 복제 상태에 대한 리팩토링 기능을 지원하며 relocate 등과 같은 복제 노드의 이동 등에 대해서 기능을 지원 하고 있습니다.





• Recovery
     마스터 및 중간 마스터 서버의 장애를 감지하기 위해 전체론적(holistic) 접근 방식을 사용 하게 됩니다.
     토폴로지 에서 얻은 정보를 기반으로 다양한 장애 시나리오 대해서 인식 하게 됩니다.
     설정에서 자동 복구를 수행하도록 선택 할 수 있으며 또는 사용자가 수동 복구 유형을 선택 할 수 있습니다
     Orchestrator 는 복구 시간에 대한 토폴로지 평가 및 조사 하여 최적의 복구 방법을 선택 합니다.


자세한 내용은 github orchestrator 사이트를 참조하시면 됩니다.

GitHub - openark/orchestrator: MySQL replication topology management and HA

MySQL replication topology management and HA. Contribute to openark/orchestrator development by creating an account on GitHub.

포스팅 환경

포스팅에서는 아래의 환경에서 진행 하였습니다.

MySQL 버전 : 5.7
Node : 총 4대 
   Orchestrator Node 1대 , Master Server 1대 , Slave(Replica) Server 2대

Orchestrator Ver : 3.2.6

MySQL 구성시 설정한 정보
  - binlog_format = ROW
  - log_slave_updates = ON
  - log-bin
  - master_info_repository = 'TABLE'
  - Parallel Replication 사용 시
    slave_preserve_commit_order=1 로 설정
  - Orchestrator 구성 에서 GTID 사용을 권장 되나 Binlog Position 사용시 Pseudo GTID 를 사용하면 됩니다.
     포스팅에서는 Replication type -  asynchronous , Binlog Position(Pseudo GTID) 으로 구성하였습니다.

Orchestrator 에서 사용되는 Repository DB(backend DB) 는 SQLite 및 MySQL 을 사용할 수 있으며, 포스팅에서는 MySQL 을 사용하였고 5.7 버전을 사용 합니다.


Hostname / IP
 - Orchestrator : 192.168.56.104
 - Master : 192.168.56.41 / acs
 - Slave1 : 192.168.56.42 acs2
 - Slave2 : 192.168.56.46 acs3


MySQL Port
 - 사용 되는 Master / Slave(Replica) 에서는 3306 을 사용하였습니다.
 - Orchestrator 에서 Repository 로 사용되는 MySQL은 3307 포트를 사용하였습니다.
         

MySQL 설치

포스팅에서는 MySQL 5.7 버전을 Binary 방식(tarball) 으로 설치 방식으로 진행하였습니다.

자세한 내용은 아래 포스팅을 참조하시면 됩니다.
 • MySQL 5.7 설치 on CentOS 7
 • MySQL 8 설치 on CentOS 8
 • MySQL 5.7 설치 on Ubuntu(우분투) 18.04


MySQL 설치 및 복제 구성이 완료 되었다면 "Orchestrator 설치" 부터 보시면 됩니다.
         

필요 선행 패키지 설치

EPEL Repository 구성

~]# yum -y install epel-release

패키지 설치

~]# yum -y install ncurses ncurses-devel \
ncurses-libs ncurses-static openssl \
openssl-devel bison readline \
gcc gcc-c++ make cmake glibc \
automake numactl numactl-devel \
libaio libaio-devel curl jq oniguruma

MySQL 설치시 mariadb 라이브러리는 삭제하도록 합니다.

~]# yum remove mariadb-libs

그룹 및 유저 생성

MySQL 데몬 실행을 위한 일반 유저를 생성 합니다.

~]# groupadd mysql 

~]# useradd -M -s /sbin/nologin -g mysql mysql

-M 옵션을 사용해서 홈디렉토리를 생성하지 않고,
-s /bin/false 혹은 /sbin/nologin 옵션을 사용해서 유저의 로그인쉘을 사용할 수 없게 하는 것입니다.

즉 mysql 이라는 유저는 mysql 데몬을 실행하기 위한 유저만으로 사용되고 서버의 보안강화 측면에서 외부에서 mysql 유저로 쉘 로그인을 불가하게 생성하는 것 입니다.
    

설치 진행

Linux Generic 파일(Binary,Tarball) 을 통해 설치를 진행하도록 하겠습니다.


파일 다운로드 및 압축 해제

~]# wget https://dev.mysql.com/get/Downloads/MySQL-5.7/mysql-5.7.31-el7-x86_64.tar.gz

~]# tar zxvf mysql-5.7.31-el7-x86_64.tar.gz -C /usr/local

~]# chown -R mysql:mysql /usr/local/mysql-5.7.31-el7-x86_64

*  버전 및 경로는 예시 입니다.


심볼릭 링크 및 라이브러리 등록

~]# ln -s /usr/local/mysql-5.7.31-el7-x86_64 /usr/local/mysql


~]# echo /usr/local/mysql/lib >> /etc/ld.so.conf

~]# ldconfig

DB 생성 및 패스워드 변경

DB 생성

DB 생성 시 my.cnf 설정 시 아래 내용은 설정이 필요 합니다.
  - server-id : 각 인스턴스별  다르게 설정
  - binlog_format = ROW
  - log_slave_updates = ON
  - log-bin
  - relay-log

그 외 파라미터는 추가적으로 설정해서 사용하시면 되며, 파라미터에 관한 추가 내용은 아래 포스팅을 참조하시면 됩니다.
 • MySQL 5.7 설치 on CentOS 7#my.cnf


root 패스워드 변경

임시 패스워드를 확인 후 root 패스워드를 변경 합니다.

~]# /usr/local/mysql/bin/mysqld_safe &

~]# cd /usr/local/mysql/logs
~]# cat mysqld.err | grep generated
-> root 패스워드가 확인됩니다.

A temporary password is generated for root@localhost: *+345#$q5FyvtZ


~]# /usr/local/mysql/bin/mysql -uroot -p
Enter password: *+345#$q5FyvtZ
-> 패스워드는 위에서 mysqld.err 에서 확인 되는 패스워드 입력 합니다.


mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '변경할패스워드';
mysql> flush privileges;
mysql> exit;

MySQL 복제 구성

Replication 유저 생성

복제 구성에 사용할 유저를 생성 합니다.

mysql> create user 'repl_user'@'%' identified with mysql_native_password by 'repl_user';

mysql> grant replication slave,replication client on *.* to 'repl_user'@'%';

mysql> flush privileges;

* 패스워드 및 호스트 정보는 예시 입니다.


Replication 구성

Slave 노드 에서 복제를 구성 합니다.

mysql> CHANGE MASTER TO
MASTER_HOST='acs',
MASTER_USER='repl_user',
MASTER_PORT=3306,
MASTER_PASSWORD='repl_user';

*  포스팅에서는 구성에 대해서 간략하게 설명되어 있습니다. 자세한 내용은 아래 포스팅을 참조하시면 됩니다.

 • MySQL Replication 구성 및 설정 - Async
 • MySQL Replication - Semi Sync
 • MySQL 복제 문제 발생시 Skip
 • MySQL GTID 를 사용한 Replication 설정
 • MySQL SSL 환경의 복제 구성

Orchestrator 설치

Orchestrator 설치 방식은 아래와 같이 3개의 방식이 있습니다.

• Extract from tarball
• Install from RPM(or DEB)
• Install from repository

Repository 는 tarball 이나 RPM(DEB) 로 설치하는 것보다는 버전이 낮을수 있습니다.

포스팅에서는 패키지 설치 방식으로 진행 하였습니다(RPM)

필요 선행 패키지 설치

EPEL Repository 구성

~]# yum -y install epel-release

패키지 설치

~]# yum -y install ncurses ncurses-devel \
ncurses-libs ncurses-static openssl \
openssl-devel bison readline \
gcc gcc-c++ make cmake glibc \
automake numactl numactl-devel \
libaio libaio-devel curl jq oniguruma

MySQL 설치시 mariadb 라이브러리는 삭제하도록 합니다.

~]# yum remove mariadb-libs

그룹 및 유저 생성

MySQL 데몬 실행을 위한 일반 유저를 생성 합니다.

~]# groupadd mysql

~]# useradd -M -s /sbin/nologin -g mysql mysql

-M 옵션을 사용해서 홈디렉토리를 생성하지 않고,
-s /bin/false 혹은 /sbin/nologin 옵션을 사용해서 유저의 로그인쉘을 사용할 수 없게 하는 것입니다.

즉 mysql 이라는 유저는 mysql 데몬을 실행하기 위한 유저만으로 사용되고 서버의 보안강화 측면에서 외부에서 mysql 유저로 쉘 로그인을 불가하게 생성하는 것 입니다.
          

orchestrator DB 유저 생성

사용하는 MySQL 에 접속하기 위한 유저 와 Repository 에 사용하는 계정을 생성하도록 하겠습니다.
          

MySQL 에 유저 생성

Master 와 Slave 에 모든 DB에서 Orchestrator 에서 접속하여 컨트롤 및 모니터링 용도를 위한 유저를 생성해야 합니다.

mysql> CREATE USER 'orchestrator'@'%' IDENTIFIED BY 'orchestrator';
mysql> GRANT SUPER, PROCESS, REPLICATION SLAVE, RELOAD ON *.* TO 'orchestrator'@'%';
mysql> GRANT SELECT ON mysql.slave_master_info TO 'orchestrator'@'%';

-- pseudo_gtid 를 사용시 권한 부여
mysql> GRANT DROP ON _pseudo_gtid_.* to 'orchestrator'@'%';
mysql> flush privileges;


-- NDB Cluster 구성 되어 있다면 아래 권한도 부여 합니다.
mysql> GRANT SELECT ON ndbinfo.processes TO 'orchestrator'@'%'; 

* 접속 Client의 Host 와 패스워드는 포스팅의 예시 입니다. 


pseudo_gtid 를 사용시 _pseudo_gtid_ 스키마를 생성하지 않아도 됩니다 필요치 않고 생성하지 않아도 됩니다.

Orchestrator will run queries of the form

mysql> drop view if exists `_pseudo_gtid_`.`_asc:5a64a70e:00000001:c7b8154ff5c3c6d8`

[참고] Automated Pseudo-GTID injection 

Orchestrator 에서는 Pseudo-GTID 를 사용할 경우 Automated 방식이 권장 됩니다.
이전 단계에서 실행한 DROP ON _pseudo_git_ 권한 과 아래와 같이 Orchestrator conf 에 설정을 하게 되면 Automated Pseudo-GTID 가 동작 되게 됩니다.

{
"AutoPseudoGTID": true,
}

Orchestrator 에서 아래와 같이 drop view 명령어는 실제 데이터를 삭제하거나 영향을 주는 것은 없으며 바이너리 로그에 명령어를 기록하는 역할로 Magic Maker 역할을 하게 됩니다.

drop view if exists `_pseudo_gtid_`.`_asc:5a64a70e:00000001:c7b8154ff5c3c6d8`

그래서 GTID 를 사용하지 않더라도 Orchestrator 에서는 위와 같은 방식으로 사용 할 수 있습니다.
        

Repository 접속을 위한 계정 생성

Orchestrator 에서 토폴로지 정보 등을 저장하고 조회하는데 사용하는 Repository 용 DB가 필요하며 포스팅에서는 MySQL 로 사용하고 논리 schema 와 유저 생성을 하도록 하겠습니다.

mysql> CREATE DATABASE IF NOT EXISTS orchestrator;

mysql> CREATE USER 'orchestrator'@'127.0.0.1' IDENTIFIED BY 'orchestrator';
mysql> GRANT ALL PRIVILEGES ON `orchestrator`.* TO 'orchestrator'@'127.0.0.1';

* 접속 Client의 Host 와 패스워드는 포스팅의 예시 입니다.
             

Orchestrator 패키지 설치

파일을 아래 링크에서 다운을 받을 수 있습니다.

Releases · openark/orchestrator

MySQL replication topology management and HA. Contribute to openark/orchestrator development by creating an account on GitHub.

아래와 같이 패키지, tarball, Source Code 를 다운 로드 받을 수 있습니다.



설치 및 설정 등은 root 유저로 진행하였습니다.


RPM 설치

~]# rpm -ivh https://github.com/openark/orchestrator/releases/download/v3.2.6/orchestrator-3.2.6-1.x86_64.rpm

orchestrator.conf.json 파일 수정

설치 시 기본 제공 되는 sample 파일을 통해서 conf.json 파일을 작성을 하면 됩니다.

~]# cd /usr/local/orchestrator
~]# cp orchestrator-sample.conf.json orchestrator.conf.json

~]# vi orchestrator.conf.json

conf.json 파일을 아래와 같이 수정을 합니다.

"MySQLOrchestratorHost": "127.0.0.1",
"MySQLOrchestratorPort": 3307,
"MySQLOrchestratorDatabase": "orchestrator",
"MySQLOrchestratorUser": "orchestrator",
"MySQLOrchestratorPassword": "orch_backend_password",
"AutoPseudoGTID": true,
"MySQLTopologyUser": "orchestrator",
"MySQLTopologyPassword": "orch_topology_password",

위의 설정 이외 여러 설정이 있으며 내용은 아래 와 같습니다


backend MySQL server(Repository) 에 접속하기 위한 설정 정보 입니다
 -  MySQLOrchestratorHost
 -  MySQLOrchestratorPort
 -  MySQLOrchestratorDatabase
 -  MySQLOrchestratorUser
 -  MySQLOrchestratorPassword


[참조] MySQLOrchestratorPort 관련
포스팅에서는 Orchestrator 서버에서 Nginx 를 활용하는 내용이 있어서 그에 따라서 Orchestrator 용 Repository DB의 포트를 3307로 사용 중 입니다.

포스팅과 동일하게 테스트를 진행하면서 Orchestrator 용 Repository DB의 포트를 3306 으로 사용을 해야하거나 하고 싶은 경우 Orchestrator 용 Repository DB의 my.cnf 설정에서 port = 3306 , bind-address=127.0.0.1 로 설정 하시면 됩니다.

Repository DB 포트를 변경하여 사용할 경우 Orchestrator 설정(conf.json) 에서 "MySQLOrchestratorPort" 부분을 변경 하시면 됩니다.


실제 사용하는 MySQL DB에 접속하기 위한 계정 정보 입니다.
 -  MySQLTopologyUser
 -  MySQLTopologyPassword


GTID 를 사용하지 않고 binlog Pos 를 사용할 경우 failover 를 위해서 PseudoGTID 사용 해야 하며 AutoPseudoGTID 파라미터 설정을 해야 합니다.
 - "AutoPseudoGTID": true,

해당 파라미터는 conf.json 파일에는 기술되어 있지 않습니다. 별도로 내용을 추가 하여야 합니다.


Recovery 관련 된 로그는 /tmp/recovery.log 파일에 기록이 되게 됩니다.
포스팅에서는 /usr/local/orchestrator/log 으로 변경 하였습니다.

-- 로그 생성 디렉토리 신규 생성
~]# mkdir -p /usr/local/orchestrator/log


-- conf.json 파일의 내용을 일괄 변경
~]# sed -i "s/\/tmp\/recovery.log/\/usr\/local\/orchestrator\/log\/recovery.log/g" orchestrator.conf.json

호스트 Discovery 방식

Orchestrator 에서는 기본적으로 조회되는 호스트로 Orchestrator 서버에서 -> MySQL DB 로 접속을 하는 방식을 사용합니다.

관련된 파라미터는 아래 와 같습니다(orchestrator.conf.json)
"HostnameResolveMethod": "default",
"MySQLHostnameResolveMethod": "@@hostname",

그래서 Orchestrator 서버에서는 DNS 로 IP가 조회되는 환경이거나 /etc/hosts 에 각 서버의 호스트명과 IP를 입력해줘야 정상적으로 사용할 수 있습니다.

포스팅 환경에서는 Orchestrator 서버의 /etc/hosts 에 아래와 같이 설정하고 사용 중입니다.

192.168.56.41 acs
192.168.56.42 acs2
192.168.56.46 acs3

192.168.56.38 acs-ha-vip
192.168.56.39 acs2-ha-vip
192.168.56.40 acs3-ha-vip

192.168.56.98 acs-rw-vip
192.168.56.99 acs-ro-vip


다만 실제 사용시에는 많은 서버를 /etc/hosts 에 등록하기 어려울 수도 있으므로 IP 로만 Discovery 와 연결을 하는 설정으로 사용 할 수도 있습니다.

orchestrator.conf.json 파일에서 아래와 같이 설정하게 되면 항상 IP로만 사용 됩니다.
"HostnameResolveMethod": "none",
"MySQLHostnameResolveMethod": "",

Never resolve, This may appeal to setups where everything uses IP addresses at all times.

그래서 실제 사용하는 환경에서는 IP 로만 사용하는 설정이 더 고려 될 수 있습니다.
       

Orchestrator 시작 및 접속

Orchestrator 를 시작하는 방법을 확인 후 웹 어드민 콘솔 접속을 하도록 하겠습니다.
        

시작 방법

Orchestrator 실행하는 방법은 2가지가 있습니다.
systemd 를 시용한 서비스 형태로 시작 과 orchestrator 실행 하여 사용하는 방법 이 있습니다.

1) systemd service 사용
~]# systemctl start orchestrator


2) orchestrator 실행 사용
~]# cd /usr/local/orchestrator 
~]# ./orchestrator http

orchestrator http 명령어로 실행 하면 foreground 형태로 실행 되며 상세한 내용이 화면에 출력이 됩니다.

~]# ./orchestrator http
DEBUG Connected to orchestrator backend: orchestrator:?@tcp(127.0.0.1:3306)/orchestrator?timeout=1s&readTimeout=30s&rejectReadOnly=false&interpolateParams=true
DEBUG Orchestrator pool SetMaxOpenConns: 128
DEBUG Initializing orchestrator
INFO Connecting to backend 127.0.0.1:3306: maxConnections: 128, maxIdleConns: 32
INFO Starting Discovery
INFO Registering endpoints
INFO continuous discovery: setting up
INFO Starting HTTP listener on :3000
INFO continuous discovery: starting
DEBUG Queue.startMonitoring(DEFAULT)
DEBUG Waiting for 15 seconds to pass before running failure detection/recovery
DEBUG Waiting for 15 seconds to pass before running failure detection/recovery
DEBUG Waiting for 15 seconds to pass before running failure detection/recovery
< ... 내용 중략 ...>

Background 로 실행하기 위해서는 nohup 으로 실행하면 되며 아래와 같은 start , stop 스크립트를 이용하여 실행하여 사용할 수 있습니다.


• start_orchestrator.sh

#!/bin/bash

export MY_ORCH=/usr/local/orchestrator

nohup $MY_ORCH/orchestrator --debug http > $MY_ORCH/log/orchestrator.log 2>&1 &

/bin/cp /dev/null $MY_ORCH/log/orchestrator.pid

/bin/ps -ef | grep "orchestrator --debug http" | grep -v grep | awk '{print $2}' > $MY_ORCH/log/orchestrator.pid


MY_ORCH_PID=`ps -ef | grep "orchestrator --debug http" | grep -v 'grep' | awk '{print $2}' | tail -1`
    if [ -z $MY_ORCH_PID ]; then
        echo "MySQL Orchestrator is failed to start"
    else
        echo "MySQL Orchestrator is Started"
        echo "Process PID is $MY_ORCH_PID"
    fi

• stop_orchestrator.sh

#!/bin/bash

export MY_ORCH=/usr/local/orchestrator

/bin/kill -9 $(cat $MY_ORCH/log/orchestrator.pid)


MY_ORCH_PID=`ps -ef | grep "orchestrator --debug http" | grep -v 'grep' | awk '{print $2}' | tail -1`
    if [ -z $MY_ORCH_PID ]; then
        echo "MySQL Orchestrator Stop..."
    else
        echo "MySQL Orchestrator is running"
    fi

실행이 완료 하였다면 웹 어드민 콘솔을 접속을 할 수 있으며 3000 포트가 기본 포트로 설정되어 있습니다.
orchestrator.conf.json 파일 내
"ListenAddress": ":3000",
         

Orchestrator 접속

웹 브라우저에서 http://ip:3000 으로 접속을 합니다.


접속 후 Clusters -> Discovery 로 이동 합니다.
메뉴 이동 후 Master MySQL Node 의 정보를 입력 합니다.





입력된 Master MySQL Node 정보가 입력이 완료 되었다면 Clusters -> Dashboard 로 이동 합니다
Dashboard 에는 Discovery 된 정보가 표기 됩니다. 
Master MySQL Node 의 hostname(1) 과 Instance 에 Master 와 Slave 노드를 포함한 수를 표기 합니다.





위에서 호스트 네임을 클릭하면 아래와 같이 구성된 복제 토폴로지 정보가 이미지화 되어서 확인 할 수 있습니다.





Master 와 Slave(Replica) 노드를 클릭 하였을 때 상세내역 및 가능한 컨트롤(예를 들어 Read-Only-> 가능/불가능) 에 대한 메뉴를 볼 수 있습니다.


• Master Node




• Slave Node





다음 포스팅에서는 토폴로지 리팩토링 및 Instance Failure detection 및 Recovery 등에 대해서 확인 해보도록 하겠습니다


이어지는 다음 글

MySQL Orchestrator - HA(High Availability) - 2 - 리팩토링 Failover Automated Recovery

안녕하세요 이번 포스팅에서는 Orchestrator 의 Refactoring, 장애 감지(Failure Detection), Recovery 에 대해서 알아 보도록 하겠습니다.

Ref.
github.com/orchestrator/docs [L]


관련 된 다른 글

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

MHA SummaryHA는 High Availability 의 약자로 고가용성을 의미하며 장애시 최대한 단축을 의미 합니다.MHA 는 Master High Availability 약자로 Master DB의 고가용성을 위해 Yoshinori Matsunobu(현 Facebook) 에 의해 개발 되었습니다.

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