Last Updated on 1월 9, 2024 by Jade(정현호)
안녕하세요
이번 포스팅에서는 이번 InnoDB Cluster 구성에 이어서 Cluster 설정 및 구성의 변경과 클러스터 관련 작업에 대해서 확인해보려고 합니다.
아래 이전 포스팅에서 이어지는 연재 포스팅 글입니다.
Contents
인스턴스 장애/복구
먼저 이전 포스팅까지 해서 Router 설정을 마무리함에 따라 접속이 가능한 상태가 되었습니다.
현재 클러스터의 상태는 아래와 같습니다.
• 클러스터 상태 조회
JS > var cluster = dba.getCluster()
JS > cluster.status()
{
"clusterName": "JadeCluster",
"defaultReplicaSet": {
"name": "default",
"primary": "ic-server1:3306",
"ssl": "REQUIRED",
"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
"topology": {
"ic-server1:3306": {
"address": "ic-server1:3306",
"mode": "R/W",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.23"
},
"ic-server2:3306": {
"address": "ic-server2:3306",
"mode": "R/O",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.23"
},
"ic-server3:3306": {
"address": "ic-server3:3306",
"mode": "R/O",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.23"
}
},
"topologyMode": "Single-Primary"
},
"groupInformationSourceMember": "ic-server1:3306"
}
이러한 상태에서 Primary 인스턴스의 장애 발생 및 인스턴스 복구에 따른 상태 변화 등을 살펴보도록 하겠습니다.
장애 발생
먼저 Primary(Master,Source) 에 접속을 시도 후에 접속된 MySQL 인스턴스 정보를 확인해보도록 하겠습니다.
-- Primary 접속 JS> \connect clusteradm@ic-router-1:6446 Creating a session to 'clusteradm@ic-router-1:6446' Please provide the password for 'clusteradm@ic-router-1:6446': ********** Fetching schema names for autocompletion... Press ^C to stop. Closing old connection... Your MySQL connection id is 212 Server version: 8.0.23 MySQL Community Server - GPL No default schema selected; type \use <schema> to set one. -- 접속 상태 조회 JS > \sql select user(),@@hostname,@@read_only; +-----------------------+------------+-------------+ | user() | @@hostname | @@read_only | +-----------------------+------------+-------------+ | clusteradm@ic-router1 | ic-server1 | 0 | +-----------------------+------------+-------------+
접속을 시도한 호스트는 MySQL 서버가 아닌 MySQL Router 이며, RW Role 인스턴스로 접속하기 위해서 6446 포트로 접속을 하였습니다. 접속된 곳은 현재 RW Role 을 가진 Primary 서버 ic-server1 로 접속된 것을 확인할 수 있습니다.
RW 이기 때문에 read_only 상태도 0 으로 확인되고 있습니다.
이 상태에서 ic-server1 의 MySQL 을 종료해보도록 하겠습니다.
ic-server1$ sudo systemctl stop mysqld ...
인스턴스가 종료가 되면 빠른 시간안에 Secondary 인스턴스 중에서 프로모션 되어 Primary 로 Role Change 가 되게 되며, 발생된 로그 및 상태 내역을 확인해보도록 하겠습니다.
• MySQL Router의 mysqlrouter.log
2022-09-19 02:09:26 routing INFO [7fefdffff700] [routing:JadeCluster_rw] resetting connection error counter for 10.0.2.15 from 1 back to 0
2022-09-19 02:10:33 metadata_cache WARNING [7fef9b7fe700] Cluster notification connection: error reading from the server ic-server1:33060; (err_code=2006; err_msg='MySQL server has gone away')
<-- 이 시점에 cluster 로 부터 ic-server1 이 접속이 되지 않음을 통지(notification) 받음
<-- 해당 내역은 use_gr_notifications 파라미터가 활성화(1) 되었을 경우 가능
2022-09-19 02:10:33 metadata_cache WARNING [7fef9b7fe700] Removing the node ic-server1:33060 from the notification thread
<-- notification thread 으로 ic-server1 이 제거 됨을 확인함
2022-09-19 02:10:33 metadata_cache WARNING [7fefecdd2700] Failed connecting with Metadata Server ic-server1:3306: Can't connect to MySQL server on 'ic-server1' (111) (2003)
2022-09-19 02:10:33 metadata_cache ERROR [7fefecdd2700] Failed to connect to metadata server 1b875030-3110-11ed-93e1-0800273eff76
2022-09-19 02:10:33 metadata_cache WARNING [7fefecdd2700] While updating metadata, could not establish a connection to replicaset 'default' through ic-server1:3306
2022-09-19 02:10:34 metadata_cache WARNING [7fefecdd2700] Failed connecting with Metadata Server ic-server1:3306: Can't connect to MySQL server on 'ic-server1' (111) (2003)
2022-09-19 02:10:34 metadata_cache ERROR [7fefecdd2700] Failed to connect to metadata server 1b875030-3110-11ed-93e1-0800273eff76
2022-09-19 02:10:34 metadata_cache WARNING [7fefecdd2700] While updating metadata, could not establish a connection to replicaset 'default' through ic-server1:3306
2022-09-19 02:10:34 metadata_cache WARNING [7fefecdd2700] Updating the router last_check_in in metadata failed: Could not connect to the writable cluster member
2022-09-19 02:10:34 metadata_cache WARNING [7fefecdd2700] Failed connecting with Metadata Server ic-server1:3306: Can't connect to MySQL server on 'ic-server1' (111) (2003)
< 동일 내용 반복 >
2022-09-19 02:10:37 metadata_cache INFO [7fefecdd2700] Potential changes detected in cluster 'JadeCluster' after metadata refresh
2022-09-19 02:10:37 metadata_cache INFO [7fefecdd2700] Metadata for cluster 'JadeCluster' has 1 replicasets:
2022-09-19 02:10:37 metadata_cache INFO [7fefecdd2700] 'default' (3 members, single-primary)
2022-09-19 02:10:37 metadata_cache INFO [7fefecdd2700] ic-server1:3306 / 33060 - mode=n/a
2022-09-19 02:10:37 metadata_cache INFO [7fefecdd2700] ic-server2:3306 / 33060 - mode=RW
2022-09-19 02:10:37 metadata_cache INFO [7fefecdd2700] ic-server3:3306 / 33060 - mode=RO
2022-09-19 02:10:37 routing INFO [7fefecdd2700] Routing routing:JadeCluster_rw listening on 6446 got request to disconnect invalid connections: metadata change
2022-09-19 02:10:37 routing INFO [7fefecdd2700] Routing routing:JadeCluster_x_rw listening on 64460 got request to disconnect invalid connections: metadata change
2022-09-19 02:10:37 routing INFO [7fefecdd2700] Routing routing:JadeCluster_x_ro listening on 64470 got request to disconnect invalid connections: metadata change
2022-09-19 02:10:37 routing INFO [7fefecdd2700] Routing routing:JadeCluster_ro listening on 6447 got request to disconnect invalid connections: metadata change
<-- metadata refresh 가 되면서 서버별 Role 이 재정의 되었음
• ic-server2의 mysqld 로그
2022-09-19T02:10:36.867027+09:00 0 [Warning] [MY-011499] [Repl] Plugin group_replication reported: 'Members removed from the group: ic-server1:3306'
2022-09-19T02:10:36.867061+09:00 0 [System] [MY-011500] [Repl] Plugin group_replication reported: 'Primary server with address ic-server1:3306 left the group. Electing new Primary.'
2022-09-19T02:10:37.868932+09:00 0 [System] [MY-011507] [Repl] Plugin group_replication reported: 'A new primary with address ic-server2:3306 was elected. The new primary will execute all previous group transactions before allowing writes.'
2022-09-19T02:10:37.869288+09:00 0 [System] [MY-011503] [Repl] Plugin group_replication reported: 'Group membership changed to ic-server2:3306, ic-server3:3306 on view 16635173605349938:4.'
2022-09-19T02:10:37.870656+09:00 60 [System] [MY-011566] [Repl] Plugin group_replication reported: 'Setting super_read_only=OFF.'
<-- 프로모션되면서 read_only=ON 에서 OFF 로 변경되어 쓰기가 가능해진 상태
2022-09-19T02:10:37.871626+09:00 60 [System] [MY-011510] [Repl] Plugin group_replication reported: 'This server is working as primary member.'
<-- 최종적으로 Primary 인스턴스가 된 것을 확인할 수 있음
• 클러스터 상태 조회
JS > var cluster = dba.getCluster()
JS > cluster.status()
{
"clusterName": "JadeCluster",
"defaultReplicaSet": {
"name": "default",
"primary": "ic-server2:3306",
"ssl": "REQUIRED",
"status": "OK_NO_TOLERANCE",
"statusText": "Cluster is NOT tolerant to any failures. 1 member is not active.", <!!----
"topology": {
"ic-server1:3306": {
"address": "ic-server1:3306",
"mode": "n/a",
"readReplicas": {},
"role": "HA",
"shellConnectError": "MySQL Error 2003 (HY000): Can't connect to MySQL server on 'ic-server1' (111)", <!!----
"status": "(MISSING)" <!!----
},
"ic-server2:3306": {
"address": "ic-server2:3306",
"mode": "R/W", <!!----
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.23"
},
"ic-server3:3306": {
"address": "ic-server3:3306",
"mode": "R/O",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.23"
}
},
"topologyMode": "Single-Primary"
},
"groupInformationSourceMember": "ic-server2:3306"
}
위의 클러스터 상태 를 통해서 알수 있는 것처럼 ic-server1 DB 인스턴스는 접속이 불가한 상태이며 ic-server2 의 인스턴스가 현재 Primary 인스턴가 된 것을 확인 할수 있습니다.
또한 "Cluster is NOT tolerant to any failures" 메세지의 내용처럼 InnoDB Cluster에서 장애복구를 위한 최소 정족수 3개를 충족하지 못하기 때문에 이와 같은 메세지가 확인되고 있습니다.
장애 감지 및 조치
위에서 간단하게 테스트한 내용처럼 Group Replication 은 일반 적인 Replication 과는 달리 데이터의 복제 이외 추가적으로 멤버의 장애 발생시 정상적으로 사용 가능 하도록 장애 감지 및 조치 메커니즘을 지원하고 있습니다.
위의 로그와 같이 인스턴스의 문제가 감지가 되면 그룹 복제에서 제외를 하고, Primary 가 문제가 발생하였을 경우, Secondary 중에서 프로모션 하여 새로운 Primary 로 변경하는 등의 작업을 자동으로 되는 기능을 제공하고 있습니다.
그룹 복제에서는 멤버 간의 계속적으로 상태에 대해서 체크를 하여 인스턴스의 장애나 다운 등을 감지하게 되며, 문제가 발생되었다고 의심이 되는 멤버에 대해서는 과반수의 멤버가 동의를 한다면 멤버를 추방하게 됩니다.
(그래서 최소 3개 이상의 정족수가 필요함)
장애 감지 및 추방까지의 timeout 또는 threadhold 개념으로 group_replication_member_expel_timeout 시스템 변수가 8.0.13 버전에서 추가되었습니다.
즉 group_replication_member_expel_timeout 시스템 변수는 그룹 복제 그룹 구성원의 장애를 의심을 생성한 후 실패한 것으로 의심되는 구성원을 그룹에서 추방하기 전에 기다리는 시간(초)을 지정합니다. 장애를 의심하기 전, 초기 5초 탐지 기간(시간)은 이 시간에 포함되지는 않습니다.
MySQL 8.0.20까지 group_replication_member_expel_timeout 기본값은 0으로, 대기 기간이 없으며 의심되는 회원은 5초의 탐지 기간이 종료된 후 즉시 추방을 하게당할 수 있음을 의미합니다. (5초 + 0초)
MySQL 8.0.21부터 해당 시스템 변수의 기본값이 5로 설정되며, 이는 의심되는 구성원을 5초 탐지 기간 후 5초 후에 추방을 할 수 있음을 의미합니다. (5초 + 5초)
group_replication_member_expel_timeout 시스템 변수는 8.0.14 버전 부터 최대 3600초(1시간) 까지만 설정할 수 있습니다.
네트워크가 불안정하고 또는 그런 환경이 잠시 발생하였을 때 그로 인해서 잠시 구성원 간의 연결을 끊었다가 다시 얻는 경우 등을 대비할 수 있는 시스템 변수로 불필요한 의심과 추방으로 Primary 프로모션이 발생할 수도 있기 때문입니다.
상황이나 환경에 따라서 해당 시스템 변수를 조금 더 크게 설정한 다면 위와 같은 경우 더 좋은 설정이 될 수도 있습니다.
다만 해당 시스템 변수를 크게 잡거나 늘린다면 기본값을 때보다 Primary 프로모션 과정이 조금 더 늦어질 수도 있습니다.
그래서 일시적인 네트워크 등의 작업이 명시적으로 예정이 되어있을 경우 작업 간에 해당 파라미터 값을 조금 더 늘려 두는 것도 한가지 방법이 될 수 있습니다.
처음에 접속한 세션에서 동일한 쿼리를 다시 수행해보도록 하겠습니다.
• 접속 인스턴스 정보 확인
JS > \sql select user(),@@hostname,@@read_only; ERROR: 2013 (HY000): Lost connection to MySQL server during query The global session got disconnected.. Attempting to reconnect to 'mysql://clusteradm@ic-router-1:6446'.. The global session was successfully reconnected. JS > \sql select user(),@@hostname,@@read_only; +-----------------------+------------+-------------+ | user() | @@hostname | @@read_only | +-----------------------+------------+-------------+ | clusteradm@ic-router1 | ic-server2 | 0 | +-----------------------+------------+-------------+
처음 쿼리시에는 맺어져 있던 세션이 접속이 끊긴 상태임으로 먼저 재접속을 시도하게 되고 다시 쿼리를 수행하게 되었을 때 위와 같은 정보가 출력되는 것을 확인할 수 있습니다.
RW 포트인 6446 으로 접속하였을 때 정상적으로 RW Role 인 Primary ic-server2 인스턴스로 접속이 된 것도 확인할 수 있습니다.
인스턴스 복구
이전 단계에서 중지한 ic-server1 의 MySQL 인스턴스를 다시 시작하도록 하겠습니다.
ic-server1$ sudo systemctl start mysqld ...
인스턴스가 시작된 다음 Primary 인스턴스인 ic-server2 에서 mysqld 로그에서 아래와 같이 ic-server1 인스턴스가 Replication group 내에서 온라인이 되었다는 내용을 확인 할 수 있습니다.
2022-09-19T04:14:50.584084+09:00 0 [System] [MY-011503] [Repl] Plugin group_replication reported: 'Group membership changed to ic-server1:3306, ic-server2:3306, ic-server3:3306 on view 16635173605349938:5.' 2022-09-19T04:14:54.312714+09:00 0 [System] [MY-011492] [Repl] Plugin group_replication reported: 'The member with address ic-server1:3306 was declared online within the replication group.'
ic-server1 인스턴스의 mysqld 로그에서도 Secondary 로 Group Replication 에 포함되는 내용의 로그를 확인할 수 있습니다.
2022-09-19T04:14:50.583586+09:00 2 [System] [MY-011511] [Repl] Plugin group_replication reported: 'This server is working as secondary member with primary member address ic-server2:3306.' 2022-09-19T04:14:51.597812+09:00 0 [System] [MY-013471] [Repl] Plugin group_replication reported: 'Distributed recovery will transfer data using: Incremental recovery from a group donor' 2022-09-19T04:14:51.598116+09:00 0 [System] [MY-011503] [Repl] Plugin group_replication reported: 'Group membership changed to ic-server1:3306, ic-server2:3306, ic-server3:3306 on view 16635173605349938:5.' < .. 중략 .. > 2022-09-19T04:14:53.986046+09:00 26 [System] [MY-010597] [Repl] 'CHANGE MASTER TO FOR CHANNEL 'group_replication_recovery' executed'. Previous state master_host='ic-server3', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='<NULL>', master_port= 0, master_log_file='', master_log_pos= 4, master_bind=''. 2022-09-19T04:14:54.312186+09:00 0 [System] [MY-011490] [Repl] Plugin group_replication reported: 'This server was declared online within the replication group.'
MySQL Router 로그에서도 기동된 ic-server1 인스턴스를 감지하고 RO Role 로 메타 데이터를 다시 갱신(refresh) 하는 내용의 로그를 확인할 수 있습니다.
2022-09-19 04:14:50 metadata_cache WARNING [7fefecdd2700] Member ic-server1:3306 (1b875030-3110-11ed-93e1-0800273eff76) defined in metadata not found in actual replicaset 2022-09-19 04:14:50 metadata_cache INFO [7fefecdd2700] Potential changes detected in cluster 'JadeCluster' after metadata refresh 2022-09-19 04:14:50 metadata_cache INFO [7fefecdd2700] Metadata for cluster 'JadeCluster' has 1 replicasets: 2022-09-19 04:14:50 metadata_cache INFO [7fefecdd2700] 'default' (3 members, single-primary) 2022-09-19 04:14:50 metadata_cache INFO [7fefecdd2700] ic-server1:3306 / 33060 - mode=n/a 2022-09-19 04:14:50 metadata_cache INFO [7fefecdd2700] ic-server2:3306 / 33060 - mode=RW 2022-09-19 04:14:50 metadata_cache INFO [7fefecdd2700] ic-server3:3306 / 33060 - mode=RO 2022-09-19 04:14:50 routing INFO [7fefecdd2700] Routing routing:JadeCluster_rw listening on 6446 got request to disconnect invalid connections: metadata change 2022-09-19 04:14:50 routing INFO [7fefecdd2700] Routing routing:JadeCluster_x_rw listening on 64460 got request to disconnect invalid connections: metadata change 2022-09-19 04:14:50 routing INFO [7fefecdd2700] Routing routing:JadeCluster_x_ro listening on 64470 got request to disconnect invalid connections: metadata change 2022-09-19 04:14:50 routing INFO [7fefecdd2700] Routing routing:JadeCluster_ro listening on 6447 got request to disconnect invalid connections: metadata change 2022-09-19 04:14:50 metadata_cache INFO [7fefecdd2700] Enabling notices for cluster changes 2022-09-19 04:14:50 metadata_cache INFO [7fefecdd2700] Enabling notices for cluster changes 2022-09-19 04:14:50 metadata_cache INFO [7fefecdd2700] Enabling notices for cluster changes 2022-09-19 04:14:54 metadata_cache INFO [7fefecdd2700] Potential changes detected in cluster 'JadeCluster' after metadata refresh 2022-09-19 04:14:54 metadata_cache INFO [7fefecdd2700] Metadata for cluster 'JadeCluster' has 1 replicasets: 2022-09-19 04:14:54 metadata_cache INFO [7fefecdd2700] 'default' (3 members, single-primary) 2022-09-19 04:14:54 metadata_cache INFO [7fefecdd2700] ic-server1:3306 / 33060 - mode=RO 2022-09-19 04:14:54 metadata_cache INFO [7fefecdd2700] ic-server2:3306 / 33060 - mode=RW 2022-09-19 04:14:54 metadata_cache INFO [7fefecdd2700] ic-server3:3306 / 33060 - mode=RO 2022-09-19 04:14:54 routing INFO [7fefecdd2700] Routing routing:JadeCluster_rw listening on 6446 got request to disconnect invalid connections: metadata change 2022-09-19 04:14:54 routing INFO [7fefecdd2700] Routing routing:JadeCluster_x_rw listening on 64460 got request to disconnect invalid connections: metadata change 2022-09-19 04:14:54 routing INFO [7fefecdd2700] Routing routing:JadeCluster_x_ro listening on 64470 got request to disconnect invalid connections: metadata change 2022-09-19 04:14:54 routing INFO [7fefecdd2700] Routing routing:JadeCluster_ro listening on 6447 got request to disconnect invalid connections: metadata change
클러스터 상태 역시 ic-server1 이 온라인이 된 것으로 확인되며, Role 의 경우 failback 없이(변화 없이) ic-server2 인스턴스가 Primary 인 RW 이고, 다시 온라인이 된 ic-server1 은 RO Role dl 이 된 것을 확인할 수 있습니다.
JS > var cluster = dba.getCluster()
JS > cluster.status()
{
"clusterName": "JadeCluster",
"defaultReplicaSet": {
"name": "default",
"primary": "ic-server2:3306",
"ssl": "REQUIRED",
"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
"topology": {
"ic-server1:3306": {
"address": "ic-server1:3306",
"mode": "R/O",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.23"
},
"ic-server2:3306": {
"address": "ic-server2:3306",
"mode": "R/W",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.23"
},
"ic-server3:3306": {
"address": "ic-server3:3306",
"mode": "R/O",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.23"
}
},
"topologyMode": "Single-Primary"
},
"groupInformationSourceMember": "ic-server2:3306"
}
InnoDB 클러스터 변경
MySQL Shell 을 이용하여 InnoDB 클러스터에 대해서 다양한 설정 변경을 진행할 수 있습니다.
현재 포스팅에서 사용하는 시스템은 싱글 프라이머리 모드로 동작중인 클러스터이며, 이전 단계에서 강제로 DB 를 중지하면서 Failover 된 상태이며 Secondary 중 하나의 인스턴스가 새로운 Primary 인스턴스로 프로모션 된 상태 임으로 다시 Primary 인스턴스 변경을 진행해보도록 하겠습니다.
Primary 변경
MySQL Shell 버전 8.0.14 부터 cluster.setPrimaryInstance() 를 이용하여 새로운 Primary 설정할 수 있습니다. Role 변경 과정에서 진행되는 트랜잭션은 실패할 수 있습니다.
현재 ic-server2 가 primary 이며, 이전 Primary 로 사용하였던 ic-server1 으로 다시 변경해보겠습니다.
• 명령어 수행
JS > var cluster = dba.getCluster()
JS > cluster.setPrimaryInstance('ic-server1:3306')
Setting instance 'ic-server1:3306' as the primary instance of cluster 'JadeCluster'...
Instance 'ic-server1:3306' was switched from SECONDARY to PRIMARY.
Instance 'ic-server2:3306' was switched from PRIMARY to SECONDARY.
Instance 'ic-server3:3306' remains SECONDARY.
WARNING: The cluster internal session is not the primary member anymore. For cluster management operations please obtain a fresh cluster handle using dba.getCluster().
The instance 'ic-server1:3306' was successfully elected as primary.
JS >
수행한 명령어의 의미와 같이 ic-server1 이 프로모션 되어 Primary 가 되었으며, ic-server2 는 Secondary 로 변경되었습니다.
HA 툴 마다 Role 변경 간에 재시작 등이 필요한 경우가 있는 경우도 있으나 Group Replication 에서는 Role 변경에 따른 재시작 없이 진행되는 것을 확인할 수 있습니다.
• ic-server1 의 mysqld 로그 내역
431358 [System] [MY-013214] [Repl] Plugin group_replication reported: 'Starting group operation local execution: Primary election change' 0 [System] [MY-011507] [Repl] Plugin group_replication reported: 'A new primary with address ic-server1:3306 was elected. The new primary will execute all previous group transactions before allowing writes. Enabling conflict detection until the new primary applies all relay logs.' 431363 [System] [MY-011566] [Repl] Plugin group_replication reported: 'Setting super_read_only=OFF.' 431363 [System] [MY-011510] [Repl] Plugin group_replication reported: 'This server is working as primary member.' 0 [System] [MY-013213] [Repl] Plugin group_replication reported: 'Configuration operation 'Primary election change' terminated. Primary server switched to: 1b875030-3110-11ed-93e1-0800273eff76'
클러스터 멤버 제거 및 추가
현재 InnoDB Cluster 에는 총 3개의 서버로 구성되어 있으며, 인스턴스의 제거는 장비의 교체 등의 여러 사유로 진행할 수도 있는 클러스터 변경 항목입니다.
cluster.removeInstance() 를 통해서 진행할 수 있으며, 인스턴스를 클러스터 멤버에서 제거하더라도 데이터는 삭제되지 않습니다.
• 명령어 수행
JS > var cluster = dba.getCluster()
JS > cluster.removeInstance('clusteradm@ic-server3:3306')
The instance will be removed from the InnoDB cluster. Depending on the instance
being the Seed or not, the Metadata session might become invalid. If so, please
start a new session to the Metadata Storage R/W instance.
Instance 'ic-server3:3306' is attempting to leave the cluster...
The instance 'ic-server3:3306' was successfully removed from the cluster.
명령어 수행 시 주의할 점은 해당 명령어는 y/n 을 물어보지 않고 수행하면 즉시 수행되어 멤버에서 제거가 수행됩니다.
제거 명령어 수행시점에 해당 인스턴스에서 아직 완료되지 않은 트랜잭션이 존재한다면 제거 명령은 정해진 timeout 만큼을 기다리게 됩니다.
dba.gtidWaitTimeout 으로 기본 60초이며, 해당 시간동안 진행 중인 트랜잭션이 종료(완료) 되지 못한다면 정해진 remove 명령어는 정해진 시간만큼 기다린 후에 결국 실패하게 됩니다.
{force:true} 을 사용하면 Timeout 이 되더라도 강제로 제거를 수행하게 됩니다
shell.options 명령어를 통해서 변수 값을 확인할 수 있으며 아래와 같이 수행합니다.
JS > shell.options['dba.gtidWaitTimeout'] 60
만약 서버의 문제나 기타 문제로 제거하려는 MySQL 인스턴스가 시작되지 못하는 상태(클러스터 멤버로 online 할수 없는 상태) 라면 아래와 같은 메세지와 y/n 을 물어보게 되고 y 를 눌러서 강제로 제거할 수 있습니다.
JS > cluster.removeInstance('clusteradm@ic-server3:3306')
WARNING: MySQL Error 2003 (HY000): Can't connect to MySQL server on 'ic-server3' (111)
ERROR: The instance 'ic-server3:3306' is not reachable and cannot be safely removed from the cluster.
To safely remove the instance from the cluster, make sure the instance is back ONLINE and try again.
If you are sure the instance is permanently unable to rejoin the group and no longer connectable, use the 'force' option to remove it from the metadata.
Do you want to continue anyway (only the instance metadata will be removed)? [y/N]: y <!!----
InnoDB 클러스터 멤버로 추가하기 위해서는 cluster.addInstance 명령어를 통해서 아래와 같이 진행할 수 있습니다.
JS > cluster.addInstance('clusteradm@ic-server3:3306')
The safest and most convenient way to provision a new instance is through automatic clone provisioning,
which will completely overwrite the state of 'ic-server3:3306' with a physical snapshot from an existing cluster member.
To use this method by default, set the 'recoveryMethod' option to 'clone'.
The incremental state recovery may be safely used if you are sure all updates ever executed in the cluster were done with GTIDs enabled,
there are no purged transactions and the new instance contains the same GTID set as the cluster or a subset of it.
To use this method by default, set the 'recoveryMethod' option to 'incremental'.
Incremental state recovery was selected because it seems to be safely usable.
Validating instance configuration at ic-server3:3306...
This instance reports its own address as ic-server3:3306
Instance configuration is suitable.
NOTE: Group Replication will communicate with other members using 'ic-server3:33061'. Use the localAddress option to override.
A new instance will be added to the InnoDB cluster. Depending on the amount of
data on the cluster this might take from a few seconds to several hours.
Adding instance to the cluster...
Monitoring recovery process of the new cluster member. Press ^C to stop monitoring and let it continue in background.
Incremental state recovery is now in progress.
* Waiting for distributed recovery to finish...
NOTE: 'ic-server3:3306' is being recovered from 'ic-server1:3306'
* Distributed recovery has finished
The instance 'ic-server3:3306' was successfully added to the cluster.
클러스터 해제
클러스터 해제는 cluster.dissolve() 명령어를 통해서 진행할 수 있습니다.
• 명령어 수행
JS > var cluster = dba.getCluster()
JS > cluster.dissolve()
The cluster still has the following registered instances:
{
"clusterName": "JadeCluster",
"defaultReplicaSet": {
"name": "default",
"topology": [
{
"address": "ic-server1:3306",
"label": "ic-server1:3306",
"role": "HA"
},
{
"address": "ic-server2:3306",
"label": "ic-server2:3306",
"role": "HA"
},
{
"address": "ic-server3:3306",
"label": "ic-server3:3306",
"role": "HA"
}
],
"topologyMode": "Single-Primary"
}
}
WARNING: You are about to dissolve the whole cluster and lose the high availability features provided by it.
This operation cannot be reverted. All members will be removed from the cluster and replication will be stopped,
internal recovery user accounts and the cluster metadata will be dropped. User data will be maintained intact in all instances.
Are you sure you want to dissolve the cluster? [y/N]: y <!!----
Instance 'ic-server2:3306' is attempting to leave the cluster...
Instance 'ic-server3:3306' is attempting to leave the cluster...
Instance 'ic-server1:3306' is attempting to leave the cluster...
The cluster was successfully dissolved.
Replication was disabled but user data was left intact.
클러스터에 관한 메타데이터 설정 정보 등을 삭제하며 복구를 위한 internal recovery user 를 삭제하게 되며, 사용자 데이터는 삭제하지 않습니다.
클러스터 모드 변경
InnoDB 클러스터 모드는 Single Primary Mode 와 Multi Primary Mode 가 있으며, InooDB Cluster 구성 시 기본적으로는 Single Primary Mode 로 구성이 됩니다.
쓰기 부하 분산 및 가용성 증가를 위해서 Multi Primary Mode 로 사용하고자 할 수 있으며, 그럴 경우 손쉽게 변경할 수 있습니다.
물론 Multi Primary Mode 에서 Single Primary Mode 로도 변경이 가능 하며, 작업은 8.0.14 버전 이상일 경우 클러스터 중지 없이 온라인 으로 변경이 가능 합니다.
Single -> Multi
이전에 해체한 클러스터는 다시 Single Primary Mode 로 구성해 둔 상태이고, 해당 상태에서 모드를 전환해보도록 하겠습니다.
MySQL 의 격리수준을 설정하는 시스템변수는 transaction_isolation 으로 기본 값은 REPEATABLE-READ 입니다. InnoDB Cluster 문서에서는 특별하게 REPEATABLE-READ 격리 수준을 사용하여 트랜잭션 제어를 하는 것이 아니라면 Multi Primary Mode 에서는 READ-COMMITTED 를 권장하고 있습니다.
For a group in multi-primary mode, unless you rely on REPEATABLE READ semantics in your applications, we recommend using the READ COMMITTED isolation level with Group Replication. InnoDB does not use gap locks in READ COMMITTED, which aligns the local conflict detection within InnoDB with the distributed conflict detection performed by Group Replication. For a group in single-primary mode, only the primary accepts writes, so the READ COMMITTED isolation level is not important to Group Replication.
위와 같은 내용으로 포스팅에서도 transaction_isolation 을 READ-COMMITTED 으로 변경을 하고 진행을 하도록 하겠습니다.
시스템 변수를 변경하는 방법은 set global 로 변경하거나 SET PERSIST 을 이용해서 진행할 수 있습니다.
InnoDB Cluster 를 구성하기 전에 instance configure 단계에서 필요한 파라미터는 SET PERSIST 를 통해서 진행하였습니다.
그래서 지금 사용하는 시스템에서는 SET PERSIST 으로 적용된 파라미터가 있으므로 포스팅에서는 SET PERSIST 을 통해서 설정하도록 하겠습니다.(SET PERSIST 으로 수행하는 것이 필수는 아님)
• 시스템 변수 변경(3개 인스턴스 모두에서 수행)
-- 시스템 변수 변경 mysql> SET PERSIST transaction_isolation = 'READ-COMMITTED'; -- 시스템 변수 변경 확인 mysql> show global variables like 'transaction_isolation'; +-----------------------+----------------+ | Variable_name | Value | +-----------------------+----------------+ | transaction_isolation | READ-COMMITTED | +-----------------------+----------------+ -- 시스템 변수 변경 확인 mysql> select * from performance_schema.persisted_variables where VARIABLE_NAME='transaction_isolation'; +-----------------------+----------------+ | VARIABLE_NAME | VARIABLE_VALUE | +-----------------------+----------------+ | transaction_isolation | READ-COMMITTED | +-----------------------+----------------+
[참고] SET PERSIST 에 관한 자세한 내용은 이전 포스팅을 참조하시면 됩니다.
• 모드 변경 수행(to Multi Primary)
JS > cluster.switchToMultiPrimaryMode() Switching cluster 'JadeCluster' to Multi-Primary mode... Instance 'ic-server1:3306' remains PRIMARY. Instance 'ic-server2:3306' was switched from SECONDARY to PRIMARY. Instance 'ic-server3:3306' was switched from SECONDARY to PRIMARY. The cluster successfully switched to Multi-Primary mode.
Multi -> Single
• 모드 변경 수행(to Single Primary)
JS > cluster.switchToSinglePrimaryMode('ic-server1:3306')
Switching cluster 'JadeCluster' to Single-Primary mode...
Instance 'ic-server1:3306' remains PRIMARY.
Instance 'ic-server2:3306' was switched from PRIMARY to SECONDARY.
Instance 'ic-server3:3306' was switched from PRIMARY to SECONDARY.
WARNING: Existing connections that expected a R/W connection must be disconnected, i.e. instances that became SECONDARY.
The cluster successfully switched to Single-Primary mode.
Single Mode 로 변경하는 명령어인 switchToSinglePrimaryMode 에서는 명시적으로 인자 값을 통해서 Single Mode 전환 시 Primary 가 될 서버를 지정할 수 있으며, 명령어에 별도의 인자 값(서버 명) 없이 수행을 하게 되면 Group Replication의 내부적인 Primary Instance 선출 로직에 따라서 Primary 서버가 결정되게 됩니다.
위에서 확인되는 메세지 내용 처럼 Multi -> Single 로 전환시에는 애플리케이션에서 잠시 접속이 끊길 수 있거나 쓰기의 에러가 발생은 될 수 있습니다.
이번 포스팅은 여기에서 마무리하도록 하겠습니다.
이어지는 다음 글
Reference
Reference URL
• mysql.com/innodb-cluster-working-with-cluster
• mysql.com/mysql-shell-8-0-14
• mysql.com/group-replication-multi-primary-mode
연관된 다른 글
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
