Last Updated on 11월 24, 2023 by Jade(정현호)
안녕하세요.
이번 글은 RockyLinux8 환경에서 MySQL 8버전을 사용하면서 MHA(Master High Availability) 구성 및 설정하는 내용 그리고 VIP 대신 ProxySQL 을 사용하는 구성으로 내용이 설명되어 있습니다.
MHA + MySQL 글의 5번째 글이며, MHA+ProxySQL 구성에 관한 내용의 두 번째 글로 아래 이전 포스팅에서 이어지는 글입니다.
Contents
ProxySQL이란
ProxySQL은 MySQL용 오픈 소스 고성능, 고가용성 데이터베이스 프로토콜 인식 프록시입니다.
[ProxySQL]
ProxySQL은 다음과 같은 기능과 장점을 제공합니다.
- ProxySQL은 커넥션 멀티플렉싱은 단일 백엔드 연결을 사용하여 여러 프런트엔드 연결을 지능적으로 제공하여 연결 사용량과 부하를 크게 줄입니다.
- ProxySQL은 복잡한 쿼리 규칙 기능을 통해 쓰기 쿼리를 프라이머리로 라우팅하고, 읽기를 복제본에 분산하고, 또는 매우 세분화된 기준으로 쿼리를 즉석에서 다시 작성할 수 있습니다.
- ProxySQL은 설치 공간이 작기 때문에 어디에나 배포할 수 있습니다.
- 애플리케이션 서버 또는 K8s 포드에 분산됨
- 중앙 집중식 ProxySQL 서버 계층
- 베어메탈, VM, Docker 컨테이너 및 보장된 데이터베이스 서비스가 필요한 모든 곳에서 ProxySQL을 실행할 수 있습니다
- ProxySQL은 AMD64(x86_64) 및 ARM64를 모두 준수합니다.
- Vendor lock in 없기 때문에 애플리케이션은 완전한 MySQL 규정 준수를 유지하여 환경에 간단하고 깔끔하게 통합할 수 있습니다.
이런 여러 기능과 장점이 있는 ProxySQL은 프로그램 명칭에서 유추할 수 있듯 Proxy 서버(솔루션) 입니다.
Proxy 서버(솔루션, 서비스)는 다양하고 넓은 의미로 설명되며, 클라이언트(접속 요청자) 와 서버사이에서의 트래픽을 처리(중계)하는 역할을 합니다.
중간에서 중계자 역할을 하면서 프로그램 또는 제품마다 상당히 다양한 기능을 통해 여러 용도로 사용되고 있습니다.
이번 포스팅 글에서는 ProxySQL에 대해서는 MHA와 연계해서 사용하는 관점에서 주로 내용을 기술되어 있으며 읽기/쓰기 호스트 그룹 기능과 읽기 쓰기 분리(Read Write Split) 기능을 사용하고 있습니다.
ProxySQL 자체에 대한 더 많은 내용이나 기능 설명은 최근에 많은 자료가 있기 때문에 다른 자료를 참고하시거나, 같은 MySQL 스터디원인 강성욱님의 블로그에서 다룬 ProxySQL 내용을 참고해보시면 좋을 것 같습니다.
http://sungwookkang.com
포스팅의 테스트 환경에서는 MHA Manager가 설치된 서버에서 ProxySQL을 설치하여 사용하였으며, 글에서는 설치완료 후 내용 부터 기술되어 있으며, 구현 및 사용에 중점을 두어 설명되어 있으므로 ProxySQL의 전반적인 내용은 도큐먼트나 강성욱님 블로그나 기타 블로그를 참조하시면 됩니다.
실제 환경에서는 고가용성을 고려하여 별도의 다중의 서버에서 ProxySQL(또는 + 클러스터로)를 배포하여 고가용성 형태로 구성해야 합니다.
ProxySQL의 고가용성은 Standalone 형태로 여러 서버에 배포 및 Cluster 모드로 구성할 수 있으며, L4 또는 AWS NLB와 같은 로드밸런서와 같은 네트워크 솔루션과 연계해서 고가용성 구성을 진행합니다.
MHA 와 ProxySQL
MySQL + MHA으로 Serve Side HA로 구성된 상태에서 ProxySQL을 사용하는 이유 등에 대해서 먼저 확인해보겠습니다.
MHA에서는 기본은 아니지만 Extra 기능으로 스크립트 수정 및 이벤트 트리거를 통해 VIP를 사용할 수 있는 기능을 지원하고 있습니다. 그래서 MHA 사용시 기본 또는 많은 경우가 VIP를 활용하고 있습니다.
VIP를 사용하는 원론적인 목적을 살펴보면 Server Side HA가 아닌 Client Side HA입니다.
서버측면에서의 고가용성만 본다면 MHA의 기본 또는 중심기능은 장애감지와 그에 따른 장애조치(Failover) 그리고 데이터 정합성을 위한 복제 동기화 등의 기능입니다.
MHA을 포함한 다른 고가용성 프로그램(솔루션)에서도 서버측면의 Failover(장애조치) 후에 클라이언트에서 접속을 관련된 Client Side HA도 별도로 고려를 해야 합니다.
즉, 서버측면에서 장애조치가 완료되어 새로운 Primary(또는 Master, Source)가 구성되었는데 클라이언트에서 어떻게 접속을 할 수 있는지? 또는 기존에 Primary(또는 Master, Source)로 인지하고 있던 서버(또는 인스턴스)가 Secondary(또는 Slave, Replica) 멤버로 참여 될 경우 클라이언트에서는 또 어떻게 접속을 해야 하는지?
DB의 고가용성에 대해서 크게 서버측면의 고가용성과 클라이언트 측면의 고가용성으로 나눠볼 수 있다고 말할 수 있습니다.
MHA에서는 Primary(또는 Master, Source) 접속에 대해서는 VIP 제어 기능을 추가로 지원하고 있습니다.
VIP의 서버 간의 이동은 장애 발생시 특정조건(Health Check 등)이나 이벤트 등에 따라서 IP Unassign와 IP assign 과정으로 진행됩니다. 이 과정에서 IP Unassign이 문제가 있다면 IP중복 Assign이 될 수도 있긴 합니다.
더 고민할 부분은 1대 이상 존재할 수 있는 Secondary(또는 Slave, Replica)에 대해서 클라이언트는 어떻게 접속을 해야 하는지?
그리고 Failover가 되어 새로운 Secondary(또는 Slave, Replica) 서버에 대해서 클라이언트의 접속처리는 어떻게 해야 하는지?
MHA에서 Source(Master) 인스턴스(서버)를 위한 VIP 할당과 이동(Failover) 기능이 지원되지만 이와 같이 Secondary(또는 Slave, Replica)접속에 대한 고민은 여전히 존재하게 됩니다.
접속에 관한 클라이언트 측면의 고가용성은 환경에 따라 다양한 방법으로 사용하고 있으며 많이 사용되는 유형은 다음과 같습니다.
- Proxy
- DNS
- VIP
- L4 또는 클라우드 NLB 서비스
위의 기능이 모두 오직 단일로 사용된다는 의미는 아니며 기능을 1개 이상 같이 혼합하여 사용되고 있는 경우가 많이 있습니다.
이와 같은 내용으로 여기 포스팅 글에서는 클라이언트의 접속과 관련된 처리를 Proxy 솔루션인 ProxySQL 을 통한 읽기 쓰기 분리(Read Write Split) 기능을 사용하였습니다.
참고로 ProxySQL 외에도 HAProxy을 사용하여 유사하게 HA 환경 및 읽기 쓰기 분리 기능을 구현/사용할 수 있습니다.
포스팅글에서는 1:N 구조이며, 이와 달리 1(Source):1(Replica) 구조의 2대를 사용중일 경우 Keepalived를 사용한 VIP Failover 방법도 있으니 1:1 구조에서는 포스팅을 참고하시면 됩니다.
HA 구성에는 매직 키워드나 정답은 없기 때문에 환경이나 운영 정책을 고려하여 선택을 하시면 됩니다.
ProxySQL 설정
ProxySQL에는 많은 장점과 기능을 제공하고 있으며 포스팅 글에서는 query rules 과 replication hostgroups 기능을 사용했습니다.
ProxySQL을 사용하기 위해서는 계정 생성 과 서버 등륵 등의 작업이 필요 합니다.
계정 생성
서버의 상태 정보 등을 확인하기 위한 모니터링용 계정과 DB에 실제 사용하는 계정을 ProxySQL 등에 생성이 필요 합니다.
모니터링용 계정 생성
모니터링용 계정은 REPLICATION CLIENT 권한이 필요함으로 기존에 해당 권한이 있는 계정이 있다면 해당으로 계정으로 사용할 수 있습니다.
별도로 생성한다면 다음과 같이 MySQL DB에서 생성합니다.
mysql> create user proxysql_monitor@'%' IDENTIFIED with 'mysql_native_password' by 'proxysql_monitor'; mysql> GRANT REPLICATION CLIENT on *.* to 'proxysql_monitor'@'%';
이제 ProxySQL에서 생성한 모니터링용 계정에 대한 정보를 갱신합니다.
-- 정보 업데이트
proxysql> UPDATE global_variables SET variable_value = 'proxysql_monitor' WHERE variable_name = 'mysql-monitor_username';
proxysql> UPDATE global_variables SET variable_value = 'proxysql_monitor' WHERE variable_name = 'mysql-monitor_password';
-- 확인
proxysql> select * from global_variables WHERE variable_name in ('mysql-monitor_username','mysql-monitor_password');
-- 변경 사항 저장
proxysql> LOAD MYSQL VARIABLES TO RUNTIME;
proxysql> SAVE MYSQL VARIABLES TO DISK;
DB 계정 정보 등록
ProxySQL을 사용하여 중계하여 MySQL을 사용한다면 ProxySQL에도 접속하려는 DB계정 정보가 입력되어야 합니다.
포스팅에서는 다음과 같은 샘플 계정을 사용하였습니다.
mysql> CREATE USER testapi@'%' IDENTIFIED WITH 'mysql_native_password' by 'testapi'; mysql> GRANT SELECT, INSERT, UPDATE, DELETE ON test.* TO testapi@'%';
사용할 MySQL DB계정에 대한 정보를 다음과 같이 ProxySQL에 등록합니다.
-- 유저 정보 등록
proxysql> INSERT INTO mysql_users (username, password, default_hostgroup)
VALUES ('testapi', 'testapi', 1);
-- 유저 정보 확인
proxysql> select * from mysql_users;
-- 변경 사항 저장
proxysql> LOAD MYSQL USERS TO RUNTIME;
proxysql> SAVE MYSQL USERS TO DISK;
서버 정보 등록
서버에 정보 등록은 2곳에서 등록을 합니다. 포스팅에서는 MySQL 3개노드(서버)를 사용하기 때문에 다음과 같이 등록하였으며, 만약 2대만 사용한다면 정책에 따라서 서버 가중치(weight) 설정이 필요할 수 있습니다.
ProxySQL에 서버 정보를 다음과 같이 등록합니다.
서버 등록을 이와 같이 해도 실제 접속 처리하는 부분은 ProxySQL의 Runtime 서버 정보를 별도로 사용하기 때문에 1개의 hostgroup_id로 등록해도 되긴 합니다.
-- 192.168.56.63 이 현재 Source 인스턴스임 proxysql> INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (1, '192.168.56.63', 3306); -- 2개의 인스턴스는 현재 리플리카 인스턴스임 proxysql> INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (2, '192.168.56.64', 3306); proxysql> INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (2, '192.168.56.65', 3306); -- 서버 변경 사항 반영 LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;
mysql_replication_hostgroups 등록
이제 Write/Read 의 host group 정보를 등록합니다.
Writer 서버 호스트 그룹을 1로 , Reader 서버 호스트 그룹을 2로 지정하였고, 판단하는 체크 조건은 read_only 를 사용한다는 의미입니다.
즉, read_only 여부에 따라서 호스트 그룹 1 과 그룹2로 이동하게 됩니다.
-- 등록 proxysql> INSERT INTO mysql_replication_hostgroups(writer_hostgroup,reader_hostgroup,comment,check_type) VALUES (1,2,'mysql-rel-set','read_only'); -- 서버 변경 사항 반영 LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;
서버 정보 확인
등록된 및 설정된 정보를 확인합니다.
중요한 메타 정보는 runtime_mysql_servers 입니다.
-- 호스트 그룹 서버 등록 정보 확인 proxysql> select * from mysql_servers; -- runtime 호스트 그룹 정보 조회 proxysql> select * from runtime_mysql_servers; -- mysql_replication_hostgroups 설정 정보 확인 proxysql> select * from mysql_replication_hostgroups;
현재 runtime 정보입니다.
proxysql> select * from runtime_mysql_servers; +--------------+---------------+------+-----------+--------+--------+-------------+-----------------+---------------------+---------+----------------+---------+ | hostgroup_id | hostname | port | gtid_port | status | weight | compression | max_connections | max_replication_lag | use_ssl | max_latency_ms | comment | +--------------+---------------+------+-----------+--------+--------+-------------+-----------------+---------------------+---------+----------------+---------+ | 1 | 192.168.56.63 | 3306 | 0 | ONLINE | 1 | 0 | 1000 | 0 | 0 | 0 | | | 2 | 192.168.56.64 | 3306 | 0 | ONLINE | 1 | 0 | 1000 | 0 | 0 | 0 | | | 2 | 192.168.56.65 | 3306 | 0 | ONLINE | 1 | 0 | 1000 | 0 | 0 | 0 | | +--------------+---------------+------+-----------+--------+--------+-------------+-----------------+---------------------+---------+----------------+---------+
Query Rule 설정
ProxySQL에서는 정규표현식으로 Query Rule을 설정할 수 있습니다. 정규표현식에 맞는(매칭된) 쿼리는 지정된 호스트그룹으로 전달됩니다.
Rule이 지정되지 않은 쿼리는 사용자별 default hostgroup 으로 전달되며, 설정에 따라 다를 수 있으나 보통의 default hostgroup은 Writer 호스트그룹인 1로(또는 첫번째 0) 지정하여 사용하는 편이고 포스팅 글에서도 이와 같이 설정되어 있습니다.
그래서 쿼리 룰에 지정되지 않은 다른 쿼리 종류인 DML이나 DDL 등과 같은 쿼리는 1번 호스트그룹으로 전달됩니다
포스팅에서는 위와 같이 select for update 쿼리와 select 쿼리 2가지에 대해서 Query Rule을 사용하였고 다음과 같이 ProxySQL에서 Query Rule을 설정하겠습니다.
proxysql> INSERT INTO mysql_query_rules (rule_id, active, apply, match_digest, destination_hostgroup) VALUES (1, 1, 1, '^SELECT.*FOR UPDATE$', 1); proxysql> INSERT INTO mysql_query_rules (rule_id, active, apply, match_digest, destination_hostgroup) VALUES (2, 1, 1, '^SELECT', 2); -- 등록 정보 확인 proxysql> select * from mysql_query_rules; -- 변경사항 저장 proxysql> LOAD MYSQL QUERY RULES TO RUNTIME; proxysql> SAVE MYSQL QUERY RULES TO DISK;
MySQL을 Failover 하기 전에 쿼리의 서버 분기가 정상적으로 되는지 확인해보도록 하겠습니다.
• 조회 쿼리 수행
다음의 조회결과 같이 정상적으로 리플리카 인스턴스 2곳으로 전달되어 수행되는 것을 확인할 수 있습니다.
참고로 6033 포트는 클라이언트(애플리케이션) 접속을 위한 ProxySQL의 애플리케이션 포트 번호이며, 기본설정은 6033 포트입니다.
(포트를 변경해서 3306으로 사용 가능)
[mysql]$ mysql -utestapi -ptestapi -h 127.0.0.1 -P6033 -e "seLECT @@hostname,@@read_only;" mysql: [Warning] Using a password on the command line interface can be insecure. +------------+-------------+ | @@hostname | @@read_only | +------------+-------------+ | mha3 | 1 | +------------+-------------+ [mysql]$ mysql -utestapi -ptestapi -h 127.0.0.1 -P6033 -e "seLECT @@hostname,@@read_only;" mysql: [Warning] Using a password on the command line interface can be insecure. +------------+-------------+ | @@hostname | @@read_only | +------------+-------------+ | mha2 | 1 | +------------+-------------+ [mysql]$ mysql -utestapi -ptestapi -h 127.0.0.1 -P6033 -e "seLECT @@hostname,@@read_only;" mysql: [Warning] Using a password on the command line interface can be insecure. +------------+-------------+ | @@hostname | @@read_only | +------------+-------------+ | mha3 | 1 | +------------+-------------+ [mysql]$ mysql -utestapi -ptestapi -h 127.0.0.1 -P6033 -e "seLECT @@hostname,@@read_only;" mysql: [Warning] Using a password on the command line interface can be insecure. +------------+-------------+ | @@hostname | @@read_only | +------------+-------------+ | mha2 | 1 | +------------+-------------+
• 트랜잭션 활성화 및 DML 수행
start transaction 으로 트랜잭션 활성화 후 조회 및 Insert 구문을 수행하여 Writer 호스트에서 수행되는지 확인해보도록 하겠습니다
[mysql]$ mysql -utestapi -ptestapi -h 127.0.0.1 -P6033 -e "start transaction; select @@hostname,@@read_only;" test mysql: [Warning] Using a password on the command line interface can be insecure. +-------------+-------------+ | @@hostname | @@read_only | +-------------+-------------+ | mha1 | 0 | +-------------+-------------+ [mysql]$ mysql -utestapi -ptestapi -h 127.0.0.1 -P6033 -e "insert into tb_test(col1,col2) select @@hostname,@@read_only;" test mysql: [Warning] Using a password on the command line interface can be insecure. [mysql]$ mysql -utestapi -ptestapi -h 127.0.0.1 -P6033 -e "select * from tb_test;" test mysql: [Warning] Using a password on the command line interface can be insecure. +----+----------+------+ | id | col1 | col2 | +----+----------+------+ | 1 | mha1 | 0 | +----+----------+------+
2개의 쿼리 모두 Writer 호스트인 mha1 에서 수행된 것을 확인할 수 있으며, 쿼리 분기가 정상적으로 수행됨을 확인할 수 있습니다.
장애조치(Failover) 수행 및 클라이언트 접속 확인
ProxySQL과 MHA 를 통한 MySQL의 고가용성 환경을 위한 준비가 완료되었습니다.
클라이언트에서 ProxySQL을 통해 접속한 다음 MySQL인스터스 장애를 발생시키도록 하겠습니다.
먼저 클라이언트에서 접속 및 트랜잭션 활성화하여 소스 인스턴스(Writer)에 접속하여 쿼리가 수행되는 확인해보겠습니다.
## ProxySQL 애플리케이션 포트로 접속 [mysql]$ mysql -utestapi -ptestapi -h 127.0.0.1 -P6033 test mysql: [Warning] Using a password on the command line interface can be insecure. Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 55 Server version: 5.5.30 (ProxySQL) Copyright (c) 2000, 2023, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. ---------------------------- -- 트랜잭션 활성화 mysql> start transaction; Query OK, 0 rows affected (0.01 sec) -- 조회 쿼리 수행 mysql> select @@hostname,@@read_only, col1,col2 from tb_test; +-------------+-------------+--------+------+ | @@hostname | @@read_only | col1 | col2 | +-------------+-------------+--------+------+ | mha1 | 0 | mha1 | 0 | +-------------+-------------+--------+------+ mysql> select @@hostname,@@read_only, col1,col2 from tb_test; +-------------+-------------+--------+------+ | @@hostname | @@read_only | col1 | col2 | +-------------+-------------+--------+------+ | mha1 | 0 | mha1 | 0 | +-------------+-------------+--------+------+
현재 소스 인스턴스에서 실행중임을 확인할 수 있습니다.
이제 소스 MySQL 인스턴스를 종료하여 장애를 발생시키도록 하겠습니다.
Source 인스턴스 종료
[root]# systemctl stop mysqld or [mysql]# /../../mysql.server stop
인스턴스를 종료하면 MHA에 의해서 Failover 조치가 수행됩니다. 수행이 완료되었다면 다음과 같은 Failover 로그 내역을 확인할 수 있습니다.
Started automated(non-interactive) failover. The latest slave mha2(192.168.56.64:3306) has all relay logs for recovery. Selected mha2(192.168.56.64:3306) as a new master. mha2(192.168.56.64:3306): OK: Applying all logs succeeded. mha3(192.168.56.65:3306): This host has the latest relay log events. Generating relay diff files from the latest slave succeeded. mha3(192.168.56.65:3306): OK: Applying all logs succeeded. Slave started, replicating from mha2(192.168.56.64:3306) mha2(192.168.56.64:3306): Resetting slave info succeeded. Master failover to mha2(192.168.56.64:3306) completed successfully. <!!----
로그로 확인되는 내용과 같이 mha2 인스턴스가 프로모션(승격) 되어 소스 인스턴스가 되었습니다.
클라이언트 조회 시도
이전에 미리 DB에 접속한 세션에서 다시 조회를 수행해보도록 하겠습니다.
mysql> select @@hostname,@@read_only, col1,col2 from tb_test; ERROR 2013 (HY000): Lost connection to MySQL server during query No connection. Trying to reconnect... Connection id: 56 Current database: test +-------------+-------------+--------+------+ | @@hostname | @@read_only | col1 | col2 | +-------------+-------------+--------+------+ | mha3 | 0 | mha1 | 0 | +-------------+-------------+--------+------+ 1 row in set (15.51 sec) mysql> start transaction; Query OK, 0 rows affected (0.00 sec) mysql> select @@hostname,@@read_only, col1,col2 from tb_test; +-------------+-------------+--------+------+ | @@hostname | @@read_only | col1 | col2 | +-------------+-------------+--------+------+ | mha2 | 0 | mha1 | 0 | +-------------+-------------+--------+------+ 1 row in set (0.00 sec)
다시 쿼리를 수행하면 DB 재접속이 이루어지며 그 다음 쿼리가 수행되는 것을 알 수 있으며 그에 따라 트랜잭션이 활성화가 되어있지 않으므로 리플리카 인스턴스인 mha3에서 수행되는 것을 알 수 있습니다.
다시 트랜잭션을 활성화 후에 조회하면 프로모션(승격)되어 소스 인스턴스가 된 mha2에서 수행되는 것을 확인할 수 있습니다.
ProxySQL runtime 확인
이 상태에서 ProxySQL에서 서버 runtime 정보를 확인해보도록 하겠습니다.
proxysql> select * from runtime_mysql_servers; +--------------+---------------+------+-----------+---------+--------+ | hostgroup_id | hostname | port | gtid_port | status | weight | +--------------+---------------+------+-----------+---------+--------+ | 1 | 192.168.56.64 | 3306 | 0 | ONLINE | 1 | | 2 | 192.168.56.63 | 3306 | 0 | SHUNNED | 1 | | 2 | 192.168.56.64 | 3306 | 0 | ONLINE | 1 | | 2 | 192.168.56.65 | 3306 | 0 | ONLINE | 1 | +--------------+---------------+------+-----------+---------+--------+ * 가로 길이에 따라서 일부 내용은 편집되어 있습니다.
호스트그룹 1에 mha2 의 IP인 192.168.56.64 이 등록된 것을 확인할 수 있으며, 장애가 발생된 이전 소스 인스턴스인 mha1의 192.168.56.63 IP는 호스트그룹 2에 배치가 된 것을 확인할 수 있습니다. 그리고 상태(status)는 SHUNNED는 접속 불가를 의미합니다.
이처럼 ProxySQL에서 계속적으로 모니터링하여 클라이언트가 계속적으로 쿼리를 수행할 수 있도록 정해진 설정에 따라서 호스트 그룹을 변경하였습니다.
인스턴스 재시작 및 MHA 모니터링 시작
중지된 mha1 인스터스를 시작 및 복제 재구성 그리고 MHA 모니터링을 시작하도록 하겠습니다.
• MySQL 인스턴스 시작
[root]# systemctl start mysqld or [mysql]# /../../mysql.server start
• 복제 설정
-- 복제 설정 mysql> CHANGE REPLICATION SOURCE TO SOURCE_HOST='mha2', SOURCE_PORT=3306, SOURCE_LOG_FILE='binlog.000007', SOURCE_LOG_POS=157, SOURCE_USER='repl', SOURCE_PASSWORD='repl'; -- 복제 시작 mysql> start replica; -- 복제 상태 확인 mysql> show replica status\G
• MHA 모니터링 시작
[mysql]$ nohup masterha_manager \ --conf=$MHA_HOME/etc/app1.cnf \ --last_failover_minute=1 &
ProxySQL runtime 재확인
1번 DB 인스턴스가 시작되었고, 복제 구성원으로 참여가 완료되었기 때문에 다시 ProxySQL 서버 runtime 정보를 확인해보도록 하겠습니다.
• runtime 정보
proxysql> select * from runtime_mysql_servers; +--------------+---------------+------+-----------+--------+--------+ | hostgroup_id | hostname | port | gtid_port | status | weight | +--------------+---------------+------+-----------+--------+--------+ | 1 | 192.168.56.64 | 3306 | 0 | ONLINE | 1 | | 2 | 192.168.56.63 | 3306 | 0 | ONLINE | 1 | | 2 | 192.168.56.64 | 3306 | 0 | ONLINE | 1 | | 2 | 192.168.56.65 | 3306 | 0 | ONLINE | 1 | +--------------+---------------+------+-----------+--------+--------+ * 가로 길이에 따라서 일부 내용은 편집되어 있습니다.
1번 인스턴스 IP: 192.168.56.63 의 상태가 ONLINE 임을 확인할 수 있습니다. 그리고 아직 2번 인스턴스인 IP 192.168.56.64는 호스트 그룹 2번에 존재하는 것을 확인할 수 있습니다.
이 부분은 ProxySQL에서 갱신이 느리거나 정보 갱신이 안되는 부분으로 변경된 내용을 갱신하는 명령어를 수행하면 Reader 호스트그룹 2도 추가적으로 정보 갱신할 수 있습니다.
proxysql> LOAD MYSQL SERVERS TO RUNTIME;
Write, Reade 쿼리 몇 번 수행 후 다시 서버 runtime 정보를 확인해보면 호스트 그룹2도 재정의 된 것을 확인할 수 있습니다.
proxysql> select * from runtime_mysql_servers; +--------------+---------------+------+-----------+--------+--------+ | hostgroup_id | hostname | port | gtid_port | status | weight | +--------------+---------------+------+-----------+--------+--------+ | 1 | 192.168.56.64 | 3306 | 0 | ONLINE | 1 | | 2 | 192.168.56.63 | 3306 | 0 | ONLINE | 1 | | 2 | 192.168.56.65 | 3306 | 0 | ONLINE | 1 | +--------------+---------------+------+-----------+--------+--------+ * 가로 길이에 따라서 일부 내용은 편집되어 있습니다.
이 부분은 LOAD MYSQL SERVERS TO RUNTIME 명령어를 수분(또는 수십분) 단위로 한 번씩 실행하는 crontab 스케줄을 설정하여 사용하는 것도 하나의 방법입니다. 또는 failover 조치가 완료되면 DBA의 별도 작업 Task 형태로 별도로 수행하여도 됩니다.
이처럼 MHA + ProxySQL의 조합으로 클라이언트 측면에서도 IP 변경이나 VIP의 이동과 같은 작업 없이 빠르게 소스(Writer) 인스턴스와 리플리카(Reader) 인스턴스로 분리(Read Write Split)하여 DB를 계속적으로 사용할 수 있는 환경을 구성할 수 있습니다.
이번 MHA + ProxySQL 글은 여기서 마무리하겠습니다.
긴 글 읽어 주셔서 감사합니다.
Reference
Reference URL
• proxysql.com/documentation
연관된 다른 글
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
