proxysql-orchestrator

김세벽·2024년 7월 23일

목록 보기

4/4

Orchestrator란

ProxySQL은 Recovery 기능을 제공하지는 않는다. 그래서 MySQL 서버 장애시DB 클러스터에서는 Slave DB (Read only)로 운영되던 데이터베이스를 Master DB로 승격을 시켜야 하는데, 이 기능을 제공하지는 않는다. 이러한 단점을 극복하기 위해 MySQL 고가용성 솔루션인 오케스트레이터(orchestrator)를 함께 사용한다.

오케스트레이터는 Replication으로 구성된 DB의 구조를 파악하고 스케줄러가 DB 설정을 변경할 수 있어 기존의 Slave DB를 Master로 승격시킬 수 있다. 그리고 ProxySQL이 인지할 수 있도록 스케줄러가 ProxySQL의 설정 파일을 업데이트 한다. 이러한 방식으로 Recovery를 구성할 수 있다.

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

Orchestrator 설치

1. MySQL 설치 및 root 사용자 pw 설정

## mysql 설치
$ sudo dnf -y install mysql-server
$ sudo systemctl start mysqld.service
$ sudo systemctl enable mysqld.service
$ sudo systemctl status mysqld.service

## root 비밀번호 설정
$ mysql -u root
//
mysql> ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '4321';
//

오케스트레이터에서 필요한 정보를 저장하기 위해 오케스트레이터용 리포지토리 MySQL을 설치한다.

먼저 root 비밀번호 설정을 합니다.

2. 필요 선행 패키지 설치(Orchestrator)

$ sudo dnf -y install epel-release
$ sudo dnf -y install ncurses ncurses-devel ncurses-libs openssl openssl-devel bison readline gcc gcc-c++ make cmake glibc automake numactl numactl-devel libaio libaio-devel curl jq oniguruma

ncurses-static 패키지가 필요한지 테스트(지금은 설치 못함)

3. orchestrator DB 유저 생성

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

3-1 MySQL에 유저 생성 (Master)

Orchestrator에 접속하여 컨트롤 및 모니터링 용도를 위한 유저를 DB에서 생성합니다.
Replica 서버에 별도로 사용자를 생성할 필요는 없습니다. MySQL의 복제 메커니즘에 의해, 마스터에서 생성한 사용자와 권한이 자동으로 슬레이브로 복제됩니다. 하지만, Replica 서버에 접근해야 하는 다른 특별한 이유가 있다면 사용자 생성 및 권한 설정이 필요할 수 있습니다.

## 오케스트레이터가 사용할 계정 생성 
mysql> CREATE USER 'orchestrator'@'%'IDENTIFIED BY 'orchestrator';

## orchestrator사용자에게 권한 부여
- 서버의 고급 관리 작업
- 실행 중인 모든 프로세스 조회
- 마스터 서버로부터 데이터를 복제
- 서버의 캐시와 로그를 새로 고침

mysql> GRANT SUPER, PROCESS, REPLICATION SLAVE, RELOAD ON *.* TO 'orchestrator'@'%';

## slave_master_info 테이블에 대한 SELECT 권한을 부여
- MySQL Orchestrator는 복제 설정을 관리하고 모니터링하는 도구입니다. 
- mysql.slave_master_info 테이블에 대한 읽기 권한을 통해 Orchestrator는 Replica 서버의 상태와 설정을 모니터링하고, 복제 설정을 파악하여 복제 클러스터를 효과적으로 관리할 수 있습니다.

mysql> GRANT SELECT ON mysql.slave_master_info TO 'orchestrator'@'%';

## 사용자 및 권한 확인
mysql> SELECT User, Host FROM mysql.user WHERE User = 'orchestrator';
mysql> SHOW GRANTS FOR 'orchestrator'@'%';

오케스트레이터가 사용할 계정 생성 및 권한을 부여한다.

3-2 Repository 접속을 위한 Topology 계정 생성(Orchestrator)

## Orchestrator가 자신의 메타데이터(예: 토폴로지 정보, 상태 정보, 장애 조치 이력 등)를 저장하는 데 사용됩니다.
mysql> CREATE DATABASE IF NOT EXISTS orchestrator;

## 로컬 머신에서만 접근 가능합니다.
mysql> CREATE USER 'orchestrator'@'127.0.0.1' IDENTIFIED BY 'orchestrator';

## 모든 데이터베이스와 모든 테이블에 대해 모든 권한을 부여
GRANT ALL PRIVILEGES ON `orchestrator`.* TO 'orchestrator'127.0.0.1';

4. Orchestrator 패키지 설치(Orchestrator)

$ sudo rpm -ivh https://github.com/openark/orchestrator/releases/download/v3.2.6/orchestrator-3.2.6-1.x86_64.rpm

Orchestrator 패키지를 설치합니다.

5. orchestrator.conf.json 컨피그 수정(Orchestrator)

$ cd /usr/local/orchestrator/
$ ll
-rwxr-xr-x. 1 root root 19794824 Jul 27  2021 orchestrator
-rw-r--r--. 1 root root     5513 Jul 24 06:17 orchestrator.conf.json
-rw-rw-r--. 1 root root     5513 May 24  2021 orchestrator-sample.conf.json
-rw-rw-r--. 1 root root     5100 Jun  4  2020 orchestrator-sample-sqlite.conf.json
drwxr-xr-x. 7 root root       82 Jul 24 06:11 resources

$ sudo cp orchestrator-sample.conf.json orchestrator.conf.json
$ ll
-rwxr-xr-x. 1 root root 19794824 Jul 27  2021 orchestrator
-rw-r--r--. 1 root root     5513 Jul 24 06:18 orchestrator.conf.json
-rw-rw-r--. 1 root root     5513 May 24  2021 orchestrator-sample.conf.json
-rw-rw-r--. 1 root root     5100 Jun  4  2020 orchestrator-sample-sqlite.conf.json
drwxr-xr-x. 7 root root       82 Jul 24 06:11 resources

$ sudo vim orchestrator.conf.json
//
  5   "MySQLTopologyUser": "orchestrator",
  6   "MySQLTopologyPassword": "orchestrator",
  ...
 13   "MySQLOrchestratorHost": "127.0.0.1",
 14   "MySQLOrchestratorPort": 3306,
 15   "MySQLOrchestratorDatabase": "orchestrator",
 16   "MySQLOrchestratorUser": "orchestrator",
 17   "MySQLOrchestratorPassword": "orchestrator",
 ...
 ## 호스트를 식별하기 위해 모든 DB 서버에서 다음 구성과 일치하도록 보고서 호스트를 설정합니다.
 36   "HostnameResolveMethod": "none",
 37   "MySQLHostnameResolveMethod": "",
 ...
 ## 이 설정이 true로 설정되면, Orchestrator는 자동으로 Pseudo-GTID를 생성하고 관리합니다.
 ## 이를 통해 오케스트레이터가 복제 상태를 정확하게 파악하고 자동 장애 조치를 수행할 수 있습니다.
 93   "AutoPseudoGTID": true,
 94   "PseudoGTIDPattern": "",
//

orchestrator.conf.json 컨피그 수정

6. Hosts 등록(Orchestrator)

Orchestrator 에서는 기본적으로 조회되는 호스트로 Orchestrator 서버에서 -> MySQL DB 로 접속을 하는 방식을 사용합니다.
그래서 Orchestrator 서버에서는 DNS 로 IP가 조회되는 환경이거나 /etc/hosts 에 각 서버의 호스트명과 IP를 입력해줘야 정상적으로 사용할 수 있습니다.

$ sudo vim /etc/hosts
//
192.168.110.110 primary_db
192.168.110.111 readreplica_db01
192.168.110.112 readreplica_db02 
//

Hosts에 각 db서버의 호스트와 ip를 입력합니다.

7. Orchestrator 시작 및 접속

$ sudo systemctl start orchestrator.service
$ sudo systemctl enable orchestrator.service
$ sudo systemctl status orchestrator.service

Orchestrator 시작

http://192.168.110.114:3000/web/clusters 접속

ip로 Discover가능

8. 오류발생

9. failover

9-1 수동 failover

오케스트레이터의 장애조치 모드 기본값은 수동이다.

수동으로 장애조치는 관리자가 문제를 인지하고 직접 장애 조치를 진행해야 한다.

primary서버를 중지시키고 recovery를 클릭해 replica중 하나를 primary로 승격시킨다.

장애조치를 실행하게 되면, 응답 없는 서버를 기존의 클러스터에 분리된다.

proxysql에서 primary서버 SHUNNED상태 확인

"not replicating"이라는 메시지는 slave 서버가 master 서버로부터 데이터를 복제하지 않고 있음을 의미합니다.

사용자 'slave_db'가 master 서버에 존재하지 않거나, 'slave_db' 사용자가 master 서버에 접근할 수 있는 권한이 없어서 생기는 오류입니다.

기존엔 master서버에서 'slave_db'사용자 생성시 slave서버에도 'slave_db'사용자가 생성되어 접근할 수 있었지만 master가 중지되어 새로 master로 승격된 replicadb1에는 'slave_db' 사용자가 없습니다.

'slave_db'사용자를 replicadb1,2에 생성해줍니다.

caching_sha2_password 플러그인과 관련된 인증 문제를 mysql_native_password로 플러그인을 변경하여 해결합니다.

마찬가지로 master,slave 전부 적용시켜야합니다.

오류가 해결되어 slave 서버가 master 서버로부터 데이터를 복제에 성공했습니다.

master서버에서 server_uuid값을 조회하고 slave서버에서 Master_UUID값이 일치하는지 확인합니다.

Orchestrator를 사용하여 자동 장애 조치(failover) 후, 원래의 마스터가 다시 가동되더라도 자동으로 새로운 마스터로 승격되지는 않습니다.

이를 해결하기 위해서는 수동으로 다시 복구 절차를 진행해야 합니다.

9-2 자동 failover
기본 모드가 수동이기 때문에, 자동으로 장애조치를 하기 위해서는 설정파일에서 파라메터 수정이 필요하다.

RecoveryPeriodBlockSeconds": 10 => 동일한 클러스터에서 연속적인 자동 복구 시도 사이에 기다려야 하는 시간(초)입니다.

"RecoveryIgnoreHostnameFilters": [] => 복구 중 무시할 호스트 이름의 필터 목록입니다. 특정 호스트를 무시하려면 해당 호스트 이름을 배열에 추가합니다.

"RecoverMasterClusterFilters": ["*"] => 마스터 복구를 수행할 클러스터를 정의하는 필터 목록입니다. 특정 클러스터만 복구하고 싶다면, 해당 클러스터 이름을 필터로 추가합니다.

"RecoverIntermediateMasterClusterFilters": ["*"] => 중간 마스터(Intermediate Master) 복구를 수행할 클러스터를 정의하는 필터 목록입니다. 특정 클러스터만 복구하고 싶다면, 해당 클러스터 이름을 필터로 추가합니다.

설정 변경을 완료하였으면, 오케스트레이터는 설정 파일에 대한 변경사항을 런타임중에 적용할 수 있다. 대시보드 상단 메뉴에서 [Home] - [Status]를 클릭한다.

Status페이지에서 [Reload congifuration]을 클릭하여 설정을 로드 한다.

auto failover 테스트를 위해 primary의 mysqld서비스를 stop합니다.

대시보드에서 auto failover를 확인합니다.

primary는 클러스터에 분리되었습니다.

auto failover가 되어 replicadb1이 master로 승격했습니다.

replicadb1의 server_uuid와 replicadb2의 master-uuid가 일치하므로 제대로 복제 구성이 된 것입니다.

트러블슈팅

1. NoFailoverSupportStructureWarning

해결방안

pseudo_gtid 를 사용시 권한 부여

mysql> GRANT DROP ON _pseudo_gtid_.* to 'orchestrator'@'%';
mysql> flush privileges;

Orchestrator 구성 에서 GTID 사용을 권장

Binlog Position 사용시 Pseudo GTID 를 사용

2. Authentication plugin 'caching_sha2_password' reported error

"Error connecting to source 'slave_db@192.168.110.111:3306'. This was attempt 1/86400, with a delay of 60 seconds between attempts. Message: Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection."

MySQL 서버에서 caching_sha2_password 인증 플러그인을 사용하는데, SSL 연결이 필요하다는 것을 나타냅니다. 이 문제는 MySQL 서버가 caching_sha2_password 플러그인을 사용하고 있지만, 클라이언트(여기서는 슬레이브 서버)가 SSL을 통해 안전하게 연결하지 않았기 때문에 발생합니다.

해결방안

SSL 설정을 확인하고 슬레이브 서버에서 SSL을 통해 마스터 서버에 연결하도록 설정합니다.
대체로 인증 플러그인을 mysql_native_password로 변경하여 문제를 해결할 수도 있습니다.
SSL 인증서와 키 파일을 확인하여 올바르게 설정되어 있는지 점검합니다.
로그 파일을 확인하여 추가적인 오류 정보를 수집합니다.

1-1 마스터 서버에서 SSL 설정 확인

[mysqld]
ssl-ca=/path/to/ca-cert.pem
ssl-cert=/path/to/server-cert.pem
ssl-key=/path/to/server-key.pem

1-1)
마스터 서버에서 SSL 설정 확인

마스터 서버가 SSL을 사용하도록 설정되어 있는지 확인합니다.

my.cnf 또는 my.ini 파일에서 SSL 관련 설정이 올바르게 되어 있어야 합니다.

1.2 슬레이브 서버에서 SSL 설정

STOP SLAVE;

CHANGE MASTER TO 
    MASTER_HOST='master_host', 
    MASTER_USER='slave_db', 
    MASTER_PASSWORD='password', 
    MASTER_LOG_FILE='master_log_file', 
    MASTER_LOG_POS=master_log_position,
    MASTER_SSL=1,          -- SSL 사용 설정
    MASTER_SSL_CA='/path/to/ca-cert.pem',
    MASTER_SSL_CERT='/path/to/client-cert.pem',
    MASTER_SSL_KEY='/path/to/client-key.pem';

START SLAVE;

슬레이브 서버에서 마스터 서버에 SSL로 연결하도록 설정합니다.

MASTER_SSL=1은 SSL을 사용하도록 설정합니다.

MASTER_SSL_CA, MASTER_SSL_CERT, MASTER_SSL_KEY는 각각 SSL CA 인증서, 클라이언트 인증서, 클라이언트 키의 경로를 지정합니다.

2-1 인증 플러그인 변경 (대체 방법 - 이방법으로 해결)

ALTER USER 'slave_db'@'%' IDENTIFIED WITH mysql_native_password BY 'password';
FLUSH PRIVILEGES;

caching_sha2_password는 MySQL 8.0 이상부터 기본 인증 플러그인으로 사용되지만, mysql_native_password(MySQL 5.7 및 이전 버전)로 변경할 수 있습니다.

이 방법은 인증 플러그인 문제를 해결할 수 있지만, SSL 연결이 필요한 경우에는 여전히 SSL 설정이 필요합니다.

3-1 SSL 인증서 및 키 파일 확인

SSL을 사용할 때 인증서 및 키 파일이 올바르게 설정되어 있는지 확인합니다.
파일 경로와 파일 내용이 정확한지, 파일 권한이 올바른지 점검합니다.

4-1 로그 파일 확인

tail -f /var/log/mysql/mysqld.log

MySQL 서버의 에러 로그를 확인하여 추가적인 오류 메시지나 경고를 점검합니다.

/etc/my.cnf.d/mysql-server.cnf 설정파일의 log-error=/var/log/mysql/mysqld.log의 주석을 제거합니다.

주석을 제거하고 MySQL 서버를 재시작하면, 지정된 파일 경로에 에러 로그가 쌓이게 됩니다.

Auto failover

성공 화면

김세벽

normal

이전 포스트

proxysql-orchestrator

final

Orchestrator란

Orchestrator 설치

1. MySQL 설치 및 root 사용자 pw 설정

2. 필요 선행 패키지 설치(Orchestrator)

3. orchestrator DB 유저 생성

4. Orchestrator 패키지 설치(Orchestrator)

5. orchestrator.conf.json 컨피그 수정(Orchestrator)

6. Hosts 등록(Orchestrator)

7. Orchestrator 시작 및 접속

8. 오류발생

9. failover

트러블슈팅

1. NoFailoverSupportStructureWarning

해결방안

pseudo_gtid 를 사용시 권한 부여

2. Authentication plugin 'caching_sha2_password' reported error

해결방안

1-1 마스터 서버에서 SSL 설정 확인

1.2 슬레이브 서버에서 SSL 설정

2-1 인증 플러그인 변경 (대체 방법 - 이방법으로 해결)

3-1 SSL 인증서 및 키 파일 확인

4-1 로그 파일 확인

Auto failover

proxysql

0개의 댓글