MySQL Galera Cluster + ProxySQL에서 Galera Cluster 특성을 고려한 R/W 호스트 그룹 설정 하기

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: 30 offline_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: NO wsrep_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: NO wsrep_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: NO wsrep_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