반응형

MySQL 고가용성 운영을 위한 Orchestrator 설치

 

l  Version : MySQL, Orchestrator

 

데이터베이스를 운영할 단일 장애 포인트(SPOF, Single Point Of Failure) 예방하기 위해서 고가용성(HA, High-Available) 매우 중요한 부분이다. 그렇기 때문에 클러스터링, 복제 고가용성으로 구성된 다수의 데이터베이스를 효율적으로 관리하기 위해 다양한 솔루션들이 존재한다.  

이번 포스트는 MySQL MariaDB 고가용성을 효율적으로 운영하기 위한 솔루션인 Orchestrator(이하 오케스트레이터’) 대해서 알아본다. 오케스트레이터는 MySQL 고가용성 복제 관리 도구로, 서비스로 실행되며 명령줄 액세스, HTTP API 인터페이스를 제공한다.

 

l  Orchestrator : https://github.com/openark/orchestrator

 

오케스트레이터의 주요 기능으로는 아래와 같다.

l  Discovery : 토폴로지를 통해 지속적으로 클러스터의 복제 상태 구성과 같은 기본 MySQL 정보를 읽어 오케스트레이션에 매핑한다. 장애가 발생하였을 복제 문제를 포함하여 토폴로지의 자세한 정보를 시각화로 제공한다.

l  Refactoring : 복제 서버의 Binlog file:position, GTID, Pseudo GTID 다양한 정보를 수집한다. 복제 토폴로지에서 리팩토링은 GUI에서 복제본을 다른 마스터 아래로 끌어서 놓는 방식으로 안전하게 진행할 있다. 오케스트레이터는 비정상적인 리팩토링 시도를 거부하며 다양한 명령줄 옵션을 통해 세밀한 제어가 가능하다.

l  Recovery : 전체적인 접근 방식을 사용하여 마스터 중간 마스터 오류를 감지한다. 토폴로지 자체에서 얻은 정보를 기반으로 다양한 장애 시나리오를 인식한다. 장애가 인식되면 자동 또는 수동 복구를 수행하도록 구성할 있다. 복구 프로세스는 오케스트레이터의 토폴로지 이해와 리팩토링 수행 능력을 활용하며, 구성이 아닌 상태를 기반으로 한다. 오케스트레이터는 자체 복구시 토폴로지를 조사/평가하여 최상의 복구 방법을 선택한다.

 

오케스트레이터는 다양한 인터페이스를 지원하는데 명령줄 인터페이스(CLI, Command Line Interface) 활용하여 디버그 메시지 등을 수집하고 자동화된 스크립팅을 제어할 있다. 외에도 다양한 Web API (HTTP Get access) 인터페이스를 제공한다.

l  Highly available

l  Controlled master takeovers

l  Manual failovers

l  Failover auditing

l  Audited operations

l  Pseudo-GTID

l  Datacenter/physical location awareness

l  MySQL-Pool association

l  HTTP security/authentication methods

 

 

 

Orchestrator 사용하려면 우선 MySQL복제 환경이 구성되어 있어야 한다. 오케스트레이터 구성에서 GTID 사용을 권장하고 있으나, Binlog position 사용시 Pseudo GTID 사용하면 된다. MySQL 복제 구성은 아래 링크를 참고한다.

l  ProxySQL 설치 (MySQL 설치부터, 복제 구성, ProxySQL 설정까지 한번에) : https://sungwookkang.com/1529

 

오케스트레이터를 구성할 서버 정보들이다. 링크에서 구성한 환경을 기반으로 진행한다.

Server Name IP OS Service Version
proxy-sql 172.30.1.49 Ubuntu 22.04.2 LTS ProxySQL version 2.4.2-0-g70336d4, codename Truls
mysql-master 172.30.1.97 Ubuntu 22.04.2 LTS mysql  Ver 8.0.33
mysql-slave1 172.30.1.10 Ubuntu 22.04.2 LTS mysql  Ver 8.0.33
mysql-slave2 172.30.1.13 Ubuntu 22.04.2 LTS mysql  Ver 8.0.33
proxy-orchestrator 172.30.1.24 Ubuntu 22.04.2 LTS mysql  Ver 8.0.33, container.d

 

proxy-orcherator서버에는 오케스트레이터가 설치되어 운영된다. 오케스트레이터에서 필요한 정보를 저장하기 위해 오케스트레이터용 리포지토리 MySQL 설치한다.

sudo apt-get install mysql-server

 

MySQL설치가 완료되면 오케스트레이터가 사용할 계정 데이터 베이스를 생성한다. 테스트 용도이기 때문에 편의상 전체 권한을 부여한다. 실제 업무에서 사용할 때에는 보안 정책에 따라 오케스트레이터에 필요한 권한만 할당한다.

--데이터베이스 생성
CREATE DATABASE IF NOT EXISTS orchestrator;
 
--사용자 생성
CREATE USER 'orchestrator'@'%' IDENTIFIED BY 'orchestrator';
--GRANT SUPER, PROCESS, REPLICATION SLAVE, RELOAD ON *.* TO 'orchestrator'@'%';
--GRANT SELECT ON mysql.slave_master_info TO 'orchestrator'@'%';
 
GRANT ALL PRIVILEGES ON *.* TO 'orchestrator'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;

 

 

이번 포스트에서는 컨테이너로 빌드된 오케스트레이터를 설치하기 때문에, 컨테이너를 실행할 있는 도커 패키지를 설치한다.

--시스템 패키지 업데이트
sudo apt-get update
 
--필요한 패키지 설치
sudo apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common
 
--Docker 공식 GPG키를 추가
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
 
--Docker 공식 apt 저장소를 추가
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
 
--시스템 패키지 업데이트
sudo apt-get update
 
--Docker 설치
sudo apt-get install docker-ce docker-ce-cli containerd.io
 
--Docker 서비스 실행 확인
sudo systemctl status docker

 

 

 

도커 설치가 완료되었으면, 도커 허브에서 오케스트레이터 컨테이너를 다운로드 한다.

ü  https://hub.docker.com/r/openarkcode/orchestrator

 

 

아래 스크립트를 실행하면 도커 이미지가 다운로드 되며, 현재 호스트에 저장되어 있는 도커 이미지를 확인할 있다.

sudo docker pull openarkcode/orchestrator
sudo docker images

 

 

 

아래 스크립트를 사용하여 도커를 실행한다.

sudo docker run -d --name orchestrator -p 3000:3000 openarkcode/orchestrator

 

 

 

오케스트레이터 서비스가 정상적으로 실행되었으면, 브라우저를 사용하여 오케스트레이터 대시보드로 접속한다.

http://172.30.1.24:3000/

 

 

상단의 [Cluster] – [Discover]에서 MySQL 클러스터를 등록할 있다. 기본값으로 호스트 이름으로 등록하게 되어 있다. 호스트 이름으로 MySQL 서버들을 검색하려면 proxy-orchstrator (오케스트레이터의 호스트 서버) 서버의 /etc/hosts 파일에 호스트 정보를 등록한다.

 

 

서버 이름이 아닌 서버IP 클러스터 서버를 찾기 위해서는 아래와 같이 설정 파일을 수정하여 사용할 있다. 기본적으로 설정 파일은 아래 경로에 있다.

/usr/local/orchestrator/

 

컨테이너 환경에서는 컨테이너 내부에서 파일 수정을 하는 것은 좋은 방법은 아니지만 실습 편의상 컨테이너 내부 쉘로 접근해서 수정하였다. 실제 서비스 환경에서는 컨테이너 특성상 데이터가 휘발되기 때문에 반드시 설정파일 따로 보관할 있도록 한다. 아래 스크립트는 실행 중인 컨테이너의 ID 확인하고, 해당 컨테이너 쉘로 접근한다.

sudo docker ps -a
sudo docker exec -it 93c5bfafa537 /bin/bash

 

 

 

설정파일이 위치한 경로로 이동하여 설정 파일을 수정한다.

cd /usr/local/orchestrator/
sudo cp orchestrator-sample.conf.json orchestrator.conf.json
vi orchestrator.conf.json

 

 

오케스트레이터 서버가 MySQL 클러스터 서버들에게 접속할 있는 계정과 비밀번호를 입력한다. 사용자 환경에 맞게 수정하여 사용한다.

"MySQLTopologyUser": "orc_client_user",
"MySQLTopologyPassword": "orc_client_password",

 

오케스트레이터 서버가 orchester 데이터베이스 접속할 있는 계정과 비밀번호를 입력한다. 오케스트레이터용 리포지토리 MySQL 설치 단계에서 생성한 계정을 입력하도록 한다.

"MySQLOrchestratorHost": "127.0.0.1",
"MySQLOrchestratorPort": 3306,
"MySQLOrchestratorDatabase": "orchestrator",
"MySQLOrchestratorUser": " orchestrator ",
"MySQLOrchestratorPassword": " orchestrator ",

 

 

호스트 이름 대신 IP 검색할 있도록 옵션을 수정한다.

변경 "HostnameResolveMethod": "default",
"MySQLHostnameResolveMethod": "@@hostname",
변경 "HostnameResolveMethod": "none",
"MySQLHostnameResolveMethod": "",

 

GTID 사용하지 않고 binlog position 사용할 경우 failover 위해서 PeseudoGTID 활성화 하기위해 아래 파리메터를 입력한다. 해당 파라메터는 설정 파일에 없으므로 직접 추가해야 한다.

"AutoPseudoGTID": true,

 

 

각종 로그파일은 아래 경로에서 확인할 있다. 필요시 사용자 경로에 맞게 수정하여 사용할 있다.

"OnFailureDetectionProcesses": [
"echo 'Detected {failureType} on {failureCluster}. Affected replicas: {countSlaves}' >> /tmp/recovery.log"
  ],
"PreGracefulTakeoverProcesses": [
"echo 'Planned takeover about to take place on {failureCluster}. Master will switch to read_only' >> /tmp/recovery.log"
  ],
"PreFailoverProcesses": [
"echo 'Will recover from {failureType} on {failureCluster}' >> /tmp/recovery.log"
  ],
"PostFailoverProcesses": [
"echo '(for all types) Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Successor: {successorHost}:{successorPort}' >> /tmp/recovery.log"
  ],
"PostUnsuccessfulFailoverProcesses": [],
"PostMasterFailoverProcesses": [
"echo 'Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Promoted: {successorHost}:{successorPort}' >> /tmp/recovery.log"
  ],
"PostIntermediateMasterFailoverProcesses": [
"echo 'Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Successor: {successorHost}:{successorPort}' >> /tmp/recovery.log"
  ],
"PostGracefulTakeoverProcesses": [
"echo 'Planned takeover complete' >> /tmp/recovery.log"
  ],

 

설정값 변경이 완료되었으면 해당 사항을 저장하고 오케스트레이터 서비스를 재시작한다. 오케스트레이터 대시보드에 접속하여 IP Discover 등록할 있다. 서버는 master 역할 서버만 입력한다.

 

 

정상적으로 등록이 완료되면 아래와 같이 등록된 서버가 나타난다.

 

 

해당 서버를 클릭하면 현재 구성된 토폴로지 상태를 나타내는 대시보드를 있다,

 

 

대시보드에 나타난 서버들을 클릭해보면 현재 상태의 상세 정보를 확인할 있으며, 일부 제어를 있는 메뉴가 나타난다.

 

 

 

 

[참고자료]

l  Orchestrator : https://github.com/openark/orchestrator

l  MySQL Orchestrator - HA(High Availability) - 1 - 기능 설명 설치 : https://hoing.io/archives/72

l  https://code.openark.org/blog/mysql/what-makes-a-mysql-server-failurerecovery-case : https://code.openark.org/blog/mysql/what-makes-a-mysql-server-failurerecovery-case

l  Orchestrator: MySQL Replication Topology Manager : https://www.percona.com/blog/orchestrator-mysql-replication-topology-manager/

l  Orchestrator and ProxySQL : https://www.percona.com/blog/orchestrator-and-proxysql/

 

 

 

 

2023-07-25 / Sungwook Kang / http://sungwookkang.com

 

MySQL, ProxySQL, MySQL Replication, MySQL HA, MySQL복제 오케스트레이션, MySQL복제설치, MySQL MHA, MySQL Orchestrator

반응형

+ Recent posts