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
'MySQL, MariaDB' 카테고리의 다른 글
MySQL HA + ProxySQL 환경에서 서비스 장애조치 구성 (0) | 2023.08.03 |
---|---|
MySQL HA 환경에서 Orchestrator를 활용한 클러스터 리팩토링 및 자동 장애조치 구성 (0) | 2023.07.27 |
ProxySQL Internals 및 시스템 구성 둘러보기 (0) | 2023.07.24 |
ProxySQL 쿼리룰 설정으로 Read, Write 부하 분산하기 (0) | 2023.07.23 |
ProxySQL 설치 (MySQL 설치부터, 복제 구성, ProxySQL 설정까지 한번에) (0) | 2023.07.22 |