2.10. MySQL 클러스터 리플리케이션

2.10.1. 약어 및 심볼

2.10.2. 전제 사항 및 일반 필요 항목

2.10.3. MySQL 클러스터 리플리케이션에서 알려져 있는 이슈 사항

2.10.4. 클러스터 리플리케이션 스키마와 테이블

2.10.5. 리플리케이션용으로 클러스터 준비하기

2.10.6. 리플리케이션 시작하기 (싱글 리플리케이션 채널)

2.10.7. 두 개의 리플리케이션 채널 사용하기

2.10.8. MySQL 클러스터를 사용해서 장애 복구 (Failover) 구현하기

2.10.9. 리플리케이션을 사용해서 MySQL 클러스터 백업하기

MySQL 5.1.6 이전 버전에서는 비동기식 리플리케이션 (간단하게 리플리케이션이라고 함)을 MySQL 클러스터에서 사용할 수 없었다. 하지만, MySQL 5.1.6 버전에서는 MySQL 클러스터 데이터베이스에 대해서 이러한 형태의 마스터-슬레이브 리플리케이션이 도입되었다. 이 섹션에서는 마스터-슬레이브 리플리케이션을 클러스터에서 구성하는 방법과 관리하는 방법에 대해서 설명하기로 한다.

일반적인 (비-클러스터) 리플리케이션에는 하나의 “마스터” 서버와 하나의 “슬레이브” 서버가 있고, 마스터 서버는 복제되는 연산 및 데이터에 대한 소스를 가지고 있으며, 슬레이브는 이러한 것들의 복제본을 가지게 된다. MySQL 클러스터 리플리케이션의 개념은 이와 유사하지만 실제 구현 방식은 보다 복잡하다. 비록 MySQL 클러스터 자체는 클러스터 기능을 구현하기 위해 NDB Cluster 스토리지 엔진을 사용하지만, 슬레이브에서도 반드시 이 엔진을 사용해야 하는 것은 아니다. 지금부터 설명하는 MySQL 클러스터 리플리케이션의 기본 구성은 다음과 같다:

이 시나리오에서 보면, 리플리케이션 프로세스는 마스터 클러스터의 상태를 연속적으로 슬레이브 클러스터에 기록한다. 이 프로세스를 구현하는 것은 NDB binlog 인젝터 쓰레드 (injector thread)라고 불리는 특수 쓰레드인데, 이것은 각각의 MySQL 서버에서 구동해서 바이너리 로그 (binlog)를 생성한다. 이 쓰레드는 바이너리 로그를 생성하는 클러스터에서 변경된 내용들이 올바른 시리얼 번호를 사용해서 바이너리 로그에 삽입되는지를 확인한다. 이 섹션에서는 MySQL 리플리케이션 마스터와 리플리케이션 슬레이브 서버를 각각 리플리케이션 서버 또는 리플리케이션 노드라고 하고, 이들 간의 통신 라인 또는 데이터 플로우를 리플리케이션 채널이라고 하겠다.