Loading...
MySQL 9.5 Reference Manual 9.5의 20.7.8 Handling a Network Partition and Loss of Quorum의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
그룹은 복제해야 하는 변경이 발생할 때마다 합의를 달성해야 합니다. 이는 일반적인 트랜잭션의 경우일 뿐 아니라, 그룹 멤버십 변경과 그룹을 일관되게 유지하는 일부 내부 메시징에도 필요합니다. 합의는 특정 결정에 대해 그룹 멤버의 과반수가 동의하는 것을 요구합니다. 그룹 멤버의 과반수가 손실되면, 그룹은 진행할 수 없게 되며, 과반수 또는 quorum을 확보할 수 없으므로 block됩니다.
여러 번의 비자발적인 장애로 인해 서버의 과반수가 그룹에서 갑자기 제거되면 quorum을 상실할 수 있습니다. 예를 들어 5개 서버로 구성된 그룹에서, 그 중 3개가 한 번에 침묵 상태가 되면, 과반수가 훼손되고 따라서 quorum을 달성할 수 없습니다. 사실 남은 두 서버는 나머지 3개 서버가 crash했는지, 아니면 network partition으로 인해 이 2개만 고립되었는지를 알 수 없으므로, 그룹을 자동으로 재구성할 수 없습니다.
반면, 서버가 자발적으로 그룹에서 나가면, 그룹에게 스스로 재구성해야 한다고 지시합니다. 실제로 이는 떠나는 서버가 다른 서버들에게 자신이 떠난다고 알리는 것을 의미합니다. 이로 인해 다른 멤버들은 그룹을 적절하게 재구성할 수 있고, 멤버십의 일관성이 유지되며, 과반수가 재계산됩니다. 예를 들어 위의 5개 서버 시나리오에서 3개가 한 번에 떠난다면, 떠나는 3개 서버가 하나씩 그룹에 떠난다고 알리면, 멤버십은 5에서 2로 스스로 조정할 수 있고, 동시에 그 과정에서 quorum을 확보할 수 있습니다.
참고
Quorum 상실은 그 자체로 잘못된 계획의 부작용입니다. 예상되는 장애 수(연속적이든, 한 번에 발생하든, 산발적이든 상관없이)에 맞게 그룹 크기를 계획하십시오.
single-primary mode의 그룹의 경우, primary는 network partition 시점에 아직 다른 멤버에 존재하지 않는 트랜잭션들을 가지고 있을 수 있습니다. primary를 새로운 그룹에서 제외하는 것을 고려 중이라면, 해당 트랜잭션들이 손실될 수 있음을 인지해야 합니다. 추가 트랜잭션을 가진 멤버는 그룹에 재참여할 수 없으며, 시도 시 다음과 같은 메시지가 포함된 에러가 발생합니다:
This member has more executed transactions than those
present in the group.
이 상황을 피하려면 그룹 멤버에 대해 group_replication_unreachable_majority_timeout 시스템 변수(system variable)를 설정하십시오.
다음 섹션에서는 시스템이 partition되어 그룹의 서버들이 자동으로 quorum을 달성하지 못하는 방식으로 분할된 경우 어떻게 해야 하는지 설명합니다.
replication_group_members Performance Schema 테이블은 이 서버의 관점에서 현재 뷰에 있는 각 서버의 상태를 보여 줍니다. 대부분의 시간 동안 시스템은 partitioning에 부딪히지 않으므로, 이 테이블은 그룹의 모든 서버에서 일관된 정보를 보여 줍니다. 다시 말해, 이 테이블에 있는 각 서버의 상태는 현재 뷰에서 모두가 동의하는 상태입니다. 그러나 network partitioning이 발생하고 quorum이 상실되면, 이 테이블은 연락할 수 없는 서버들에 대해 UNREACHABLE 상태를 표시합니다. 이 정보는 Group Replication에 내장된 로컬 장애 감지기(local failure detector)에 의해 export됩니다.
Figure 20.14 Losing Quorum
이러한 유형의 network partition을 이해하기 위해, 다음 섹션에서는 처음에는 5개 서버가 제대로 함께 동작하고 있다가, 이후 그룹에서 2개 서버만 online 상태가 되었을 때 그룹에 발생하는 변경 사항을 설명합니다. 이 시나리오는 figure에 나타나 있습니다.
따라서, 다음의 5개 서버로 구성된 그룹이 있다고 가정해 봅시다.
member identifier가 199b2df7-4aaf-11e6-bb16-28b2bd168d07인 서버 s1
member identifier가 199bb88e-4aaf-11e6-babe-28b2bd168d07인 서버 s2
member identifier가 1999b9fb-4aaf-11e6-bb54-28b2bd168d07인 서버 s3
member identifier가 19ab72fc-4aaf-11e6-bb51-28b2bd168d07인 서버 s4
member identifier가 19b33846-4aaf-11e6-ba81-28b2bd168d07인 서버 s5
초기에 그룹은 잘 동작하고 있으며, 서버들은 서로 원활하게 통신하고 있습니다. s1에 로그인해서 replication_group_members Performance Schema 테이블을 확인하여 이를 검증할 수 있습니다. 예를 들어:
1mysql> SELECT MEMBER_ID,MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members; 2+--------------------------------------+--------------+-------------+ 3| MEMBER_ID | MEMBER_STATE | MEMBER_ROLE | 4+--------------------------------------+--------------+-------------+ 5| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | ONLINE | SECONDARY | 6| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE | PRIMARY | 7| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE | SECONDARY | 8| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | ONLINE | SECONDARY | 9| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | ONLINE | SECONDARY | 10+--------------------------------------+--------------+-------------+
그러나 잠시 후 치명적인 장애가 발생하여 서버 s3, s4, s5가 예기치 않게 중지됩니다. 몇 초 후, s1에서 다시 replication_group_members 테이블을 확인하면, s1은 여전히 online 상태지만 다른 여러 멤버는 그렇지 않은 것을 볼 수 있습니다. 실제로 아래에서 보듯이 그들은 UNREACHABLE로 표시됩니다. 더욱이 시스템은 멤버십을 변경하기 위해 스스로 재구성할 수 없는데, 과반수가 상실되었기 때문입니다.
1mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members; 2+--------------------------------------+--------------+ 3| MEMBER_ID | MEMBER_STATE | 4+--------------------------------------+--------------+ 5| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | UNREACHABLE | 6| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE | 7| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE | 8| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | UNREACHABLE | 9| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | UNREACHABLE | 10+--------------------------------------+--------------+
이 테이블은 s1이 이제 과반수 서버에 접근할 수 없으므로 외부 개입 없이는 진행할 수 없는 그룹에 속해 있음을 보여 줍니다. 이 특정 사례에서 시스템이 계속 진행할 수 있도록 그룹 멤버십 목록을 reset해야 하며, 이는 이 섹션에서 설명합니다. 또는 s1과 s2에서 Group Replication을 중지(또는 s1과 s2 서버 자체를 완전히 중지)한 다음, s3, s4, s5에 어떤 일이 발생했는지 파악하고 Group Replication(또는 서버)을 다시 시작하는 방법도 선택할 수 있습니다.
Group replication은 특정 configuration을 강제로 설정하여 그룹 멤버십 목록을 reset할 수 있게 해 줍니다. 예를 들어 위 사례에서 s1과 s2만 online 상태인 경우, s1과 s2로만 구성된 멤버십 configuration을 강제로 설정할 수 있습니다. 이를 위해 s1과 s2에 대한 일부 정보를 확인한 후 group_replication_force_members 변수를 사용합니다.
Figure 20.15 Forcing a New Membership
다시 s1과 s2만이 그룹에 남아 있는 상황이라고 가정해 봅시다. 서버 s3, s4, s5는 예기치 않게 그룹을 떠났습니다. 서버 s1과 s2가 계속 동작하도록 하려면, s1과 s2만 포함하는 멤버십 configuration을 강제로 설정하려고 합니다.
주의
이 절차는 group_replication_force_members를 사용하며, 최후의 수단으로 간주해야 합니다. 이는 quorum 상실을 무시하기 위한 용도로만, 극도로 주의하여 사용해야 합니다. 잘못 사용하면 인위적인 split-brain 시나리오를 만들거나 전체 시스템을 완전히 block시킬 수 있습니다.
새로운 멤버십 configuration을 강제할 때, 그룹에서 강제로 제외할 서버가 실제로 중지되어 있는지 반드시 확인하십시오. 위 시나리오에서 s3, s4, s5가 실제로는 unreachable 상태가 아니라 여전히 online이라면, 이들은 자체적인 functional partition을 형성했을 수 있습니다(5개 중 3개이므로 과반수를 가집니다). 이 경우, s1과 s2로 이루어진 그룹 멤버십 목록을 강제하면 인위적인 split-brain 상황을 만들 수 있습니다. 따라서 새로운 멤버십 configuration을 강제하기 전에, 제외하려는 서버가 실제로 shutdown되어 있는지 확인하는 것이 중요하며, 그렇지 않다면 진행하기 전에 해당 서버들을 shutdown해야 합니다.
주의
single-primary mode의 그룹의 경우, primary는 network partition 시점에 아직 다른 멤버에 존재하지 않는 트랜잭션들을 가지고 있을 수 있습니다. primary를 새로운 그룹에서 제외하는 것을 고려 중이라면, 해당 트랜잭션들이 손실될 수 있음을 인지해야 합니다. 추가 트랜잭션을 가진 멤버는 그룹에 재참여할 수 없으며, 시도 시 다음과 같은 메시지가 포함된 에러가 발생합니다:
This member has more executed
transactions than those present in the group.
이 상황을 피하려면 그룹 멤버에 대해 group_replication_unreachable_majority_timeout 시스템 변수를 설정하십시오.
시스템은 block된 상태이며, 현재 configuration은 (s1의 로컬 장애 감지기 관점에서) 다음과 같습니다.
1mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members; 2+--------------------------------------+--------------+ 3| MEMBER_ID | MEMBER_STATE | 4+--------------------------------------+--------------+ 5| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | UNREACHABLE | 6| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE | 7| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE | 8| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | UNREACHABLE | 9| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | UNREACHABLE | 10+--------------------------------------+--------------+
가장 먼저 할 일은 s1과 s2의 로컬 주소(group communication identifier)가 무엇인지 확인하는 것입니다. s1과 s2에 로그인하여 다음과 같이 해당 정보를 가져옵니다.
1mysql> SELECT @@group_replication_local_address;
s1의 group communication address가 (127.0.0.1:10000), s2의 group communication address가 (127.0.0.1:10001)라는 것을 알았다면, 두 서버 중 하나에서 이를 사용하여 새로운 멤버십 configuration을 주입해, quorum을 상실한 기존 configuration을 대체할 수 있습니다. s1에서 이를 수행하려면:
1mysql> SET GLOBAL group_replication_force_members="127.0.0.1:10000,127.0.0.1:10001";
이는 다른 configuration을 강제하여 그룹의 block 상태를 해제합니다. 이 변경 이후의 그룹 멤버십을 검증하기 위해, s1과 s2 양쪽에서 replication_group_members를 확인하십시오. 먼저 s1에서 확인합니다.
1mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members; 2+--------------------------------------+--------------+ 3| MEMBER_ID | MEMBER_STATE | 4+--------------------------------------+--------------+ 5| b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | ONLINE | 6| b60907e7-4ab6-11e6-afb7-28b2bd168d07 | ONLINE | 7+--------------------------------------+--------------+
그 다음 s2에서 확인합니다.
1mysql> SELECT * FROM performance_schema.replication_group_members; 2+--------------------------------------+--------------+ 3| MEMBER_ID | MEMBER_STATE | 4+--------------------------------------+--------------+ 5| b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | ONLINE | 6| b60907e7-4ab6-11e6-afb7-28b2bd168d07 | ONLINE | 7+--------------------------------------+--------------+
group_replication_force_members 시스템 변수를 사용하여 새로운 그룹 멤버십을 성공적으로 강제하고 그룹의 block 상태를 해제한 후에는, 반드시 해당 시스템 변수를 비워야 합니다. START GROUP_REPLICATION 문을 실행하려면 group_replication_force_members가 비어 있어야 합니다.
20.7.7 Responses to Failure Detection and Network Partitioning
20.7.9 Monitoring Group Replication Memory Usage with Performance Schema Memory Instrumentation
