[MySQL] InnoDB Cluster 3부작 : 1. Group Replication (1) - 개념 이해하기

InnoDB Cluster 3부작
1. Group Replication (1) - 개념 이해하기
2. Group Replication (2) - 구성하기
3. MySQL InnoDB Cluster Metadata 생성 및 MySQL Router 구성하기

 

 

목차

---

1. 개요

 

그룹 기반 복제(Group-based replication)는 내결함성 시스템을 구현하는 데 사용될 수 있는 기술입니다.

복제 그룹은 여러개의 서버로 구성되며, 각 서버는 데이터의 전체 복사본만을 공유하는 Shared-Nothing 복제방식을 따릅니다.

각 서버는 메시지 전달을 통해 서로 통신하고, 서버의 통신 계층에서는 원자적 메시지 전달과 메시지 순서 전달과 같은 보장 기능을 통해 데이터를 동기화하고자 합니다.

 

이러한 강력한 개념은 보다 발전된 데이터베이스 복제 솔루션을 위한 것으로, 멀티-마스터(Multi-Master) 업데이트 에브리웨어(Update Everywhere) 복제 프로토콜을 구현할 수 있도록 합니다.

 

기본적으로 복제 그룹(replication group) 은 여러 개의 서버로 구성됩니다.

그룹 내 각 서버는 독립적으로 트랜잭션을 실행 할 수 있지만, 읽기+쓰기(RW) 트랜잭션 은 그룹 내에서 해당 작업이 조정(coordinated) 된 후에만 커밋됩니다.

 

MySQL Group Replication Protocol

 

트랜잭션이 커밋될 준비가 되면, 해당 서버는 쓰기 값(write values) 및 쓰기 집합(write set) 을 원자적 브로드캐스트로 수행합니다.

 

원자적 브로드캐스트 Atomic Broadcast

원자적 브로드 캐스트는 분산 시스템에서 메시지를 여러 노드에 전달할 때, 모든 노드가 동일한 순서로 메시지를 받도록 보장하는 합의 프로토콜입니다.
원자적 브로드캐스트는 아래 특성을 보장합니다.

  1. 원자성 (Atomicity) : 모든 노드가 같은 메시지를 받거나, 아무것도 받지 않음
  2. 순서 보장 (Total Order) : 모든 노드가 동일한 순서로 메시지를 수신
  3. 장애 허용 (Fault Tolerance) : 일부 노드에서 장애가 발생하더라도 동작 가능

 

이를 통해 글로벌 전체 순서(global total order) 가 보장됩니다.

궁극적으로, 이는 모든 서버가 동일한 트랜잭션 집합을 동일한 순서로 수신한다는 것 을 의미합니다.

따라서 모든 서버는 동일한 변경 사항을 동일한 순서로 적용 하게 되며, 그룹 내에서 일관성을 유지할 수 있습니다.

 

그러나 서로 다른 서버에서 동시에 실행된 트랜잭션 간에는 충돌(conflict) 이 발생할 수 있습니다.

충돌은 인증 과정에서 감지되는데, 인증 과정에서 두 개의 트랜잭션이 동시에 같은 행을 변경하는 경우 충돌로 간주합니다.

충돌 발생 시 먼저 시작된 트랜잭션이 커밋되고, 다른 트랜잭션은 중단됩니다. 즉 먼저 시작된 트랜잭션이 '이긴다'는 규칙(first commit wins)가 적용됩니다.

여기서 중단된 트랜잭션은 실행된 서버에서 롤백(rollback) 되고, 그룹 내 다른 서버에서는 폐기되어 적용되지 않습니다.

이를통해 MySQL의 그룹 복제는 Shared-Nothing 복제 방식을 구현합니다.

추가로, 충돌 가능성이 높은 트랜잭션은 동일한 서버에서 실행하는 것이 좋습니다. 동일한 서버에서 실행할 경우, 인증에서 충돌을 검사하여 트랜잭션이 중단되는 것이 아니라 로컬 락 매니저를 통해 트랜잭션이 수행되기 때문입니다.

 

 

그룹 복제를 구성할 경우, 여러 서버가 협력하여 하나의 그룹을 형성하기 때문에 네트워크 파티셔닝이나 스플릿 브레인과 같은 전형적인 분산 시스템 문제도 해결해야 합니다.

그룹복제의 궁극적인 목적은 데이터베이스 및 데이터 복제의 로직을 여러 서버가 일관되고 단순한 방식으로 협력할 수 있도록 조정하는 것입니다. 시스템이 변화할 때마다 모든 서버가 시스템 상태와 데이터를 동일하게 인식해야합니다.

이는 MySQL 그룹 복제가 분산 상태 머신(distributed state machine) 으로 운영되어야 함을 의미합니다.

 

분산 상태 머신(distributed state machine)이란 여러 개의 MySQL 인스턴스(또는 노드)가 협력하여 일관된 상태를 유지하는 시스템을 의미합니다.
주로 멀티 노드 환경에서 상태 전이(State Transition)를 동기화하고, 장애 발생 시 일관성을 유지하기 위해 사용됩니다.

분산 상태 머신은 특정한 데이터베이스(MySQL)에 한정된 개념이 아니라 컴퓨터 과학 전반에서 사용하는 분산 시스템 설계 방법론 중 하나입니다.

MySQL에서도 적용할 수 있지만, Kafka, Raft, Paxos, ZooKeeper 같은 분산 시스템에서 더 일반적으로 사용됩니다.

MySQL 그룹 복제는 강력한 서버 간 조정을 기반으로 하는 분산 상태 머신 복제(distributed state machine replication) 기능을 제공합니다. 이 기능은 동일한 그룹에 속한 서버들이 자동으로 서로 조정되도록 합니다.

 

 

그룹 복제는 단일-프라이머리(single-primary)모드와 멀티-프라이머리(multi-primary)모드 두가지로 분류됩니다.

• 단일-프라이머리(single-primary)
  프라이머리 서버가 하나만 존재.
  하나의 프라미어리 서버에서만 Write가 가능하고, 자동으로 프라이머리(primary) 서버가 선출된다.
  
  
• 멀티-프라이머리(multi-primary)
  그룹의 모든 서버를 프라이머리 서버로 간주한다.
  따라서 각 서버에서 Write를 수행하는 것이 가능하다.

MySQL 그룹 복제에는 내장된 그룹 멤버십 서비스(group membership service) 가 포함되어 있어 모든 서버가 현재 그룹의 상태를 일관되게 유지할 수 있도록 합니다.

각 DB서버(노드)는 그룹을 자유롭게 탈퇴하거나 합류할 수 있으며, 이에 따라 그룹의 상태가 자동으로 업데이트됩니다. 또한, 서버가 예기치 않게 그룹에서 이탈하는 경우, 내장된 장애 감지 메커니즘이 이를 감지하고 그룹에 변경 사항을 자동으로 알립니다.

 

트랜잭션이 커밋되려면, 그룹 내 과반수 이상의 서버가 전역 트랜잭션 순서에서 해당 트랜잭션의 순서에 동의해야 합니다.

트랜잭션을 커밋할지에 대한 여부는 각 서버가 개별적으로 결정하지만, 모든 서버는 동일한 결정을 내립니다.

만일 네트워크 파티셔닝이나 기타 장애로 인해 각 서버들이 합의할 수 없다면, 이 문제가 해결될 때까지 시스템은 진행되지 않습니다. 이러한 동작을 통해 스플릿 브레인을 방지합니다.

 

이 모든 기능은 그룹 통신 시스템(Group Communication System, GCS) 프로토콜 에 의해 제공됩니다.

GCS는 장애 감지 메커니즘, 그룹 멤버십 서비스, 그리고 안전하고 완전한 순서 보장 메시지 전달 기능을 제공합니다. 이를 통해 그룹 내 서버들의 데이터가 일관되게 복제될 수 있습니다.

이 기술의 핵심에는 Paxos 알고리즘이 존재합니다.

Paxos 알고리즘은 그룹 통신 엔진 역할을 하여, 그룹 내 서버들이 신뢰할 수 있는 방식으로 상태를 동기화하고 트랜잭션을 처리할 수 있도록 합니다.

 

 

 

 

---

2. 그룹 복제 아키텍처

MySQL Group Replication Architecture – Block Diagram

 

그룹 복제 아키텍처에는 기존 인프라의 많은 부분이 재사용되었습니다.

일부 코드는 상당한 리팩토링이나 모듈화가 이루어졌으며, 플러그인이 활용할 수 있는 인터페이스가 생성되었습니다.

그룹 복제 플러그인은 서버 및 기존 복제 계층과 밀접하게 통합되어 있습니다.

바이너리 로그 캐시, 슬레이브 적용기 인프라, 글로벌 트랜잭션 식별자, 릴레이 로그 인프라, 기존 복제 스레드 등을 활용합니다.

 

최상단에는 플러그인과 서버 간의 상호작용을 규정하는 일련의 API가 있습니다.

이러한 인터페이스는 서버에서 플러그인으로, 그리고 플러그인에서 서버로 정보를 전달하는 역할을 합니다. 

• 서버 -> 플러그인 방향
  서버가 시작되었거나, 복구 중이거나, 연결을 수락할 준비가 되었거나, 트랜잭션을 커밋하려 한다는 등의 알림을 제공
  
  
• 플러그인 -> 서버 방향
  플러그인이 진행 중인 트랜잭션을 커밋 또는 중단하도록 서버에 지시하거나 트랜잭션을 릴레이 로그에 큐잉하는 등의 역할을 수행
  

API 블록 아래에는 특정 알림이 전달되었을 때 반응하는 컴포넌트 집합이 존재합니다.

• 캡처(Capture) 컴포넌트
  현재 실행중인 트랜잭션과 관련된 컨텍스트를 추적
  
  
• 적용(Applier) 컴포넌트
  원격 트랜잭션을 데이터베이스에 적용
  
  
• 복구(Recovery) 컴포넌트
  분산 복구를 관리.
  서버를 최신 상태로 업데이트하거나 그룹 내 새로운 서버에 데이터를 적용

 

 

그 아래에는 복제 프로토콜(Replication Protocol) 모듈이 있습니다. 이 모듈은 복제 프로토콜의 특정 로직을 포함하고 있으며, 충돌 감지를 수행하고 트랜잭션을 그룹 내로 수신 및 전파하는 역할을 합니다.

 

마지막으로 가장 아래에는 그룹 통신 API(Group Communication API)가 있습니다.

이는 메시징 툴킷을 추상화하는 고수준 API로, 메시징 계층과 플러그인의 나머지 부분을 분리합니다.

이외에 보라색 박스로 표시된 부분은 플러그인 외부의 구성 요소로, 전체적인 이해를 돕기 위해 다이어그램에 포함되었습니다.

 

 

 

---

3. 사용 적합 사례

MySQL 그룹 복제는 고가용성, 높은 유연성, 그리고 안정적인 MySQL 서비스를 제공합니다.

다음은 그룹 복제를 도입하기에 적합한 사례입니다.

 

• 탄력적 복제 Elastic Replication
  클라우드 환경과 같이 서버 수가 동적으로 증가하거나 감소해야하며, 부작용을 최소화해야 하는 환경
  
  
• 고가용성 샤드 Highly Available Shards
  샤딩은 쓰기 확장석을 높이기 위한 일반적인 방법으로, MySQL 그룹 복제를 사용하여 고가용성 샤드 구현해야 하는 환경
  
  
• 비동기 소스-복제본 복제의 대안  Alternative to asynchronous Source-Replica replication
  단일 소스 서버를 사용하여 한 서버에 집중되는 부하를 나눌 필요가 있는 환경
  그룹 복제를 통해 전체 그룹에 쓰기를 수해앟는 방식이 특정 상황에서 대안이 될 수 있음
  
  
• 자율 시스템 Autonomic Systems
  내장된 자동화 기능을 활용하여 배포 가능
  

 

 

 

---

4. 멀티-프라이머리 모드 및 싱글-프라이머리 모드

 

MySQL Group Replication - Single-Primary mode vs Multi-Primary mode

 

MySQL 그룹 복제는 싱글 프라이머리 모드 또는 멀티 프라이머리 모드로 운영됩니다.

그룹의 모드는 group_replication_single_primary_mode 시스템 변수를 통해 설정하며, 그룹의 모든 멤버는 동일한 변수 값을 가져야 합니다. ON 값은 싱글 프라이머리 모드, OFF 값은 멀티 프라이머리 모드를 의미합니다.

동일한 그룹 내에서 일부는 멀티프라이머리 모드로, 일부는 싱글 프라이모드로 혼용하는 것은 불가능합니다.

 

그룹 복제가 실행 중일 때에는 group_replication_single_primary_mode 변수 값을 변경할 수 없습니다.

MySQL 8.0.13 부터는 group_replication_switch_to_single_primary_mode() 와group_replication_switch_to_multi_primary_mode() 함수를 이용하여 그룹 복제가 실행 중인 상태에서도 모드를 전환할 수 있습니다. 이러한 함수는 그룹 모드 변경 프로세스를 관리하며, 데이터의 안전성과 일관성을 보장합니다.

이전 버전에서 그룹 모드를 변경하려면 그룹 복제를 중지한 후 모든 멤버에서 group_replication_single_primary_mode 값을 변경해야 합니다. 그런 다음, 그룹을 완전히 재부팅(group_replication_bootstrap_group=ON으로 설정된 서버에서 부트스트랩)하여 새로운 운영 구성을 적용해야 합니다. 하지만 서버 자체를 다시 시작할 필요는 없습니다.

 

어떤 모드로 설정되었든, 그룹 복제는 클라이언트 측 장애 조치를 처리하지 않습니다. 클라이언트 장애 조치(client-side failover)는 MySQL Router 8.0, 프록시, 커넥터 또는 애플리케이션 자체와 같은 미들웨어 프레임워크를 통해 처리해야 합니다.

 

클라이언트 장애 조치 Client-Side Failover

클라이언트 장애 조치는 클라이언트가 접속 중인 데이터베이스가 장애로 사용할 수 없게 되었을 때, 자동으로 다른 정상적인 서버로 연결을 전환하는 과정을 의미합니다.
MySQL Group Replication 자체는 서버 간의 복제 및 데이터 동기화를 관리하지만, 클라이언트가 어느 서버에 연결해야 하는지는 직접 관리하지 않습니다. 따라서 클라이언트 측에서 적절한 장애 조치 메커니즘이 필요합니다.

MySQL Router, 애플리케이션 레벨의 장애 조치, 로드밸런서, 프록시 등을 클라이언트 장애 조치에 사용할 수 있습니다.

 

 

 

1) 싱글-프라이머리 모드

싱글 프라이머리 모드(group_replication_single_primary_mode=ON)에서는 그룹 내에서 하나의 서버만이 프라이머리 서버로, 읽기+쓰기가 가능합니다. 그룹 내 다른 모든 멤버는 읽기 전용 모드(super_read_only=ON)로 설정됩니다.

일반적으로 프라이머리 서버가 그룹 전체를 부트스트랩하고, 이후 그룹에 합류하는 모든 서버는 프라이머리 서버를 인식하고 읽기 전용 모드로 설정됩니다.

싱글 프라이머리 모드에서는 오직 하나의 프라이머리 서버에만 데이터를 기록할 수 있으므로, 멀티 프라이머리 모드와 비교했을 때 데이터 일관성 검사가 덜 엄격하게 이루어질 수 있습니다. 또한, DDL을 실행할 때 특별한 조치가 필요하지 않습니다. group_replication_enforce_update_everywhere_checks 옵션을 통해 그룹의 엄격한 일관성 검사를 활성화하거나 비활성화할 수 있으며, 싱글 프라이머리 모드로 배포하거나 전환할 때 이 시스템 변수는 반드시 OFF로 설정해야 합니다.

 

프라이머리 서버 지정 방식은 다음과 같습니다.

1. 기존 프라이머리 서버가 그룹을 떠날 경우(자발적이든 예상치 못한 장애로든) 새로운 프라이머리 서버가 자동으로 선출됩니다.
2. group_replication_set_as_primary() 함수를 사용하여 특정 멤버를 새로운 프라이머리 서버로 지정할 수 있습니다.
3. group_replication_switch_to_single_primary_mode() 함수를 사용하여 멀티 프라이머리 모드에서 싱글 프라이머리 모드로 전환하면, 새로운 프라이머리 서버가 자동으로 선출되거나, 함수를 통해 특정 서버를 프라이머리로 지정할 수 있습니다.

이러한 기능들은 MySQL 8.0.13 이상 버전에서만 사용할 수 있습니다.

새로운 프라이머리 서버가 선출되면(자동 또는 수동), 해당 서버는 자동으로 읽기+쓰기 모드로 전환되며, 나머지 그룹 멤버들은 계속 ReadOnly 모드로 유지됩니다.

이 과정은 아래 다이어그램과 같이 진행됩니다.

 

 

새로운 프라이머리 서버 선출과정

 

새로운 프라이머리 서버가 선출될 때, 기존 프라이머리 서버에서 적용된 변경 사항이 새로운 프라이머리에 적용되지 않은 백로그(backlog)가 존재할 수 있습니다. 이 경우, 새로운 프라이머리서버가 이전 프라이머리 서버와 동일한 데이터를 갖게 될 때까지 읽기+쓰기 트랜잭션은 충돌이 발생하여 롤백될 수 있으며, 읽기 전용 트랜잭션은 오래된 데이터를 반환할 가능성이 있습니다.

 

이러한 문제를 방지하기 위해 그룹 복제의 플로우 컨트롤(flow control) 매커니즘이 활성화되고 적절히 조정되면, 빠른 멤버와 느린 멤버 간의 차이를 최소화하여 발생 가능성을 줄일 수 있습니다.

 

또한, MySQL 8.0.14 이상 버전에서는 group_replication_consistency 시스템 변수를 사용하여 그룹의 트랜잭션 일관성 수준을 설정할 수 있습니다. 이 변수를 BEFORE_ON_PRIMARY_FAILOVER(기본값) 또는 그 이상의 일관성 수준으로 설정하면, 새로운 프라이머리 서버가 선출된 후 백로그가 적용될 때까지 새로운 트랜잭션이 보류되도록 설정할 수 있습니다.

만약 플로우 컨트롤과 트랜잭션 일관성 보장이 활성화되지 않은 그룹이라면, 새로운 프라이머리 서버가 릴레이 로그(relay log)를 적용할 시간을 충분히 가진 후에 클라이언트 애플리케이션을 해당 프라이머리로 재라우팅(re-routing)하는 것이 좋은 방법입니다.

 

 

1_ 프라이머리 서버 선출 알고리즘

프라이머리 서버 선출 과정에서는 각 멤버가 새로운 그룹 구성을 확인하고, 새로운 기본 멤버 후보들을 정렬한 후, 가장 적합한 멤버를 선택합니다. 각 멤버는 MySQL 서버 버전에 따른 기본 선출 알고리즘을 로컬에서 실행하여 독립적으로 결정을 내립니다. 그러나 모든 멤버가 동일한 결정을 내려야 하므로, 만약 그룹 내에 낮은 MySQL 버전을 실행하는 멤버가 있다면, 다른 멤버들도 낮은 버전에 맞춰 알고리즘을 조정하여 동일한 동작을 하도록 합니다.

 

프라이머리 서버를 선출할 때 고려되는 요소는 다음과 같습니다. (우선순위는 1>2>3 순 입니다)

1. 가장 낮은 버전의 MySQL 서버를 실행하는 멤버 선택
   그룹 내에서 가장 낮은 버전을 실행하는 멤버를 우선적으로 고려합니다.
   만일 모든 멤버가 MySQL8.0.17 이상을 실행중이라면, 마이너 버전을 기준으로 정렬됩니다.
   만일 그룹 내에서 MySQL5.7 혹은 MySQL8.0.16 이하의 멤버가 있다면, 메이저기준으로만 정렬하고 마이너 버전은 무시됩니다.
   
   
2. 멤버 가중치(group_replication_member_weight) 비교
   가장 낮은 MySQL 서버 버전을 실행하는 멤버가 여럿이거나, 모든 멤버의 버전이 똑같을 경우  group_replication_member_weight 시스템 변수를 비교하여 가중치가 높은 멤버를 우선적으로 선택합니다.
   만일 그룹내에 MySQL5.7을 실행하는 멤버가 여럿이라면 해당 버전에서는 멤버 가중치 변수를 지원하지 않으므로 이 기준은 무시됩니다.
   가중치는 0 ~ 100 사이의 값을 설정할 수 있으며, 기본값은 50입니다.
   50보다 낮은 값을 설정하면 우선순위가 낮아지고, 50보다 높은 값을 설정하면 우선순위가 높아집니다.
   이 기능을 활용해 더 좋은 하드웨어를 우선적으로 사용하거나 특정 멤버를 유지보수할 때 대체 멤버를 사전에 지정할 수 있습니다.
   
   
3. 서버 UUID 비교
   가장 낮은 MySQL 서버 버전을 실행하는 멤버가 여럿이고, 멤버 가중치가 모두 동일한 경우 server_uuid를 정렬하여 가장 작은 값을 가진 멤버를 프라이머리 서버로 선출합니다.

 

 

2_프라이머리 서버 확인

싱글 프라이머리 모드에서 아래 쿼리를 이용하면 현재 어떤 서버가 프라이머리인지 확인할 수 있습니다.

mysql> SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;

+-------------------------+-------------+
| MEMBER_HOST             | MEMBER_ROLE |
+-------------------------+-------------+
| remote1.example.com     | PRIMARY     |
| remote2.example.com     | SECONDARY   |
| remote3.example.com     | SECONDARY   |
+-------------------------+-------------+

mysql> SHOW STATUS LIKE 'group_replication_primary_member';

 

group_replication_primary_member 상태변수는 deprecated된 상태로, performance_schema.replication_group_members 테이블을 조회하는것을 권장합니다.

 

 

 

 

 

 

2) 멀티-프라이머리 모드

멀티 프라이머리 모드에서는 모든 멤버가 프라이머리 서버가 되어 읽기+쓰기 모드로 동작할 수 있습니다.

따라서 그룹에 새 멤버가 합류하면 기존멤버들과 호환되는 경우 자동으로 읽기+쓰기 모드로 설정되어 동시에 쓰기 트랜잭션을 처리할 수 있습니다.

 

어떤 멤버가 예기치 않게 서버를 종료하는 등의 이유로 쓰기 트랜잭션을 처리할 수 없는 경우, 해당 멤버에 연결된 클라이언트는 읽기+쓰기 모드에 있는 다른 멤버로 리디렉션되거나 장애 조치(failover)될 수 있습니다. 그룹 복제는 클라이언트 측 장애 조치를 자체적으로 처리하지 않으므로, 이를 위해 MySQL Router 8.0, 프록시, 커넥터 또는 애플리케이션 자체에서 이 작업을 수행해야 합니다. 아래 그림에서는 특정 멤버가 그룹을 떠날 경우 클라이언트가 대체 그룹 멤버로 다시 연결되는 방식을 보여줍니다

Client Failover

 

일부 멤버의 쓰기 처리량이 다른 멤버보다 낮은 경우 트랜잭션 처리 속도가 뒤쳐져 오래된 데이터를 읽을 가능성이 생깁니다.

멀티 프라이머리 모드에서는 속도가 느린 멤버들이 인증이나 적용해야 할 트랜잭션을 과도하게 누적할 수도 있는데, 이는 충돌 및 인증 실패의 위험을 증가시킵니다.

이러한 문제를 완화하기 위해 싱글 프라이머리 모드와 마찬가지로 멀티 프라이머리 모드에서도 Group Replication의 플로우 컨트롤(flow control) 메커니즘과 트랜잭션 일관성 보장을 위한 group_replication_consistency 시스템 변수를 지원합니다.

 

 

1_ 트랜잭션 검사

그룹이 멀티 프라이머리 모드로 설정되면, 트랜잭션이 해당 모드와 호환되는지 확인하는 검사가 수행됩니다.

그룹복제가 멀티 프라이머리 모드로 실행될 경우 아래와 엄격한 일관성 검사(strict consistency checks)가 이루어집니다.

• 트랜잭션이 SERIALIZABLE 격리 수준에서 실행된 경우, 그룹과 동기화하는 동안에는 커밋이 실패됩니다.
• 트랜잭션이 CASCADE 제약 조건을 가진 외래 키(foreign key)가 있는 테이블을 대상으로 실행된 경우, 그룹과 동기화하는 동안에는 커밋이 실패됩니다.

이러한 검사는 group_replication_enforce_update_everywhere_checks 시스템 변수에 의해 제어됩니다.

 

멀티 프라이머리 모드에서는 일반적으로 이 시스템 변수를 ON으로 설정해야 하지만, 필요에 따라 OFF로 비활성화할 수도 있습니다. 싱글 프라이머리 모드에서는 이 시스템 변수를 반드시 OFF로 설정해야 합니다.

 

 

 

2_ DDL

멀티 프라이머리 모드의 그룹 복제 토폴로지에서 데이터 정의 언어(DDL) 실행 시 주의를 요구합니다.

MySQL 8.0에서는 원자적 데이터 정의 언어(Atomic Data Definition Language, DDL) 문을 지원하며, 이를 통해 전체 DDL 문이 하나의 원자적 트랜잭션으로 커밋되거나 롤백됩니다.
즉, DDL 문은 다른 트랜잭션 내에서 실행할 수 없으며, START TRANSACTION ... COMMIT과 같은 트랜잭션 제어문 내에서 실행되거나 다른 쿼리와 동일한 트랜잭션에서 실행될 수 없습니다.

 

그룹 복제는 낙관적 복제(Optimistic Replication)를 기반으로 합니다. 즉, 명령문을 먼저 실행한 후 필요에 따라 롤백하는 방식입니다. 각 서버는 그룹의 동의를 먼저 확보하지 않고 실행을 수행합니다.
따라서 멀티 프라이머리 모드에서 DDL을 수행할 때는 더욱 주의해야 합니다.

만약 동일한 개체를 대상으로한 DDL과 DML을 동시에 수행할 경우, DDL이 그룹 내 모든서버에서 완료되지 않은 경우 작업이 중단되거나 부분적으로만 완료되는 경우 데이터 불일치(Data Inconsistency)가 발생할 수 있습니다.

 

반면, 싱글 프라이머리 모드에서는 모든 변경 사항이 하나의 프라이머리 서버에서만 발생하기에 이러한 이슈가 발생하지 않습니다.

 

 

 

3_ 버전 호환성

최적의 호환성과 성능을 위해 그룹 내 모든 멤버는 동일한 MySQL Server 버전을 권장합니다.

멀티-프라이머리 모드에서는 모든 멤버가 읽기+쓰기 모드이므로, 이것이 더욱 중요합니다.

 

만일 그룹에 다양한 MySQL Server 버전이 존재할 경우 일부 멤버는 다른 멤버가 지원하지 않는 기능을 사용하거나, 반대로 기능이 부족하여 데이터 불일치가 발생할 수 있습니다.

때문에 그룹 복제에서는 이를 방지하기 위해 새로운 멤버가 합류할 때 기존 멤버와의 호환성 검사를 수행합니다.

여기서 기준은 버전이 가장 낮은 MySQL Server가 됩니다.

 

 

 

 

 

---

:: 참고문헌

MySQL :: MySQL Group Replication : Hello World!

MySQL :: MySQL Group Replication : Hello World!

Replicating data between two MySQL Group Replication sets using “regular” asynchronous replication with Global Transaction Identifiers (GTID’s) | Scripting MySQL

Replicating data between two MySQL Group Replication sets using “regular” asynchronous replication with Global Transaction I

MySQL :: MySQL 8.0 Reference Manual :: 20 Group Replication

MySQL :: MySQL 8.0 Reference Manual :: 20 Group Replication