25.7.8 Implementing Failover with NDB Cluster Replication

25.7.8 Implementing Failover with NDB Cluster Replication

primary Cluster 복제 프로세스에 장애가 발생한 경우, secondary 복제 채널로 전환하는 것이 가능합니다. 아래 절차는 이를 수행하는 데 필요한 단계들을 설명합니다.

1. 가장 최근 global checkpoint(GCP)의 시간을 구합니다. 즉, replica 클러스터의 ndb_apply_status 테이블에서 다음 쿼리를 사용하여 가장 최근 epoch를 확인해야 합니다:

1mysqlR'> SELECT @latest:=MAX(epoch)
2         ->        FROM mysql.ndb_apply_status;

순환 복제 토폴로지에서, 각 호스트에서 source와
replica가 실행되고 있고
`ndb_log_apply_status=1`을 사용하는 경우,
NDB Cluster epoch는 replica의 바이너리 로그에 기록됩니다.
이는 `ndb_apply_status` 테이블이 이 호스트의 replica뿐만 아니라,
이 호스트에서 실행 중인 복제 source 서버의
replica 역할을 하는 다른 호스트에 대한 정보도 포함하고 있음을
의미합니다.

이 경우, 이 replica의 바이너리 로그에서 다른 replica들로부터 온,
그리고 이 replica를 설정할 때 사용한
[`CHANGE REPLICATION SOURCE TO`](https://dev.mysql.com/doc/refman/9.5/en/change-replication-source-to.html "15.4.2.2 CHANGE REPLICATION SOURCE TO Statement")
구문의 `IGNORE_SERVER_IDS` 옵션에 나열되지 않은
어떤 다른 replica로부터의 epoch는 제외하고,
이 replica에서의 최신 epoch를 결정해야 합니다.
이러한 epoch를 제외하는 이유는,
이 replica 자신의 서버 ID를 가진 행들뿐만 아니라,
이 replica의 source를 준비할 때 사용한
[`CHANGE REPLICATION SOURCE TO`](https://dev.mysql.com/doc/refman/9.5/en/change-replication-source-to.html "15.4.2.2 CHANGE REPLICATION SOURCE TO Statement")
구문의 `IGNORE_SERVER_IDS` 목록에 일치하는
서버 ID를 가진 `mysql.ndb_apply_status`
테이블의 행들도 로컬 서버로부터 온 것으로 간주되기 때문입니다.
이 목록은 [`SHOW REPLICA STATUS`](https://dev.mysql.com/doc/refman/9.5/en/show-replica-status.html "15.7.7.36 SHOW REPLICA STATUS Statement")의
출력에서 `Replicate_Ignore_Server_Ids`로
조회할 수 있습니다. 이 목록을 이미 얻었고,
아래 쿼리에서 _`ignore_server_ids`_ 자리에
대체해 사용한다고 가정합니다. 이 쿼리는 이전 쿼리와 마찬가지로
가장 큰 epoch를 `@latest`라는 변수에
선택합니다:

1mysqlR'> SELECT @latest:=MAX(epoch)
2         ->        FROM mysql.ndb_apply_status
3         ->        WHERE server_id NOT IN (ignore_server_ids);

어떤 경우에는 포함할 서버 ID 목록을 사용하고,
`WHERE` 절에서
`server_id IN
         server_id_list`를 사용하는 것이
더 단순하거나 더 효율적(혹은 둘 다)일 수 있습니다.

2. Step 1의 쿼리에서 얻은 정보를 사용하여, source 클러스터의 ndb_binlog_index 테이블에서 해당하는 레코드들을 가져옵니다.

다음 쿼리를 사용하여 source의
`ndb_binlog_index` 테이블에서 필요한
레코드들을 얻을 수 있습니다:

1mysqlS'> SELECT
2       ->     @file:=SUBSTRING_INDEX(next_file, '/', -1),
3       ->     @pos:=next_position
4       -> FROM mysql.ndb_binlog_index
5       -> WHERE epoch = @latest;

이는 primary 복제 채널이 장애를 일으킨 이후
source에 저장된 레코드들입니다. 여기서 사용자 변수
`@latest`는 Step 1에서 얻은 값을 나타내는 데
사용되었습니다. 물론 하나의
[**mysqld**](https://dev.mysql.com/doc/refman/9.5/en/mysqld.html "6.3.1 mysqld — The MySQL Server") 인스턴스가 다른 서버 인스턴스에서
설정한 사용자 변수에 직접 접근하는 것은 불가능합니다.
이러한 값들은 수동으로 또는 애플리케이션을 통해
두 번째 쿼리에 “삽입”해야 합니다.

주의

replica mysqld는 START REPLICA를 실행하기 전에 반드시 --replica-skip-errors=ddl_exist_errors 옵션을 사용하여 시작해야 합니다. 그렇지 않으면, 중복 DDL 오류로 인해 복제가 중지될 수 있습니다.

3. 이제 secondary replica 서버에서 다음 쿼리를 실행하여 secondary 채널을 동기화할 수 있습니다:

1mysqlR'> CHANGE REPLICATION SOURCE TO
2         ->     SOURCE_LOG_FILE='@file',
3         ->     SOURCE_LOG_POS=@pos;

여기서도 사용자 변수(이 경우 `@file`과
`@pos`)를 사용하여 Step 2에서 얻고
Step 3에서 적용한 값을 나타냈습니다. 실제로는 이러한 값은
수동으로 삽입하거나, 두 서버 모두에 접근할 수 있는
애플리케이션을 사용하여 삽입해야 합니다.

참고

@file은 '/var/log/mysql/replication-source-bin.00001'와 같은 문자열 값이므로, SQL이나 애플리케이션 코드에서 사용할 때는 반드시 따옴표로 감싸야 합니다. 그러나 @pos가 나타내는 값은 따옴표로 감싸서는 안 됩니다. MySQL은 일반적으로 문자열을 숫자로 변환하려고 시도하지만, 이 경우는 예외입니다.

4. 이제 secondary replica mysqld에서 적절한 명령을 실행하여 secondary 채널에서 복제를 시작할 수 있습니다:

1mysqlR'> START REPLICA;

secondary 복제 채널이 활성화되면, primary의 장애를 조사하고 복구 작업을 수행할 수 있습니다. 이를 위해 필요한 구체적인 작업은 primary 채널이 실패한 이유에 따라 달라집니다.

주의

secondary 복제 채널은 primary 복제 채널에 장애가 발생했을 때, 그리고 그 때에만 시작해야 합니다. 여러 복제 채널을 동시에 실행하면 replica에 원치 않는 중복 레코드가 생성될 수 있습니다.

장애가 단일 서버로 국한되는 경우, 이론적으로는 _S_에서 _R'_으로 또는 _S'_에서 _R_으로 복제하는 것이 가능해야 합니다.