18.6.3 MySQL Cluster Replication의 알려진 문제

이 섹션에서는 MySQL Cluster NDB 7.3에서 복제를 사용하는 경우의 문제점과 과제에 대해 설명합니다.

마스터 슬레이브 연결 상실 연결의 손실은 복제 마스터의 SQL 노드와 복제 슬레이브 SQL 노드 사이 또는 복제 마스터의 SQL 노드와 마스터 클러스터의 데이터 노드 사이 중 하나에서 발생할 수 있습니다. 후자의 경우이 사건은 물리적 연결이 손실 된 결과 (예를 들어, 네트워크 케이블의 손상 등)뿐만 아니라 데이터 노드 이벤트 버퍼 오버플로 가능성도 있습니다. SQL 노드는 응답이 너무 느리고 클러스터에서 드롭 될 가능성이 있습니다 (이것은 MaxBufferedEpochs 및 TimeBetweenEpochs 구성 매개 변수를 조정하여 어느 정도까지 제어가 가능합니다). 문제가 발생하면 새 데이터를 복제 마스터의 바이너리 로그에 기록하지 않고 마스터 클러스터에 삽입 할 수 있습니다. 따라서 고 가용성을 보장하려면 슬레이브 클러스터와 마스터 간의 동기화 유지에 필요한 경우 보조 복제 채널로 페일 오버 백업 복제 채널의 유지, 주 채널의 모니터가 매우 중요합니다. MySQL Cluster는 스스로 이러한 모니터링을 실행하도록 설계되어 있지 않기 때문에, 외부의 응용 프로그램이 필요합니다.

복제 마스터는 마스터 클러스터에 연결하거나 다시 연결을 할 때 "간격"이벤트를 발행합니다. (갭 이벤트는 일종의 '사건 이벤트 "이며, 데이터베이스의 내용에 영향을 미치는 일련의 변화로 쉽게 표현할 수없는 사건이 발생한 것을 나타냅니다. 사고의 예는 서버 충돌 데이터베이스 재 동기화 (여러) 소프트웨어 업데이트 (여러) 하드웨어 업데이트 등입니다.) 슬레이브는 복제 로그의 격차를 감지하면 오류 메시지를 내고 중지합니다. 이 메시지는 SHOW SLAVE STATUS 의 출력에 표시되고 SQL 쓰레드가 복제 스트림에 등록 된 사고에 의해 중지하고 수동 개입이 필요한 것을 나타냅니다. 이런 상황에서의 대처에 대한 자세한 내용은 섹션 18.6.8 "MySQL Cluster 복제를 사용한 장애 조치 구현" 을 참조하십시오.

순환 복제 MySQL Cluster 복제는 다음 예제와 같이 순환 복제를 지원합니다. 복제 설정은 번호가 1,2,3의 3 개의 MySQL Cluster로 구성된 클러스터 1은 클러스터 2의 복제 마스터로 동작하고 클러스터 2 클러스터 3의 마스터로 작동 클러스터 3 클러스터 1 마스터로 동작하고 순환을 완성합니다. 각 MySQL Cluster는 2 개의 SQL 노드를 가지고 SQL 노드 A와 B는 클러스터 1에 속하고, SQL 노드 C와 D는 클러스터 2에 속하는 SQL 노드 E와 F는 클러스터 3에 속해 있습니다.

이러한 클러스터를 사용하는 순환 복제는 다음 조건을 충족 한 지원됩니다.

이 유형의 순환 복제 설정은 다음 그림과 같습니다.

이 시나리오에서는 클러스터 1의 SQL 노드 A는 클러스터 2의 SQL 노드 C에 복제, SQL 노드 C는 클러스터 3의 SQL 노드 E에 복사, SQL 노드 E는 SQL 노드 A에 복제합니다. 즉, 복제 라인 (그림의 빨간색 화살표)은 복제 마스터 및 슬레이브로 사용되는 모든 SQL 노드를 직접 연결합니다.

여기에서 같이 모든 마스터 SQL 노드가 반드시 슬레이브가 아닌 순환 복제를 설정할 수 있습니다.

이 경우 각 클러스터의 다른 SQL 노드는 복제 마스터 및 슬레이브로 사용됩니다. 그러나 SQL 노드를 --log-slave-updates 를 사용하여 시작할 필요가 없습니다. 복제 라인 (이것도 그림의 빨간색 화살표)가 연속하지 않은 MySQL Cluster의이 유형의 순환 복제 방식은 가능성은 있지만 아직 완전히 테스트되지 않기 때문에 실험적인 것이라고 생각하게합니다.

MySQL Cluster 복제 및 기본 키 노드에 장애가 발생하면 중복 행이 삽입 될 수 있기 때문에 기본 키가없는 NDB 테이블의 복제 오류가 발생할 수 있습니다. 따라서 복제되는 모든 NDB 테이블에 기본 키를 가지는 것을 권장합니다.

MySQL Cluster 복제 및 고유 키 이전 버전의 MySQL Cluster는 NDB 테이블의 고유 키의 컬럼 값을 업데이트하는 작업이 수행되면 복제시 중복 키 오류가 될 수있었습니다. NDB 테이블 사이의 복제에 관한 문제는 모든 테이블 행의 업데이트가 실행될 때까지 고유 키의 체크를 보류하는 것으로 해결됩니다.

이 방법으로 제약을 보류하는 것은 현재 NDB 에서만 지원됩니다. 따라서 NDB 에서 다른 스토리지 엔진 ( MyISAM 이나 InnoDB 등)에 복제하는 경우 고유 키의 업데이트는 아직 지원되지 않습니다.

고유 키 업데이트 확인을 보류하지 않는 복제가 NDB 테이블 ( t )를 사용하여 설명 할 수있는 경우에 발생하는 문제는 여기서 같이 마스터에서 발생하고 채워집니다 (및 고유 키 업데이트 보류를 지원하지 않는 슬레이브에 복제됩니다).

CREATE TABLE t (
    p INT PRIMARY KEY, 
    c INT, 
    UNIQUE KEY u (c)
)   ENGINE NDB;

INSERT INTO t 
    VALUES (1,1), (2,2), (3,3), (4,4), (5,5);

t 에서 다음 UPDATE 문은 마스터에서 성공합니다. 이것은 영향을받는 행이 ORDER BY 옵션에 지정된 순서대로 처리되고 전체 테이블에 실행되기 때문입니다.

UPDATE t SET c = c - 1 ORDER BY p;

그러나 슬레이브는 같은 문이 중복 키 에러 등의 제약 조건 위반에 실패했습니다. 이것은 행의 업데이트 순서 지정이 전체 테이블에 대해 수행 된 것이 아니라 한 번에 하나의 파티션에 대해 수행 된 것입니다.

GTID는 지원되지 않는 글로벌 트랜잭션 ID를 사용하는 복제는 NDB 스토리지 엔진과 호환되지 않으며, 지원되지 않습니다. GTID을 사용하면 MySQL Cluster 복제가 실패 할 수 있습니다.

--initial에서 다시 시작 --initial 옵션을 사용하여 클러스터를 다시 시작하면 GCI와 신기원 번호의 순서가 0 부터 다시 시작됩니다. (이것은 일반적으로 MySQL Cluster에 적용, MySQL Cluster를 포함하는 복제 시나리오에 한정되는 것은 아닙니다.)이 경우 복제에 참여하는 MySQL 서버가 다시 시작됩니다. 이 후, RESET MASTER 및 RESET SLAVE 문을 사용하여 잘못된 ndb_binlog_index 및 ndb_apply_status 테이블을 각각 삭제합니다.

NDB에서 다른 스토리지 엔진에 복제 마스터 NDB 테이블을 다른 스토리지 엔진을 사용하는 슬레이브의 테이블에 복제 할 수 있습니다 만, 다음에 기재 한 제한 사항을 고려하십시오.

다음 몇 단락에서는 여기에 설명 된 문제들에 대한 추가 정보를 제공합니다.

NDB를 다른 스토리지 엔진에 복제 할 때 지원되지 않는 다중 마스터 NDB 에서 다른 스토리지 엔진에 대한 복제의 경우 두 데이터베이스의 관계는 단순한 주종 관계 일 필요가 있습니다. 즉, 순환 복제 또는 마스터 마스터 복제는 MySQL Cluster와 다른 스토리지 엔진 사이에서 지원되지 않습니다.

또한 NDB 및 다른 스토리지 엔진간에 복제하는 경우 여러 복제 채널을 구성 할 수 없습니다. (단, MySQL Cluster 데이터베이스는 여러 슬레이브 MySQL Cluster 데이터베이스에 동시에 복제 할 수 있습니다.) 마스터가 NDB 테이블을 사용하는 경우 여러 MySQL Server가 모든 변경 바이너리 로그를 유지하는 것은 여전히 가능 입니다. 그러나 노예가 주인을 바꾼 경우 (장애 조치) 새 마스터 슬레이브 관계는 슬레이브에서 명시 적으로 정의 될 필요가 있습니다.

바이너리 로깅을 수행하지 않은 슬레이브 스토리지 엔진에 NDB 복제 자신의 바이너리 로깅을 처리하지 않는 스토리지 엔진을 사용하는 슬레이브에 MySQL Cluster에서 복제하려고하면 복제 프로세스는 다음 오류로 인해 중지합니다 : Binary logging not possible ... Statement can not be written atomically since more than one engine involved and at least one engine is self-logging (오류 1595). 다음 방법 중 하나로이 문제를 해결할 수 있습니다.

NDB에서 비 트랜잭션 스토리지 엔진에 복제 MyISAM 과 같은 비 트랜잭션 스토리지 엔진에 NDB 에서 복제하는 경우 INSERT ... ON DUPLICATE KEY UPDATE 문을 복제 할 때 불필요한 중복 키 오류가 발생할 수 있습니다. 이들을 제어하기 위해 강제로 업데이트를 (업데이트가 아니라) 쓰기로 로그를 취하도록한다 --ndb-log-update-as-write=0 을 사용합니다.

MySQL Cluster 간 복제에 사용하는 복제 및 바이너리 로깅 필터링 규칙 --replicate-do-* , --replicate-ignore-* , --binlog-do-db 또는 --binlog-ignore-db 중 지의 옵션을 사용하여 복제 된 데이터베이스 또는 테이블을 제외하면 mysql.ndb_apply_status 복제 또는 바이너리 로깅을 차단하지 않도록주의해야합니다. 이것은 MySQL Cluster 간의 복제가 제대로 작동하기 위해 필요합니다. 특히 다음 사항에 유의해야합니다.

각 복제 규칙에는 다음 사항이 필요합니다.

NDB 이외의 스토리지 엔진을 사용하는 슬레이브에 MySQL Cluster를 복제하는 경우이 절의 다른 곳에서 설명하도록 이전에 설명 된 고려 사항은 적용되지 않습니다.

MySQL Cluster 복제 및 IPv6 현재 NDB API와 MGM API는 IPv6를 지원하지 않습니다. 그러나 MySQL Server (MySQL Cluster에서 SQL 노드로 동작하는 MySQL Server 포함)는 IPv6를 사용하여 다른 MySQL Server에 연결할 수 있습니다. 즉, 아래 그림의 점선과 같이 마스터와 슬레이브의 SQL 노드를 연결하기 위해 IPv6를 사용하여 MySQL Cluster 사이를 복제 할 수 있습니다.

그러나 MySQL Cluster 내에서 발생하는 모든 연결 (위 그림에서 실선의 화살표로 나타낸 연결)는 IPv4를 사용해야합니다. 즉, 모든 MySQL Cluster의 데이터 노드 관리 서버 및 관리 클라이언트는 IPv4를 사용하여 서로 액세스 할 수 있어야합니다. 또한 SQL 노드는 IPv4를 사용하여 클러스터와 통신해야합니다.

현재 NDB와 MGM의 API에서는 IPv6를 지원하지 않기 때문에 이러한 API를 사용하여 작성된 응용 프로그램은 IPv4를 사용하여 모든 연결을 만드는 것도 필요합니다.

속성 승격과 강등 MySQL Cluster 복제는 속성 승격과 강등을 지원하고 있습니다. 후자의 구현은 돌이킬 수없는 형과 무손실 형식 변환은 구분 슬레이브에서 이러한 변환의 사용은 slave_type_conversions 글로벌 시스템 변수를 설정하여 제어 할 수 있습니다.

MySQL Cluster의 속성 승격과 강등에 대한 자세한 내용은 열 기반 리플리케이션 : 속성 승격과 강등 을 참조하십시오.