20.1 Group Replication Background

20.1 Group Replication Background

20.1.1 Replication Technologies 20.1.2 Group Replication Use Cases 20.1.3 Multi-Primary and Single-Primary Modes 20.1.4 Group Replication Services 20.1.5 Group Replication Plugin Architecture

이 섹션은 MySQL Group Replication에 대한 배경 정보를 제공합니다.

장애 허용 시스템을 만드는 가장 일반적인 방법은 구성 요소들을 중복(redundant)으로 만드는 것입니다. 다시 말해, 구성 요소를 제거하더라도 시스템이 예상대로 계속 동작해야 합니다. 이는 이러한 시스템의 복잡성을 전혀 다른 수준으로 끌어올리는 일련의 과제를 만들어 냅니다.

특히, 복제된 데이터베이스는 단일 서버 하나만이 아니라 여러 서버에 대한 유지 관리와 관리를 처리해야 합니다. 더욱이, 서버들이 그룹을 형성하기 위해 함께 협력함에 따라, 네트워크 파티셔닝이나 스플릿 브레인 시나리오와 같은 다른 고전적인 분산 시스템 문제들도 처리해야 합니다.

따라서 궁극적인 과제는 데이터베이스와 데이터 복제의 로직을, 여러 서버를 일관되고 단순한 방식으로 조정하는 로직과 융합하는 것입니다. 다시 말해, 시스템이 겪는 각 변경마다 여러 서버가 시스템 상태와 데이터에 대해 동의하도록 하는 것입니다. 이는 서버들이 각 데이터베이스 상태 전이에 대해 합의에 도달하여, 모두가 하나의 단일 데이터베이스처럼 함께 진행하거나, 아니면 결국 동일한 상태로 수렴하도록 하는 것으로 요약할 수 있습니다.

즉, (분산된) 상태 기계로 동작해야 한다는 뜻입니다.

MySQL Group Replication은 서버 간 강한 조정을 갖춘 분산 상태 기계 복제를 제공합니다. 동일한 그룹의 일부가 되면 서버들은 자동으로 서로를 조정합니다.

그룹은 자동 프라이머리 선출이 있는 싱글 프라이머리 모드에서 동작할 수 있으며, 이 경우 한 번에 하나의 서버만 업데이트를 허용합니다. 또는 더 고급 사용자를 위해, 그룹을 멀티 프라이머리 모드로 배포할 수도 있으며, 이 경우 모든 서버가 업데이트를 허용하고, 심지어 동시에 발생하는 업데이트도 허용합니다.

이러한 강력한 기능은, 이러한 배포 방식이 부과하는 제약을 애플리케이션이 우회해서 처리해야 한다는 대가를 수반합니다.

내장된 그룹 멤버십 서비스가 있어, 어느 시점에서나 그룹의 뷰를 모든 서버에 대해 일관되고 사용 가능하게 유지합니다. 서버는 그룹을 떠나거나 그룹에 조인할 수 있고, 그에 따라 뷰가 갱신됩니다.

때때로 서버가 예상치 못하게 그룹을 떠날 수 있는데, 이 경우 장애 감지 메커니즘이 이를 감지하고 뷰가 변경되었음을 그룹에 알립니다. 이 모든 것은 자동으로 이루어집니다.

트랜잭션이 커밋되려면, 그룹의 과반수가 전역 트랜잭션 시퀀스 내에서 특정 트랜잭션의 순서에 동의해야 합니다. 트랜잭션을 커밋할지 중단(abort)할지에 대한 결정은 각 서버가 개별적으로 수행하지만, 모든 서버가 동일한 결정을 내립니다.

네트워크 파티션이 발생하여, 멤버들이 합의에 도달할 수 없는 분할이 생기면, 이 문제가 해결될 때까지 시스템은 진행되지 않습니다. 따라서 내장된 자동 스플릿 브레인 보호 메커니즘도 존재합니다.

이 모든 것은 제공되는 Group Communication System(GCS) 프로토콜에 의해 구동됩니다. 이는 장애 감지 메커니즘, 그룹 멤버십 서비스, 그리고 안전하고 완전히 순서화된 메시지 전달을 제공합니다. 이러한 모든 속성은 서버 그룹 전체에 걸쳐 데이터가 일관되게 복제되도록 하는 시스템을 만드는 데 핵심적입니다.

이 기술의 가장 핵심에는 Paxos 알고리즘의 구현이 있으며, 이는 그룹 커뮤니케이션 엔진 역할을 합니다.