MySQL Galera Cluster + ProxySQL 에서 Galera Cluster 특성을 고려한 R/W 호스트 그룹 설정 하기
l Version : MySQL, MariaDB, Galera Cluster, ProxySQL 2.X
Galera Cluster ( 이하 “ 갈레라 클러스터 ”) 는 다중 마스터 동기 복제를 제공하는 솔루션으로 DB 간의 직접적인 데이터 공유가 없는 형태의 오픈소스 고가용성 솔루션이다 . 갈레라 클러스터는 동기 방식의 복제구조를 사용하는 멀티마스터 RDB 클러스터로 제공된다 .
ProxySQL 은 여러 데이터베이스에 대해 동일한 커넥션을 재사용할 수 있도록 멀티 플렉싱 기능과 쿼리를 분석하여 Write/Read 를 분산하는 등 다양한 기능을 제공하는 솔루션이다 .
l ProxySQL 이란 무엇인가 : https://sungwookkang.com/1528
l MySQL/MariaDB 환경에서 다중 마스터 복제를 지원하는 Galera Cluster 알아보기 : https://sungwookkang.com/1536
ProxySQL 2.x 부터는 Galera Cluster 를 좀더 유연하게 지원한다 . 이번 포트스에서는 MySQL Galera cluster + ProxySQL 로 구성된 환경에서 Galera Cluster 특성을 고려한 ProxySQL 의 Write, Read 호스트 그룹 전략에 대해서 알아본다 .
[mysql_galera_hostgroups]
ProxySQL 에서 호스트 그룹에 따라 Write, Read 를 역할을 정의한다 . Galera Cluster 환경에서는 mysql_galera_hostgroups 에서 해당 노드의 역할을 정의할 수 있다 . 아래 스크립트를 실행하면 mysql_galera_hostgroups 테이블의 정보를 확인할 수 있다 .
select * from mysql_galera_hostgroups\G
Admin> select * from mysql_galera_hostgroupsG *************************** 1. row *************************** writer_hostgroup: 10 backup_writer_hostgroup: 20 reader_hostgroup: 30 offline_hostgroup: 9999 active: 1 max_writers: 1 writer_is_also_reader: 2 max_transactions_behind: 20 comment:
l writer_hostgroup : 쓰기 가능한 (read_only=0) 모든 구성원을 포함할 호스트 그룹의 ID
l backup_writer_hostgroup : 쓰기 백업 노드의 그룹 ID. 클러스터가 다중 쓰기 모드 (read_only=0 인 여러 노드가 있는 경우 ) 에서 실행 중이고 max_writers 가 전체 쓰기 노드 수보다 작은 수로 설정된 경우 추가 노드는 backup_writer_hostgroup 으로 이동된다 .
l reader_hostgroup : 읽기 가능한 (read_only=1 인 노드 ) 모든 구성원을 포함할 호스트 그룹의 ID
l offline_hostgroup : 클러스터에서 참여하지 않는 노드들에 대한 그룹 ID. ProxySQL 모니터링에서 호스트가 OFFLINE 인 것으로 확인되면 호스트가 offline_hostgroup 으로 이동된다 .
l Active : 호스트 그룹을 활성화하는 부울 값 (0 또는 1)
l max_writers : writer 호스트 그룹에서 허용되는 최대 노드 수를 제어한다 . Writer_hostgroup 노드 수가 max_writers 수보다 클 경우 추가 노드는 backup_writer_hostgroup 으로 이동된다 .
l writer_is_also_reader : 1 이면 writer_hostgroup 의 노드가 reader_hostgroup 에도 배치되어 읽기에 사용된다 . 2 로 설정하면 backup_writer_hostgroup 의 노드가 writer_hostgroup 의 노드 대신 reader_hostgroup 에 배치된다 .
l max_transactions_behind : 오래된 읽기를 방지하기 위해 노드가 SHUNNED 되기 전에 클러스터의 노드가 대기할 수 있는 최대 쓰기 세트 수를 결정한다 . (wsrep_local_recv_queue Galera 변수를 쿼리하여 결정됨 ).
l Comment : 사용자가 정의한 목적에 맞게 사용할 수 있는 텍스트 필드
ProxySQL 은 MySQL 상태 및 변수를 모니터링하여 Galera 상태 확인을 수행한다 .
l read_only : 설정값이 ON 인 경우 , writer_is_also_reader 가 1 이 아니면 ProxySQL 은 정의된 호스트를 reader_hostgroup 으로 그룹화한다 .
l wsrep_desync : 설정값이 ON 인 경우 , ProxySQL 은 노드를 사용할 수 없는 것으로 표시하여 offline_hostgroup 으로 이동한다 .
l wsrep_reject_queries : 설정값이 ON 이면 ProxySQL 은 노드를 사용할 수 없는 것으로 표시하고 이를 offline_hostgroup 으로 이동한다 . ( 특정 유지 관리 상황에서 유용함 ).
l wsrep_sst_donor_rejects_queries : 설정값이 ON 이면 ProxySQL 은 Galera 노드가 SST 기증자 역할을 하는 동안 해당 노드를 사용 불가로 표시하여 offline_hostgroup 으로 이동한다 .
l wsrep_local_state : 해당 값이 동기화를 의미하는 4 이외의 값을 반환하면 ProxySQL 은 노드를 사용할 수 없는 것으로 표시하고 offline_hostgroup 으로 이동한다 .
l wsrep_local_recv_queue : 해당 값이 max_transactions_behind보다 높으면 노드가 회피된다 .
l wsrep_cluster_status : 이 상태가 기본이 아닌 다른 상태로 반환되면 ProxySQL 은 노드를 사용할 수 없는 것으로 표시하고 offline_hostgroup 으로 이동한다 .
ProxySQL 2.x 는 mysql_galera_hostgroups 의 매개변수와 mysql_query_rules 정책을 함께 결합함으로써 훨씬 더 다양한 Galera Cluster 구성에 대한 유연성을 갖게 되었다 . 예를 들어 쿼리 규칙의 대상 호스트 그룹으로 정의된 단일 쓰기 , 다중 쓰기 및 다중 읽기 호스트 그룹을 가질 수 있으며 , 쓰기 수를 제한하고 오래된 읽기 동작을 보다 세밀하게 제어할 수 있다 .
ProxySQL 에서 max_writers 및 writer_is_also_reader 변수는 ProxySQL 이 백엔드 MySQL 서버를 동적으로 그룹화하는 방법을 결정할 수 있으며 커넥션 분산 및 쿼리 라우팅에 직접적인 영향을 끼친다 . 예를 들어 아래와 같이 MySQL 백엔드 ( 노드 ) 서버가 등록되어 있다고 가정한다 . 등록된 노드는 아래 스크립트로 확인 가능하다 .
Admin> select hostgroup_id, hostname, status, weight from mysql_servers;
Admin> select hostgroup_id, hostname, status, weight from mysql_servers; +--------------+--------------+--------+--------+ | hostgroup_id | hostname | status | weight | +--------------+--------------+--------+--------+ | 10 | DB1 | ONLINE | 1 | | 10 | DB2 | ONLINE | 1 | | 10 | DB3 | ONLINE | 1 | +--------------+--------------+--------+--------+
그리고 현재 구성되어 있는 mysql_galera_hostgroup 의 설정도 살펴본다 .
Admin> select * from mysql_galera_hostgroups\G
Admin> select * from mysql_galera_hostgroups\G *************************** 1. row *************************** writer_hostgroup: 10 backup_writer_hostgroup: 20 reader_hostgroup: 30offline_hostgroup: 9999 active: 1 max_writers: 1 writer_is_also_reader: 2 max_transactions_behind: 20 comment:
현재 노드 설정에서 모든 호스트가 가동되어 실행 중임을 고려하면 ProxySQL 은 호스트를 아래와 같이 다양한 시나리오로 그룹화할 수 있다 .
위 그림에 따른 3 가지 케이스의 특징을 한번 살펴본다 .
Configuration Description
writer_is_also_reader=0 l 호스트를 2 개의 호스트 그룹 (writer 및 backup_writer) 으로 그룹화한다 . l Writer 는 backup_writer 의 일부이다 . l Write 는 Reader 가 아니므로 read_only=1 로 설정된 호스트가 없기 때문에 호스트 그룹 30(Reader) 에는 아무것도 없다 . 읽기 전용 플래그를 활성화하는 것은 Galera 에서 일반적인 관행이 아니다 .
writer_is_also_reader=1 l 호스트를 3 개의 호스트 그룹 (writer, backup_writer 및 reader) 으로 그룹화한다 . l Galera 의 변수 read_only=0 은 영향을 미치지 않으므로 writer 는 호스트 그룹 30(reader) 에도 있다 . l writer 는 backup_writer 의 일부가 아니다 .
writer_is_also_reader=2 l writer_is_also_reader=1 과 유사하지만 writer 는 backup_writer 의 일부이다 .
위 그룹 구성에 따른 특성을 활용하면 사용자는 특정 워크로드에 맞는 호스트 그룹 대상을 다양하게 선택할 수 있다 . " 핫스팟 " 쓰기는 다중 마스터 충돌을 줄이기 위해 하나의 서버로만 이동하도록 구성할 수 있다 . 충돌하지 않는 쓰기는 다른 마스터에 균등하게 분배될 수 있다 . 쓰기는 최신 서버로 전달될 수 있으며 분석 읽기는 슬레이브 복제본으로 전달될 수 있다 .
[Galera 클러스터용 ProxySQL 배포 ]
아래 그림과 같이 ClusterControl 에 의해 배포된 3 노드 Galera Cluster 가 구성되어 있다고 가정하고 , 시나리오를 만족하기 위해 클러스터를 세팅하는 과정을 다루어 본다 .
시나리오는 아래와 같다 .
WordPress 애플리케이션은 Docker 에서 실행되고 WordPress 데이터베이스는 베어메탈 서버에서 실행되는 Galera Cluster 에서 호스팅 된다 . 우리는 WordPress 데이터베이스 쿼리 라우팅을 더 잘 제어하고 데이터베이스 클러스터 인프라를 완전히 활용하기 위해 WordPress 컨테이너와 함께 ProxySQL 컨테이너를 실행하기로 결정했다 . 읽기 - 쓰기 비율이 약 80%-20% 이므로 ProxySQL 을 다음과 같이 구성하려고 한다 . l 모든 쓰기를 하나의 Galera 노드로 전달 ( 충돌 감소 , 쓰기에 집중 ) l 다른 두 Galera 노드에 대한 모든 읽기의 균형을 분배 ( 대부분의 워크로드에 대해 더 나은 분배 ).
위 시나리오를 만족할 수 있도록 ProxySQL 을 구성한다 . 먼저 컨테이너에 매핑할 수 있도록 Docker 호스트 내부에 ProxySQL 구성 파일을 만든다 .
$ mkdir /root/proxysql-docker $ vim /root/proxysql-docker/proxysql.cnf
아래와 같이 설정값을 입력한다 . ( 코드에 대한 자세한 설명은 아래부분에서 하나씩 설명한다 .)
datadir="/var/lib/proxysql" admin_variables= { admin_credentials="admin:admin" mysql_ifaces="0.0.0.0:6032" refresh_interval=2000 web_enabled=true web_port=6080 stats_credentials="stats:admin"} mysql_variables= { threads=4 max_connections=2048 default_query_delay=0 default_query_timeout=36000000 have_compress=true poll_timeout=2000 interfaces="0.0.0.0:6033;/tmp/proxysql.sock" default_schema="information_schema" stacksize=1048576 server_version="5.1.30" connect_timeout_server=10000 monitor_history=60000 monitor_connect_interval=200000 monitor_ping_interval=200000 ping_interval_server_msec=10000 ping_timeout_server=200 commands_stats=true sessions_sort=true monitor_username="proxysql" monitor_password="proxysqlpassword" monitor_galera_healthcheck_interval=2000 monitor_galera_healthcheck_timeout=800} mysql_galera_hostgroups = ( { writer_hostgroup=10 backup_writer_hostgroup=20 reader_hostgroup=30 offline_hostgroup=9999 max_writers=1 writer_is_also_reader=1 max_transactions_behind=30 active=1 }) mysql_servers = ( { address="db1.cluster.local" , port=3306 , hostgroup=10, max_connections=100 }, { address="db2.cluster.local" , port=3306 , hostgroup=10, max_connections=100 }, { address="db3.cluster.local" , port=3306 , hostgroup=10, max_connections=100 }) mysql_query_rules = ( { rule_id=100 active=1 match_pattern="^SELECT .* FOR UPDATE" destination_hostgroup=10 apply=1 }, { rule_id=200 active=1 match_pattern="^SELECT .*" destination_hostgroup=30 apply=1 }, { rule_id=300 active=1 match_pattern=".*" destination_hostgroup=10 apply=1 }) mysql_users = ( { username = "wordpress", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 }, { username = "sbtest", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 })
위 코드에서 살펴보면 mysql_galera_hostgroups 구성은 아래와 같이 정의되어 있다 .
mysql_galera_hostgroups = ( { writer_hostgroup=10 backup_writer_hostgroup=20 reader_hostgroup=30 offline_hostgroup=9999 max_writers=1 writer_is_also_reader=1 max_transactions_behind=30 active=1 })
writer 그룹은 10, backup 그룹은 20, reader 그룹은 30 으로 정의 되어있다 . max_writers 를 1 로 설정하여 모든 쓰기가 전송되어야 하는 호스트 그룹 10 에 대해 단일 쓰기로 작동하도록 하였다 . 그런 다음 writer_is_also_reader 를 1 로 정의하여 모든 Galera 노드를 읽기 노드에 참여할 수 있도록 하였다 . 이렇게 하면 읽기 요청은 모든 노드에 균등하게 배포할 수 있다 . Offline 그룹은 9999 이며 ProxySQL 이 작동하지 않는 Galera 노드를 감지한 경우 offline_hostgroup 으로 이동시킨다 .
mysql_servers 는 클러스터에 참여하는 노드 정보를 정의한다 . 시나리오에서는 모든 노드를 쓰기 가능한 호스트 그룹인 10 으로 MySQL 서버를 구성하였다 .
mysql_servers = ( { address="db1.cluster.local" , port=3306 , hostgroup=10, max_connections=100 }, { address="db2.cluster.local" , port=3306 , hostgroup=10, max_connections=100 }, { address="db3.cluster.local" , port=3306 , hostgroup=10, max_connections=100 })
위의 구성을 그림으로 표현하면 ProxySQL 은 아래와 같이 호스트 그룹을 구성하고 인식한다 .
mysql_query_rules 은 쿼리 라우팅을 정의한다 . 요구 사항에 따라 모든 읽기는 작성자 ( 호스트 그룹 20) 를 제외한 모든 Galera 노드로 전송되어야 하며 다른 모든 것은 단일 작성자의 호스트 그룹 10 으로 전달된다 .
mysql_query_rules = ( { rule_id=100 active=1 match_pattern="^SELECT .* FOR UPDATE" destination_hostgroup=10 apply=1 }, { rule_id=200 active=1 match_pattern="^SELECT .*" destination_hostgroup=20 apply=1 }, { rule_id=300 active=1 match_pattern=".*" destination_hostgroup=10 apply=1 })
마지막으로 ProxySQL 을 통해 전달될 MySQL 사용자를 정의한다 .
mysql_users = ( { username = "wordpress", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 }, { username = "sbtest", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 })
우리는 transaction_persistent 를 0 으로 설정하여 사용자로부터 오는 모든 연결이 읽기 및 쓰기 라우팅에 대한 쿼리 규칙을 준수하도록 한다 . 그렇지 않으면 연결이 하나의 호스트 그룹에 도달하게 되어 로드 밸런싱의 목적이 상실하기 때문이다 . 모든 MySQL 서버에서 해당 사용자를 먼저 생성하는 것을 잊지 않도록 한다 . ClusterControl 를 활용해서 사용자를 추가하는 경우 [ 관리 ] -> [ 스키마 및 사용자 기능 ] 을 사용하여 해당 사용자를 생성할 수 있다 .
설정 파일 생성이 완료되었으면 이제 컨테이너를 실행한다 . ProxySQL 컨테이너를 시작할 때 ProxySQL 구성 파일을 바인드 마운트로 매핑하기 때문에 아래와 같은 명령어로 실행한다 .
$ docker run -d --name proxysql2 --hostname proxysql2 --publish 6033:6033 --publish 6032:6032 --publish 6080:6080 --restart=unless-stopped -v /root/proxysql/proxysql.cnf:/etc/proxysql.cnf severalnines/proxysql:2.0
마지막으로 ProxySQL 컨테이너 포트 6033 을 가리키도록 WordPress 에서 데이터베이스 연결 포트를 변경한다 .
$ docker run -d --name wordpress --publish 80:80 --restart=unless-stopped -e WORDPRESS_DB_HOST=proxysql2:6033 -e WORDPRESS_DB_USER=wordpress -e WORDPRESS_DB_HOST=passw0rd wordpress
지금까지의 서비스 구성을 그림으로 표현하면 아래 아키텍처와 같다 .
ProxySQL 컨테이너를 영구적으로 유지하려면 /var/lib/proxysql/ 을 Docker 볼륨에 매핑하거나 바인드를 마운트 해야한다 . 아래 스크립트는 컨테이너 실행시 설정 파일을 영구 저장소로 바인드하는 예제이다 .
$ docker run -d --name proxysql2 --hostname proxysql2 --publish 6033:6033 --publish 6032:6032 --publish 6080:6080 --restart=unless-stopped -v /root/proxysql/proxysql.cnf:/etc/proxysql.cnf -v proxysql-volume:/var/lib/proxysql severalnines/proxysql:2.0
위와 같이 영구 저장소로 실행하면 컨테이너를 다시 시작 시 /root/proxysql/proxysql.cnf 를 사용하지 않는 다는 것에 주의한다 . 이는 /var/lib/proxysql/proxysql.db 가 존재하는 경우 ProxySQL 이 구성 파일에서 로드 옵션을 건너뛰고 대신 SQLite 데이터베이스에 있는 항목을 로드하는 ProxySQL 다중 계층 구성 때문이다 . ( – initial 플래그로 proxysql 서비스를 시작하면 설정 파일의 값으로 시작한다 .) ProxySQL 구성 관리는 구성 파일을 사용하는 대신 포트 6032 의 ProxySQL 관리 콘솔을 통해 수행해야 한다 .
ProxySQL 서비스 시작 시 사용하는 구성파일에 대한 자세한 정보는 아래 글을 참고한다 .
l ProxySQL 은 서비스에 필요한 설정값을 어디에 저장하고 재사용할까 ? : https://sungwookkang.com/1535
[Monitoring]
ProxySQL 프로세스 로그는 기본적으로 syslog 에 기록되며 표준 docker 명령을 사용하여 볼 수 있다 .
$ docker ps $ docker logs proxysql2
현재 ProxySQL 에서 운영중인 호스트 그룹을 확인하려면 runtime_mysql_servers 테이블을 쿼리한다 . 아래 스크립트는 호스트 환경에서 컨테이너의 ProxySQL 관리 콘솔에 접속한다 .
$ docker exec -it proxysql2 mysql -uadmin -padmin -h127.0.0.1 -P6032 --prompt='Admin> '
$ docker exec -it proxysql2 mysql -uadmin -padmin -h127.0.0.1 -P6032 --prompt='Admin> ' Admin> select hostgroup_id,hostname,status from runtime_mysql_servers; +--------------+--------------+--------+ | hostgroup_id | hostname | status | +--------------+--------------+--------+ | 10 | 192.168.0.21 | ONLINE | | 30 | 192.168.0.21 | ONLINE | | 30 | 192.168.0.22 | ONLINE | | 30 | 192.168.0.23 | ONLINE | | 20 | 192.168.0.22 | ONLINE | | 20 | 192.168.0.23 | ONLINE | +--------------+--------------+--------+
만약 특정 쓰기 노드가 다운되면 해당 노드는 offline_hostgroup (HID 9999) 으로 이동된다 . 예제에서는 192.168.0.21 노드가 다운되어 9999 그룹으로 이동되었다 .
Admin> select hostgroup_id,hostname,status from runtime_mysql_servers; +--------------+--------------+--------+ | hostgroup_id | hostname | status | +--------------+--------------+--------+ | 10 | 192.168.0.22 | ONLINE | | 9999 | 192.168.0.21 | ONLINE | | 30 | 192.168.0.22 | ONLINE | | 30 | 192.168.0.23 | ONLINE | | 20 | 192.168.0.23 | ONLINE | +--------------+--------------+--------+
위의 토폴로지 변경 사항은 아래 그림과 같다 .
ProxySQL 에서 admin-web_enabled=true 로 설정할 경우 웹 통계 UI 를 사용할 수 있다 . 웹 UI 에 액세스하려면 포트 웹브라우저로 Docker 호스트 6080 포트로 접속한다 . ( 예 , http://192.168.0.200:8060) 사용자 이름을 묻는 메시지가 표시되면 admin-stats_credentials 에 정의된 자격 증명을 입력한다 . 로그인하면 아래와 같은 통계 화면을 볼 수 있다 .
MySQL 연결 풀 테이블을 모니터링하면 모든 호스트 그룹에 대한 연결 분포 개요를 확인할 수 있다 .
Admin> select hostgroup, srv_host, status, ConnUsed, MaxConnUsed, Queries from stats.stats_mysql_connection_pool order by srv_host;
Admin> select hostgroup, srv_host, status, ConnUsed, MaxConnUsed, Queries from stats.stats_mysql_connection_pool order by srv_host; +-----------+--------------+--------+----------+-------------+---------+ | hostgroup | srv_host | status | ConnUsed | MaxConnUsed | Queries | +-----------+--------------+--------+----------+-------------+---------+ | 20 | 192.168.0.23 | ONLINE | 5 | 24 | 11458 | | 30 | 192.168.0.23 | ONLINE | 0 | 0 | 0 | | 20 | 192.168.0.22 | ONLINE | 2 | 24 | 11485 | | 30 | 192.168.0.22 | ONLINE | 0 | 0 | 0 | | 10 | 192.168.0.21 | ONLINE | 32 | 32 | 9746 | | 30 | 192.168.0.21 | ONLINE | 0 | 0 | 0 | +-----------+--------------+--------+----------+-------------+---------+
위의 출력 값을 살펴보면 쿼리 규칙에 의해 호스트 그룹 30 이 아무 것도 처리하지 않음을 알 수 있다 .
Galera 노드와 관련된 통계는 mysql_server_galera_log 테이블에서 볼 수 있다 .
> select * from mysql_server_galera_log order by time_start_us desc limit 3 \G
Admin> select * from mysql_server_galera_log order by time_start_us desc limit 3 \G *************************** 1. row *************************** hostname: 192.168.0.23 port: 3306 time_start_us: 1552992553332489 success_time_us: 2045 primary_partition: YES read_only: NO wsrep_local_recv_queue: 0 wsrep_local_state: 4 wsrep_desync: NO wsrep_reject_queries: NOwsrep_sst_donor_rejects_queries: NO error: NULL*************************** 2. row *************************** hostname: 192.168.0.22 port: 3306 time_start_us: 1552992553329653 success_time_us: 2799 primary_partition: YES read_only: NO wsrep_local_recv_queue: 0 wsrep_local_state: 4 wsrep_desync: NO wsrep_reject_queries: NOwsrep_sst_donor_rejects_queries: NO error: NULL*************************** 3. row *************************** hostname: 192.168.0.21 port: 3306 time_start_us: 1552992553329013 success_time_us: 2715 primary_partition: YES read_only: NO wsrep_local_recv_queue: 0 wsrep_local_state: 4 wsrep_desync: NO wsrep_reject_queries: NOwsrep_sst_donor_rejects_queries: NO error: NULL
쿼리 결과 내용은 특정 타임스탬프에 대한 모든 Galera 노드의 관련 MySQL 변수 / 상태 상태를 반환한다 . 이 구성에서는 Galera 상태 확인이 2 초마다 실행되도록 구성되어 있다 . (monitor_galera_healthcheck_interval=2000). 따라서 클러스터에 토폴로지 변경이 발생하는 경우 최대 장애 조치 시간은 약 2 초이다 .
지금까지 MySQL Galera 클러스터 환경에서 ProxySQL 을 조합하여 사용할 때 , 쓰기 , 읽기 그룹에 대한 정의와 ProxySQL 을 컨테이너로 구성하는 과정을 다루었다 . 실제 운영환경에서는 각자의 노드 구성과 SLA 가 모두 다르기 때문에 위 내용을 이해하고 잘 활용할 수 있도록 한다 .
[ 참고자료 ]
l How to Run and Configure ProxySQL 2.0 for MySQL Galera Cluster on Docker : https://severalnines.com/blog/how-run-and-configure-proxysql-20-mysql-galera-cluster-docker/
l ProxySQL 이란 무엇인가 : https://sungwookkang.com/1528
l MySQL/MariaDB 환경에서 다중 마스터 복제를 지원하는 Galera Cluster 알아보기 : https://sungwookkang.com/1536
l ProxySQL 은 서비스에 필요한 설정값을 어디에 저장하고 재사용할까 ? : https://sungwookkang.com/1535
2023-08-10 / Sungwook Kang / http://sungwookkang.com
MySQL, MariaDB, Galera Cluster, 마리아디비 , 마이에스큐엘 , 갈레라 클러스터 , MariaDB 복제 , MariaDB Cluster, MySQL Cluster, MariaDB Replication, MySQL, ProxySQL, ProxySQL 설정 , ProxySQL 구성관리 , ProxySQL 시작 , Proxy Container
