2. 그룹 복제 기술 아키텍처에 대한 간단하고 심층적인 설명 |

전통적인 마스터-슬레이브 복제 방식은 마스터 노드에서 데이터 업데이트 트랜잭션을 수행한 후 이 트랜잭션을 binlog에 기록한 다음 binlog를 슬레이브 노드로 보내 릴레이 로그에 덤프하는 방식입니다. 그런 다음 슬레이브 노드에 저장합니다. 별도의 스레드가 이러한 릴레이 로그를 읽은 다음 이러한 트랜잭션을 다시 실행하거나 적용합니다. 각 노드에는 데이터의 완전한 복사본이 있습니다.

MySQL 또한 기존 마스터-슬레이브 복제에 동기화 단계를 추가하는 반동기 복제를 제공합니다. 마스터 노드에 트랜잭션을 제출하기 전에 슬레이브 노드가 트랜잭션 정보 수신을 확인할 때까지 기다려야 합니다. (이것이 앞서 슬레이브 느린 노드 응답이 마스터 노드의 트랜잭션 제출에 영향을 미친다고 말한 이유입니다.) 기술 흐름도는 다음과 같습니다.

MGR도 공유되지 않습니다. 데이터의 완전한 사본을 생성하고 노드 간에 GCS(그룹 통신 시스템)를 사용하여 상호 작용합니다. GCS 계층은 노드 간 전역 메시지를 제공하고 질서를 보장합니다.

MGR은 언제든지 모든 노드에서 읽기-쓰기 트랜잭션(읽기 전용 트랜잭션 제외)을 실행할 수 있습니다. 그러나 읽기-쓰기 트랜잭션은 제출하기 전에 전체 복제 그룹에서 확인되어야 합니다. 읽기 전용 트랜잭션인 경우에는 그러한 제한이 없으며 모든 노드가 이를 시작하고 제출할 수 있습니다.

읽기-쓰기 트랜잭션이 커밋될 준비가 되면 트랜잭션에 의해 수정된 데이터와 해당 쓰기 세트를 포함하여 원자 브로드캐스트를 복제 그룹에 보냅니다. 복제 그룹의 모든 노드가 트랜잭션을 수신하거나 아무 노드도 수신하지 않습니다. 그룹의 모든 노드가 트랜잭션 메시지를 수신하면 이전에 트랜잭션이 전송된 순서와 동일한 순서로 모두 브로드캐스트 메시지를 수신합니다. 따라서 모든 그룹 구성원은 동일한 순서로 트랜잭션 쓰기 세트를 수신하고 트랜잭션에 대한 전역 순서가 설정됩니다.

여러 노드에서 병렬로 실행되는 트랜잭션은 충돌이 발생할 수 있습니다. 이 경우 확인을 위해 두 병렬 트랜잭션의 쓰기 세트를 비교하고 결정해야 합니다. 이 프로세스를 충돌 감지라고도 합니다. 트랜잭션 충돌 감지는 행 수준에서 수행됩니다. 즉, 두 개의 병렬 트랜잭션이 동일한 행을 업데이트할 때 충돌이 있는 것으로 간주됩니다. 이때의 접근 방식은 이전 글로벌 순서의 트랜잭션이 성공할 수 있고, 모든 노드가 트랜잭션을 제출하는 것입니다. 전역 순서의 후속 트랜잭션은 실패하고 롤백되며 각 노드는 트랜잭션을 삭제합니다. 이는 실제로 먼저 제출한 사람이 거래에서 승리하는 분산 규칙입니다. 제안: 노드 간 트랜잭션 충돌이 자주 발생하는 경우 이러한 트랜잭션을 동일한 노드에서 실행하는 것이 가장 좋습니다. 그러면 MGR의 충돌 감지로 인해 충돌이 발생하지 않고 로컬 트랜잭션 동시성 제어 및 조정 하에 모두 성공적으로 제출될 수 있습니다. 항상 롤백되었습니다.

적용되거나 외부화되는 트랜잭션의 경우 MGR을 사용하면 트랜잭션의 일관성과 유효성이 파괴되지 않는 한 반드시 원래 순서대로 실행될 필요는 없습니다. MGR의 기본 요구 사항은 최종 일관성입니다. 즉, 모든 트랜잭션이 완료되면 모든 노드의 데이터가 일관성을 갖습니다. 트래픽이 많을 경우 트랜잭션이 외부화되어 약간의 순서 불일치가 발생할 수 있습니다. 예를 들어, 다중 마스터 모드에서는 MGR 인증 스레드가 이 거래는 충돌이 발생하지 않습니다. 단일 마스터 모드에서는 충돌이 발생하지 않는 한 기본 노드에서 로컬 동시 트랜잭션의 제출 및 외부화 순서가 트랜잭션의 전역 트랜잭션 순서와 약간 일치하지 않을 수 있습니다. 보조 노드에는 쓰기 트랜잭션이 없으므로 트랜잭션 순서는 전역 트랜잭션 순서와 일치합니다.

다음 그림에서는 MGR의 그룹 복제 프로토콜을 설명합니다. 기존 마스터-슬레이브 복제(및 반동기 복제)와 몇 가지 차이점을 볼 수 있습니다. 단순화를 위해 식별 알고리즘 및 Paxos 관련 정보는 그림에서 생략되었습니다.

MGR은 단일 마스터 또는 다중 마스터 모드를 지원합니다.

시작 시 group_replication_single_primary_mode 옵션을 설정하여 사용할 모드를 결정합니다. 각 노드에서 이 값에 대한 설정 요구 사항은 일관됩니다. ON으로 설정되면 싱글 마스터 모드를 나타냅니다. OFF로 설정하면 멀티 마스터 모드를 나타냅니다.

실행 프로세스 중에는 group_replication_single_primary_mode 값을 온라인으로 수정할 수 없지만 MySQL 8.0.13부터는 두 개의 udfs group_replication_switch_to_single_primary_mode() 및 group_replication_switch_to_multi_primary_mode()를 호출하여 실행 모드를 온라인으로 수정할 수 있습니다. MySQL Shell Revise를 통해.

단일 마스터 모드에서는 하나의(기본) 노드만 데이터를 쓸 수 있고 다른(보조) 노드는 데이터를 읽을 수만 있습니다. 다중 마스터 모드에서는 모든 노드에서 동시에 데이터를 읽고 쓸 수 있습니다.

MGR은 단일 마스터 또는 다중 마스터 모드에 관계없이 최대 9개의 노드만 지원할 수 있습니다.

MGR은 노드 집합으로 구성되며 각 노드에는 UUID 형식으로 표현되는 고유한 이름이 있습니다. 노드는 동적으로 MGR에 가입하거나 탈퇴할 수 있습니다(또는 수동적으로 추방될 수 있습니다).

MGR의 그룹 멤버십 서비스는 각 활성 노드를 정의하는 정보를 유지하는 데 사용됩니다. 이 활성 노드 정보를 그룹 보기라고도 합니다. 각 노드에는 그룹에 대한 일관된 보기가 있으며, 이는 특정 순간에 그룹에 어떤 활성 구성원이 있는지 나타냅니다.

트랜잭션이 제출될 때 일관성을 유지하는 것 외에도 각 MGR 노드는 그룹 보기가 변경될 때 합의에 도달해야 합니다. 새 노드가 합류하거나 기존 노드가 떠나면 새로운 그룹 보기 변경이 트리거됩니다.

노드가 자발적으로 클러스터를 떠나면 클러스터의 자동 재구성이 트리거되고 나머지 노드는 새 그룹 보기에 동의합니다. 그러나 네트워크 이상 또는 다운타임으로 인해 노드가 실수로 클러스터를 떠난 경우 자동 재구성이 트리거될 수 없습니다. 이때 클러스터 결함 감지 메커니즘은 노드가 일정 기간 동안 떠난 후 이 상태를 인식하고 재구성 그룹을 발행합니다. 보기. 그룹 보기를 재구성하려면 대다수 구성원의 동의가 필요합니다. 합의에 도달하지 못하면 자동 재구성이 이루어질 수 없으며 수동 개입이 필요합니다. 합의를 형성할 수 없는 가능한 이유는 남은 노드 수가 요약 지점의 절반 이상에 도달하지 못하기 때문이며, 이는 다수를 형성할 수 없음을 의미합니다.

노드가 다운된 것으로 확인되기 전이나 실패한 노드를 제거하기 위해 그룹을 재구성하기 전에 노드가 잠시 오프라인 상태가 되도록 허용한 다음 클러스터에 다시 가입을 시도하십시오. 이 경우 노드는 이전 상태(트랜잭션 데이터)를 잃을 수 있으며, 이는 다른 노드가 충돌 전 메시지가 포함된 메시지를 보내면 데이터 불일치와 같은 문제로 이어질 수 있습니다.

이 문제를 해결하기 위해 MySQL 5.7.22부터 MGR은 동일한 주소와 포트를 가진 노드가 새로운 ID로 다시 클러스터에 조인하는지 확인하여 이전 ID가 여전히 존재하는지 확인합니다. 현재로서는 클러스터에서 이전 ID를 삭제할 수 있을 때까지 새 ID를 추가할 수 없습니다.

참고: group_replication_member_expel_timeout 옵션의 기능은 노드가 공식적으로 제거되기 전에 클러스터에 다시 가입을 시도할 수 있는 시간을 더 갖도록 대기 기간을 설정하는 것입니다. 즉, 의심되는 상태의 노드가 여전히 클러스터에 다시 가입을 시도할 수 있습니다. 시간 초과 전에 다시 활성 노드로 작동합니다. 노드가 group_replication_member_expel_timeout 임계값을 초과하여 클러스터에서 제거되거나, 노드가 STOP GROUP_REPLICATION을 실행하여 클러스터를 종료하거나, 노드 가동 중지 시간 등으로 인해 노드가 새 ID로 클러스터에 다시 참여해야 합니다.

MGR에는 자체 오류 감지 메커니즘이 있으며 특정 조건이 충족되면 해당 노드가 작동하지 않는 것으로 간주됩니다. 어떤 노드가 죽은 것으로 의심되는지에 대한 정보를 제공하는 분산형 오류 감지 서비스입니다.

노드가 침묵하면(다른 노드의 메시지에 적극적으로 메시지를 보내거나 응답하지 않음) 의심을 유발할 수 있습니다. 노드 A가 주어진 시간 내에 노드 B로부터 메시지를 수신하지 못하면 메시지 타임아웃이 발생하고 의심이 제기됩니다. 이후 클러스터 내 다른 구성원들이 해당 노드에 대한 의심이 확실하다고 동의(과반수 동의)하면 해당 노드는 실패한 것으로 판단된다.

네트워크 장애로 인해 한 노드가 다른 노드와 연결이 끊어지면 다른 노드에도 장애가 발생한 것으로 의심할 수 있습니다. 그러나 다수 결의안을 형성할 수 없기 때문에 이 의심은 현재로서는 유효하지 않습니다. 노드는 읽기-쓰기 트랜잭션을 수행할 수 없으며 기껏해야 읽기 전용 트랜잭션만 수행할 수 있습니다.

네트워크가 불안정하면 두 노드의 연결이 자주 끊어졌다가 다시 연결될 수 있습니다. 이론적으로는 모든 노드가 제거 대상으로 표시될 수 있으며 클러스터가 종료되고 다시 구축되어야 합니다. 이러한 상황을 방지하기 위해 MySQL 8.0.20부터 GCS는 제거 표시된 노드를 추적하고 의심스러운 노드가 여전히 대부분의 노드에 있는지 여부를 결정하여 클러스터에서 종료되지 않고 최소 하나의 노드를 유지합니다. 축출된 노드가 클러스터에서 공식적으로 제거되면 GCS는 나중에 다시 추가할 수 있도록 축출 표시된 레코드를 삭제합니다.

MGR은 분산형 Paxos 알고리즘을 기반으로 구현되므로 투표를 위해서는 다수의 노드가 살아남아야 합니다. 이는 전체 시스템 가용성에 영향을 주지 않고 허용할 수 있는 노드 오류 수를 결정합니다. 총 노드 수를 n개, 장애를 허용할 수 있는 노드 수를 f개라고 가정하면 이들의 관계는 n = 2*f 1입니다. 즉, 장애를 허용할 수 있는 노드 수는 전체 노드 수의 절반을 넘지 않아야 합니다.

다음 표는 서로 다른 노드 번호 간의 대응 관계를 보여줍니다.

개인 수준의 한계로 인해 열에 필연적으로 오류 및 누락이 있습니다. 명령과 항목을 직접 복사하지 마십시오. 문서에 있는 방법을 온라인 제작 환경에 직접 적용할 수 있습니다. 독자들은 이를 공식적으로 구현하기 전에 테스트 환경에서 완전히 이해하고 검증해야 프로덕션 환경에 피해가 발생하거나 손상되는 것을 방지할 수 있습니다.

GreatSQL을 즐겨보세요 :)