Loading...
MySQL 9.5 Reference Manual 9.5의 20.5.2 Restarting a Group의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
Group Replication은 그룹을 구성하는 일부 서버가 계획된 유지 보수나 예기치 않은 문제로 인해 현재 그룹에 참여할 수 없더라도 데이터베이스 서비스가 지속적으로 사용 가능하도록 설계되었습니다. 남아 있는 멤버들이 그룹의 과반수인 동안은 새로운 프라이머리를 선출하고 그룹으로서 동작을 계속할 수 있습니다. 그러나 복제 그룹의 모든 멤버가 그룹을 떠나고, STOP GROUP_REPLICATION statement 또는 시스템 셧다운에 의해 모든 멤버에서 Group Replication이 중지되면, 그룹은 이제 멤버들의 설정으로서 이론적으로만 존재하게 됩니다. 이 상황에서는 그룹을 다시 만들기 위해, 처음 시작하는 것과 마찬가지로 부트스트래핑을 통해 시작해야 합니다.
그룹을 처음 부트스트랩하는 것과 두 번째 이후에 부트스트랩하는 것의 차이점은, 후자의 경우에는 종료되었던 그룹의 멤버들이 중지되거나 장애가 발생한 순서에 따라 서로 다른 트랜잭션 집합을 가지고 있을 수 있다는 점입니다. 멤버는 다른 그룹 멤버들에 존재하지 않는 트랜잭션을 가지고 있다면 그룹에 조인할 수 없습니다. Group Replication의 경우, 여기에는 커밋 및 적용이 완료되어 gtid_executed GTID 집합에 있는 트랜잭션과, 아직 적용되지는 않았지만 인증된 트랜잭션(group_replication_applier 채널에 있음) 모두가 포함됩니다. 트랜잭션이 커밋되는 정확한 시점은 그룹에 대해 설정된 트랜잭션 일관성 수준에 따라 다릅니다(Section 20.5.3, “Transaction Consistency Guarantees” 참조). 그러나 Group Replication 그룹 멤버는 인증된 트랜잭션, 즉 해당 멤버가 그 트랜잭션을 커밋할 의도가 있음을 선언한 내용을 절대 제거하지 않습니다.
따라서 복제 그룹은 가장 최신의 멤버, 즉 가장 많은 트랜잭션을 실행하고 인증한 멤버부터 재시작해야 합니다. 그보다 적은 트랜잭션을 가진 멤버들은 이후 조인하여 분산 복구를 통해 누락된 트랜잭션을 따라잡을 수 있습니다. 그룹의 마지막으로 알려진 프라이머리 멤버가 그룹에서 가장 최신의 멤버라고 가정하는 것은 올바르지 않습니다. 프라이머리보다 나중에 종료된 멤버가 더 많은 트랜잭션을 가지고 있을 수 있기 때문입니다. 그러므로 각 멤버를 재시작하여 트랜잭션을 확인하고, 모든 트랜잭션 집합을 비교하여 가장 최신의 멤버를 식별해야 합니다. 그런 다음 이 멤버를 사용하여 그룹을 부트스트랩할 수 있습니다.
모든 멤버가 셧다운된 후 복제 그룹을 안전하게 재시작하려면 다음 절차를 따르십시오.
각 그룹 멤버에 대해, 순서는 상관없이 다음을 수행합니다.
클라이언트를 그룹 멤버에 연결합니다. Group Replication이 아직 중지되지 않았다면 STOP GROUP_REPLICATION statement를 실행하고 Group Replication이 중지될 때까지 기다립니다.
MySQL Server 설정 파일(일반적으로 Linux 및 Unix 시스템에서는 my.cnf, Windows 시스템에서는 my.ini)을 편집하여 시스템 변수 group_replication_start_on_boot=OFF를 설정합니다. 이 설정은 MySQL Server가 시작될 때(기본 동작) Group Replication이 시작되는 것을 방지합니다.
이 시스템에서 해당 설정을 변경할 수 없다면, 서버가 Group Replication을 시작하도록 그대로 두어도 되는데, 이 경우 그룹이 완전히 셧다운되었고 아직 부트스트랩되지 않았기 때문에 시작은 실패합니다. 이 방식을 선택하는 경우, 이 단계에서는 어떤 서버에서도 group_replication_bootstrap_group=ON을 설정하지 마십시오.
MySQL Server 인스턴스를 시작하고, Group Replication이 시작되지 않았는지(또는 시작에 실패했는지) 확인합니다. 이 단계에서는 Group Replication을 시작하지 마십시오.
그룹 멤버에서 다음 정보를 수집합니다.
gtid_executed GTID 집합의 내용. 다음 statement를 실행하여 확인할 수 있습니다:
1mysql> SELECT @@GLOBAL.GTID_EXECUTED
group_replication_applier 채널의 인증된 트랜잭션 집합. 다음 statement를 실행하여 확인할 수 있습니다:
1mysql> SELECT received_transaction_set FROM \ 2 performance_schema.replication_connection_status WHERE \ 3 channel_name="group_replication_applier";
모든 그룹 멤버에서 트랜잭션 집합을 수집한 후, 이를 비교하여 실행된 트랜잭션(gtid_executed)과 인증된 트랜잭션(group_replication_applier 채널에 있음)을 모두 포함했을 때 전체적으로 가장 큰 트랜잭션 집합을 가진 멤버를 찾습니다. 이는 GTID를 직접 살펴보며 수동으로 수행할 수도 있고, Section 19.1.3.8, “Stored Function Examples to Manipulate GTIDs”에 설명된 대로 스토어드 함수(stored function)를 사용하여 GTID 집합을 비교할 수도 있습니다.
가장 큰 트랜잭션 집합을 가진 멤버를 사용해 그룹을 부트스트랩합니다. 이를 위해 클라이언트를 그 그룹 멤버에 연결하고 다음 statement를 실행합니다:
1mysql> SET GLOBAL group_replication_bootstrap_group=ON; 2mysql> START GROUP_REPLICATION; 3mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
group_replication_bootstrap_group=ON 설정을 설정 파일에 저장하지 않는 것이 중요합니다. 그렇지 않으면 서버가 다시 시작될 때 동일한 이름의 두 번째 그룹이 설정됩니다.
그룹이 이제 이 창시자(founder) 멤버를 포함하여 존재하는지 확인하려면, 그룹을 부트스트랩한 멤버에서 다음 statement를 실행합니다:
1mysql> SELECT * FROM performance_schema.replication_group_members;
나머지 각 멤버를 그룹에 다시 추가하려면, 순서는 상관없이 각 멤버에서 START GROUP_REPLICATION statement를 실행합니다:
1mysql> START GROUP_REPLICATION;
각 멤버가 그룹에 조인했는지 확인하려면, 임의의 멤버에서 다음 statement를 실행합니다:
1mysql> SELECT * FROM performance_schema.replication_group_members;
멤버들이 그룹에 다시 조인한 후, 설정 파일을 편집하여 group_replication_start_on_boot=OFF를 설정해 두었다면, 이를 ON으로 다시 설정하거나, 시스템 변수를 제거할 수 있습니다(ON이 기본값이기 때문입니다).
20.5.1 Configuring an Online Group
20.5.3 Transaction Consistency Guarantees