MySQL, MariaDB

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

SungWookKang 2023. 8. 10. 15:55
반응형

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

반응형