25.7.9 NDB Cluster Backups With NDB Cluster Replication

25.7.9 NDB Cluster Replication과 함께 사용하는 NDB Cluster 백업

25.7.9.1 NDB Cluster Replication: Automating Synchronization of the Replica to the Source Binary Log
25.7.9.2 Point-In-Time Recovery Using NDB Cluster Replication

이 섹션에서는 NDB Cluster replication을 사용하여 백업을 생성하고 해당 백업으로부터 복구하는 방법을 다룹니다. replication 서버들은 이미 앞에서 다룬 내용에 따라 구성되어 있다고 가정합니다(참조: Section 25.7.5, “Preparing the NDB Cluster for Replication” 및 바로 이어지는 섹션들). 이 작업이 완료되었다면, 백업을 생성한 후 그 백업으로부터 복원하는 절차는 다음과 같습니다:

1. 백업을 시작하는 방법에는 두 가지가 있습니다.

   • Method A.
     이 방법을 사용하려면 replication 프로세스를 시작하기 전에 source 서버에서 cluster backup 프로세스가 미리 활성화되어 있어야 합니다. 이를 위해서는 my.cnf file의 [mysql_cluster] 섹션에 다음 행을 포함시키면 됩니다. 여기서 management_host 는 source cluster의 NDB 관리 서버의 IP 주소 또는 호스트 이름이고, port 는 해당 관리 서버의 포트 번호입니다:

     1ndb-connectstring=management_host[:port]

     Note

     포트 번호는 기본 포트(1186)를 사용하지 않는 경우에만 지정해야 합니다. NDB Cluster에서의 포트 및 포트 할당에 대한 더 많은 정보는 Section 25.3.3, “Initial Configuration of NDB Cluster”를 참조하십시오.

     이 경우, 다음 문장을 replication source에서 실행하여 백업을 시작할 수 있습니다:

     1shellS> ndb_mgm -e "START BACKUP"

   • Method B.
     my.cnf 파일에 관리 호스트의 위치가 지정되어 있지 않은 경우, 이 정보를 START BACKUP 명령의 일부로 NDB 관리 클라이언트에 전달하여 백업 프로세스를 시작할 수 있습니다. 이는 다음과 같이 수행할 수 있으며, 여기서 management_host 와 port 는 관리 서버의 호스트 이름과 포트 번호입니다:

     1shellS> ndb_mgm management_host:port -e "START BACKUP"

     앞에서 설명한 시나리오(참조: Section 25.7.5, “Preparing the NDB Cluster for Replication”)에서는 이 명령을 다음과 같이 실행하게 됩니다:

     1shellS> ndb_mgm rep-source:1186 -e "START BACKUP"

2. online으로 가져오려는 replica에 cluster backup 파일을 복사합니다. source cluster에 대해 ndbd 프로세스를 실행하는 각 시스템에는 cluster backup 파일이 존재하며, 성공적인 복원을 보장하기 위해 이 모든 파일을 replica로 복사해야 합니다. backup 파일들은 replica의 관리 호스트가 존재하는 컴퓨터의 임의의 디렉터리에 복사할 수 있으며, 해당 디렉터리에 있는 파일들에 대해 MySQL 및 NDB 바이너리가 읽기 권한을 가지고 있기만 하면 됩니다. 여기서는 이 파일들이 디렉터리 /var/BACKUPS/BACKUP-1 에 복사된 것으로 가정합니다.

   replica cluster가 source와 동일한 데이터 노드 수를 갖는 것은 필수는 아니지만, 이 수가 동일하도록 강력히 권장됩니다. replication 프로세스가 replica 서버가 시작될 때 시작되지 못하도록 하는 것은 반드시 필요합니다. 이를 위해 replica를 --skip-replica-start 옵션과 함께 시작하면 됩니다.

3. source cluster에 존재하며 replication 대상이 되는 데이터베이스들을 replica cluster에 생성합니다.

주의

복제 대상이 되는 각 데이터베이스에 대응하는 CREATE DATABASE (또는 CREATE SCHEMA) 문장은 replica cluster의 각 SQL 노드에서 실행되어야 합니다.

4. mysql 클라이언트에서 다음 문장을 사용하여 replica cluster를 리셋합니다:

1mysqlR> RESET REPLICA;

5. 이제 replica에서 각 backup 파일에 대해 차례로 ndb_restore 명령을 사용하여 cluster 복원 프로세스를 시작할 수 있습니다. 이 중 첫 번째에 대해서는 cluster 메타데이터를 복원하기 위해 -m 옵션을 포함해야 하며, 다음과 같이 수행합니다:

1shellR> ndb_restore -c replica_host:port -n node-id \
2           -b backup-id -m -r dir

dir 은 backup 파일들이 replica에 배치된 디렉터리의 경로입니다. 나머지 backup 파일들에 대응하는 ndb_restore 명령에서는 -m 옵션을 사용해서는 안 됩니다.

4개의 데이터 노드를 가진 source cluster(도식은
[Section 25.7, “NDB Cluster Replication”](https://dev.mysql.com/doc/refman/9.5/en/mysql-cluster-replication.html "25.7 NDB Cluster Replication")에 나와 있음)에서 복원하는 경우이며 backup 파일들이 디렉터리
`/var/BACKUPS/BACKUP-1` 에 복사되어 있다고 할 때, replica에서 실행해야 할 적절한 명령 순서는 다음과 같을 수 있습니다:

1shellR> ndb_restore -c replica-host:1186 -n 2 -b 1 -m \
2           -r ./var/BACKUPS/BACKUP-1
3shellR> ndb_restore -c replica-host:1186 -n 3 -b 1 \
4           -r ./var/BACKUPS/BACKUP-1
5shellR> ndb_restore -c replica-host:1186 -n 4 -b 1 \
6           -r ./var/BACKUPS/BACKUP-1
7shellR> ndb_restore -c replica-host:1186 -n 5 -b 1 -e \
8           -r ./var/BACKUPS/BACKUP-1

주의

이 예제의 마지막 ndb_restore 호출에서 사용된 -e (또는 --restore-epoch) 옵션은 epoch가 replica의 mysql.ndb_apply_status 테이블에 기록되도록 보장하기 위해 필요합니다. 이 정보 없이는 replica가 source와 제대로 동기화할 수 없습니다. (자세한 내용은 Section 25.5.23, “ndb_restore — Restore an NDB Cluster Backup”을 참조하십시오.)

6. 이제 replica에서 ndb_apply_status 테이블로부터 가장 최근 epoch를 얻어야 합니다(이는 Section 25.7.8, “Implementing Failover with NDB Cluster Replication”에서 설명한 대로입니다):

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

7. 이전 단계에서 얻은 epoch 값인 @latest 를 사용하여, source의 mysql.ndb_binlog_index 테이블로부터 올바른 binary log 파일 @file 내의 올바른 시작 위치 @pos 를 얻을 수 있습니다. 여기 제시된 query는 논리적 복원 위치 이전에 적용된 마지막 epoch로부터 Position 및 File 열에서 이 값을 가져옵니다:

1mysqlS> SELECT
2        ->     @file:=SUBSTRING_INDEX(File, '/', -1),
3        ->     @pos:=Position
4        -> FROM mysql.ndb_binlog_index
5        -> WHERE epoch > @latest
6        -> ORDER BY epoch ASC LIMIT 1;

현재 replication traffic이 없는 경우, source에서 [`SHOW BINARY LOG STATUS`](https://dev.mysql.com/doc/refman/9.5/en/show-binary-log-status.html "15.7.7.1 SHOW BINARY LOG STATUS Statement")를 실행하고, 출력의 `File` 열에 표시된 모든 파일 중 suffix 값이 가장 큰 파일의 `Position` 열에 표시된 값을 사용하여 유사한 정보를 얻을 수 있습니다. 이 경우 어떤 파일이 해당되는지 판별한 후, 다음 단계에서 그 이름을 수동으로 제공하거나 스크립트로 출력을 파싱하여 제공해야 합니다.

8. 이전 단계에서 얻은 값들을 사용하여 이제 replica의 mysql 클라이언트에서 적절한 명령을 실행할 수 있습니다. 다음 CHANGE REPLICATION SOURCE TO 문을 사용하십시오:

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

9. 이제 replica가 source로부터 어떤 binary log 파일의 어떤 지점부터 데이터를 읽기 시작해야 하는지 알게 되었으므로, 다음 문장을 사용하여 replica가 replication을 시작하도록 할 수 있습니다:

1mysqlR> START REPLICA;

두 번째 replication 채널에서 backup 및 restore를 수행하려면, 호스트 이름과 ID를 주 source와 replica 서버 대신 보조 source와 replica의 것으로 적절히 대체하고, 위의 문장들을 해당 서버들에서 실행하는 것만으로 충분합니다.

Cluster backup을 수행하고 backup으로부터 Cluster를 복구하는 방법에 대한 추가 정보는 Section 25.6.8, “Online Backup of NDB Cluster”를 참조하십시오.