데브러너 (DevRunner)

20.5.6 Using MySQL Enterprise Backup with Group Replication

MySQL Enterprise Backup은 MySQL Server용으로 상용 라이선스가 적용된 백업 유틸리티이며, MySQL Enterprise Edition과 함께 제공됩니다. 이 절에서는 MySQL Enterprise Backup을 사용하여 Group Replication 멤버를 백업한 후 복구하는 방법을 설명합니다. 동일한 기법을 사용하여 그룹에 새 멤버를 빠르게 추가할 수 있습니다.

Backing up a Group Replication Member Using MySQL Enterprise Backup

Group Replication 멤버를 백업하는 것은 독립 실행형 MySQL 인스턴스를 백업하는 것과 유사합니다. 다음 지침은 백업을 수행하기 위해 MySQL Enterprise Backup 사용 방법을 이미 숙지하고 있다고 가정합니다. 그렇지 않다면 먼저 Backing Up a Database Server를 검토하십시오. 또한 Grant MySQL Privileges to Backup Administrator 및 Using MySQL Enterprise Backup with Group Replication에 설명된 요구 사항에 유의하십시오.

세 개의 멤버(s1, s2, s3)로 구성된 다음 그룹이 있고, 이들이 동일한 이름의 호스트에서 실행 중이라고 가정해 보겠습니다:

1mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
2+-------------+-------------+--------------+
3| member_host | member_port | member_state |
4+-------------+-------------+--------------+
5| s1          |        3306 | ONLINE       |
6| s2          |        3306 | ONLINE       |
7| s3          |        3306 | ONLINE       |
8+-------------+-------------+--------------+

MySQL Enterprise Backup을 사용하여, 예를 들어 다음 명령을 해당 호스트에서 실행해 s2의 백업을 생성합니다:

1s2> mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/backups/my.mbi_`date +%d%m_%H%M` \
2		      --backup-dir=/backups/backup_`date +%d%m_%H%M` --user=root -p \
3--host=127.0.0.1 backup-to-image

Restoring a Failed Member

세 멤버 중 하나(다음 예제에서는 s3)가 복구 불가능하게 손상되었다고 가정합니다. 그룹 멤버 s2의 최신 백업을 사용하여 s3를 복구할 수 있습니다. 복구를 수행하는 단계는 다음과 같습니다:

s3용 호스트로 s2의 백업을 복사합니다. 백업을 복사하는 정확한 방법은 사용하는 운영 체제와 사용 가능한 도구에 따라 달라집니다. 이 예제에서는 두 호스트가 모두 Linux 서버라고 가정하고, SCP를 사용하여 파일을 복사합니다:

1s2/backups> scp my.mbi_2206_1429 s3:/backups

백업을 복구합니다. 대상 호스트(이 경우 s3의 호스트)에 접속하여 MySQL Enterprise Backup을 사용해 백업을 복구합니다. 단계는 다음과 같습니다:
손상된 서버가 아직 실행 중이라면 중지합니다. 예를 들어 systemd를 사용하는 Linux 배포판에서:

1s3> systemctl stop mysqld

손상된 서버의 데이터 디렉터리에 있는 두 개의 설정 파일인 auto.cnf 및 mysqld-auto.cnf(존재하는 경우)를 데이터 디렉터리 외부의 안전한 위치로 복사하여 보존합니다. 이는 아래 단계에서 필요로 하는 서버의 UUID와 Section 7.1.9.3, “Persisted System Variables” (사용 중인 경우)을 보존하기 위한 것입니다.
s3의 데이터 디렉터리 내 모든 내용을 삭제합니다. 예를 들어:

1s3> rm -rf /var/lib/mysql/*

시스템 변수 innodb_data_home_dir, innodb_log_group_home_dir, innodb_undo_directory 가 데이터 디렉터리 이외의 디렉터리를 가리키는 경우, 해당 디렉터리 역시 비워야 합니다. 그렇지 않으면 복구 작업이 실패합니다.

s2의 백업을 s3용 호스트에 복구합니다:

1s3> mysqlbackup --defaults-file=/etc/my.cnf \
2  --datadir=/var/lib/mysql \
3  --backup-image=/backups/my.mbi_2206_1429  \
4--backup-dir=/tmp/restore_`date +%d%m_%H%M` copy-back-and-apply-log

Note

위 명령은 s2와 s3에서의 바이너리 로그와 릴레이 로그가 동일한 기본 이름을 가지고, 두 서버에서 동일한 위치에 존재한다고 가정합니다. 이러한 조건이 충족되지 않는 경우, --log-bin 및 --relay-log 옵션을 사용하여 s3에서 바이너리 로그와 릴레이 로그를 원래 파일 경로로 복구해야 합니다. 예를 들어, s3에서 바이너리 로그의 기본 이름이 s3-bin, 릴레이 로그의 기본 이름이 s3-relay-bin이라는 것을 알고 있다면, 복구 명령은 다음과 같아야 합니다:

1mysqlbackup --defaults-file=/etc/my.cnf \
2  --datadir=/var/lib/mysql \
3  --backup-image=/backups/my.mbi_2206_1429  \
4  --log-bin=s3-bin --relay-log=s3-relay-bin \
5  --backup-dir=/tmp/restore_`date +%d%m_%H%M` copy-back-and-apply-log

바이너리 로그와 릴레이 로그를 올바른 파일 경로로 복구할 수 있으면 복구 과정이 더 쉬워집니다. 어떤 이유로든 이것이 불가능하다면, Rebuild the Failed Member to Rejoin as a New Member를 참조하십시오.

s3용 auto.cnf 파일을 복구합니다. 복제 그룹에 다시 합류하려면 복구된 멤버는 그룹에 처음 조인할 때 사용했던 것과 동일한 server_uuid를 반드시(must) 가져야 합니다. 이를 위해 위의 2단계에서 보존해 둔 auto.cnf 파일을 복구된 멤버의 데이터 디렉터리로 복사하여 이전 서버 UUID를 제공합니다.

참고

실패한 멤버의 원래 server_uuid를 오래된 auto.cnf 파일을 복구하는 방식으로 복구된 멤버에 제공할 수 없다면, 복구된 멤버는 새 멤버로 그룹에 조인해야 합니다. 그 방법에 대해서는 아래의 Rebuild the Failed Member to Rejoin as a New Member에 있는 지침을 참조하십시오.

s3용 mysqld-auto.cnf 파일을 복구합니다 (s3가 퍼시스턴트 시스템 변수를 사용한 경우에만 필요).
실패한 멤버를 구성하는 데 사용되었던 Section 7.1.9.3, “Persisted System Variables”의 설정을 복구된 멤버에 제공해야 합니다. 이러한 설정은 실패한 서버의 mysqld-auto.cnf 파일에 있으며, 위 2단계에서 보존해 두어야 합니다. 해당 파일을 복구된 서버의 데이터 디렉터리로 복사합니다. 파일의 사본이 없는 경우 해야 할 일은 Restoring Persisted System Variables를 참조하십시오.
복구된 서버를 시작합니다. 예를 들어 systemd를 사용하는 Linux 배포판에서:

1systemctl start mysqld

참고

복구 중인 서버가 primary 멤버인 경우, 복구된 서버를 시작하기 전에
Restoring a Primary Member에 설명된 단계를 수행하십시오.

Group Replication을 재시작합니다. 예를 들어 mysql 클라이언트를 사용하여 재시작된 s3에 접속하고 다음 명령을 실행합니다:

1mysql> START GROUP_REPLICATION;

복구된 인스턴스가 그룹의 online 멤버가 되기 전에, 백업이 수행된 이후 그룹에서 발생한 모든 트랜잭션을 적용해야 합니다. 이는 Group Replication의 distributed recovery 메커니즘을 통해 이루어지며, START GROUP_REPLICATION 구문이 실행된 후 이 과정이 시작됩니다. 복구된 인스턴스의 멤버 상태를 확인하려면 다음을 실행합니다:

1mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
2+-------------+-------------+--------------+
3| member_host | member_port | member_state |
4+-------------+-------------+--------------+
5| s1          |        3306 | ONLINE       |
6| s2          |        3306 | ONLINE       |
7| s3          |        3306 | RECOVERING   |
8+-------------+-------------+--------------+

이는 s3가 그룹을 따라잡기 위해 트랜잭션을 적용 중임을 보여 줍니다. 나머지 그룹과의 동기화가 완료되면 member_state는 ONLINE으로 변경됩니다:

1mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
2+-------------+-------------+--------------+
3| member_host | member_port | member_state |
4+-------------+-------------+--------------+
5| s1          |        3306 | ONLINE       |
6| s2          |        3306 | ONLINE       |
7| s3          |        3306 | ONLINE       |
8+-------------+-------------+--------------+

참고

복구 중인 서버가 primary 멤버인 경우, 그룹과 동기화를 완료하여 ONLINE 상태가 되면, 서버를 시작하기 전에 수행했던 구성 변경을 되돌리기 위해 Restoring a Primary Member 끝부분에 설명된 단계를 수행하십시오.

이제 멤버는 백업에서 완전히 복구되었으며 그룹의 일반적인 멤버로 동작합니다.

Rebuild the Failed Member to Rejoin as a New Member

때때로 Restoring a Failed Member에 설명된 단계를 실행할 수 없는 경우가 있습니다. 예를 들어, 바이너리 로그 또는 릴레이 로그가 손상되었거나 백업에서 누락된 경우입니다. 이러한 상황에서는 백업을 사용하여 멤버를 다시 구축한 후, 새 멤버로 그룹에 추가해야 합니다. 아래 단계에서는 다시 구축된 멤버 이름이 실패한 멤버와 마찬가지로 s3이며, 동일한 호스트에서 실행된다고 가정합니다:

s3용 호스트로 s2의 백업을 복사합니다. 백업을 복사하는 정확한 방법은 사용하는 운영 체제와 사용 가능한 도구에 따라 달라집니다. 이 예제에서는 두 호스트가 모두 Linux 서버라고 가정하고, SCP를 사용하여 파일을 복사합니다:

1s2/backups> scp my.mbi_2206_1429 s3:/backups

백업을 복구합니다. 대상 호스트(이 경우 s3의 호스트)에 접속하여 MySQL Enterprise Backup을 사용해 백업을 복구합니다. 단계는 다음과 같습니다:
손상된 서버가 아직 실행 중이라면 중지합니다. 예를 들어 systemd를 사용하는 Linux 배포판에서:

1s3> systemctl stop mysqld

손상된 서버의 데이터 디렉터리에서 설정 파일 mysqld-auto.cnf가 발견되면, 이를 데이터 디렉터리 외부의 안전한 위치로 복사하여 보존합니다. 이는 나중에 필요하게 될 서버의 Section 7.1.9.3, “Persisted System Variables”를 보존하기 위한 것입니다.
s3의 데이터 디렉터리 내 모든 내용을 삭제합니다. 예를 들어:

1s3> rm -rf /var/lib/mysql/*

s2의 백업을 s3 호스트에 복구합니다. 이 접근 방식에서는 s3를 새 멤버로 재구축하며, 백업에 포함된 오래된 바이너리 로그와 릴레이 로그는 필요하지 않거나 사용하지 않으려 합니다. 따라서 이러한 로그가 백업에 포함된 경우 --skip-binlog 및 --skip-relaylog 옵션을 사용해 이를 제외합니다:

1s3> mysqlbackup --defaults-file=/etc/my.cnf \
2  --datadir=/var/lib/mysql \
3  --backup-image=/backups/my.mbi_2206_1429  \
4  --backup-dir=/tmp/restore_`date +%d%m_%H%M` \
5  --skip-binlog --skip-relaylog \
6copy-back-and-apply-log

Note

백업 안에 문제가 없는 바이너리 로그와 릴레이 로그가 있고, 이를 대상 호스트로 문제 없이 전송할 수 있다면, 위에 설명된 보다 간단한 절차인 Restoring a Failed Member를 따르는 것이 좋습니다.

s3용 mysqld-auto.cnf 파일을 복구합니다 (s3가 퍼시스턴트 시스템 변수를 사용한 경우에만 필요).
실패한 멤버를 구성하는 데 사용되었던 Section 7.1.9.3, “Persisted System Variables”의 설정을 복구된 서버에 제공해야 합니다. 이러한 설정은 실패한 서버의 mysqld-auto.cnf 파일에 있으며, 위 2단계에서 보존해 두어야 합니다. 해당 파일을 복구된 서버의 데이터 디렉터리로 복사합니다. 파일의 사본이 없는 경우 해야 할 일은 Restoring Persisted System Variables를 참조하십시오.

참고

손상된 서버의 auto.cnf 파일을 새 멤버의 데이터 디렉터리로 복구하지 마십시오. 재구축된 s3가 새 멤버로 그룹에 조인하면 새 서버 UUID가 할당됩니다.

복구된 서버를 시작합니다. 예를 들어 systemd를 사용하는 Linux 배포판에서:

1systemctl start mysqld

참고

복구 중인 서버가 primary 멤버인 경우, 복구된 서버를 시작하기 전에
Restoring a Primary Member에 설명된 단계를 수행하십시오.

복구된 멤버를 Group Replication에 조인하도록 재구성합니다. mysql 클라이언트로 복구된 서버에 접속한 후, 다음 구문을 사용하여 소스와 복제본 정보를 초기화합니다:

1mysql> RESET BINARY LOGS AND GTIDS;
2
3mysql> RESET REPLICA ALL;

복구된 서버가 Group Replication의 내장 메커니즘인 distributed recovery를 사용해 자동으로 복구하려면, 서버의 gtid_executed 변수를 구성해야 합니다. 이를 위해 일반적으로 복구된 멤버의 데이터 디렉터리 아래에 복구되는, s2 백업에 포함된 backup_gtid_executed.sql 파일을 사용합니다. 바이너리 로깅을 비활성화하고, backup_gtid_executed.sql 파일을 사용해 gtid_executed를 구성한 다음, 다음과 같이 mysql 클라이언트로 구문을 실행하여 바이너리 로깅을 다시 활성화합니다:

1mysql> SET SQL_LOG_BIN=OFF;
2mysql> SOURCE datadir/backup_gtid_executed.sql
3mysql> SET SQL_LOG_BIN=ON;

그런 다음, 멤버에서 다음 SQL 구문을 사용해 Group Replication user credentials을 구성합니다:

1mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user',
2       ->   SOURCE_PASSWORD='password'
3       ->   FOR CHANNEL 'group_replication_recovery';

Group Replication을 재시작합니다. mysql 클라이언트를 사용하여 복구된 서버에 다음 명령을 실행합니다:

1mysql> START GROUP_REPLICATION;

1mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
2+-------------+-------------+--------------+
3| member_host | member_port | member_state |
4+-------------+-------------+--------------+
5| s3          |        3306 | RECOVERING   |
6| s2          |        3306 | ONLINE       |
7| s1          |        3306 | ONLINE       |
8+-------------+-------------+--------------+

이는 s3가 그룹을 따라잡기 위해 트랜잭션을 적용 중임을 보여 줍니다. 나머지 그룹과의 동기화가 완료되면 member_state는 ONLINE으로 변경됩니다:

1mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
2+-------------+-------------+--------------+
3| member_host | member_port | member_state |
4+-------------+-------------+--------------+
5| s3          |        3306 | ONLINE       |
6| s2          |        3306 | ONLINE       |
7| s1          |        3306 | ONLINE       |
8+-------------+-------------+--------------+

참고

이제 멤버는 새 멤버로 그룹에 복구되었습니다.

Restoring Persisted System Variables.
mysqlbackup은 Section 7.1.9.3, “Persisted System Variables”를 백업하거나 보존하는 기능을 제공하지 않습니다. mysqld-auto.cnf 파일은 백업에 포함되지 않습니다. 복구된 멤버를 퍼시스턴트 변수 설정과 함께 시작하려면, 다음 중 하나를 수행해야 합니다:

손상된 서버에서 mysqld-auto.cnf 사본을 보존해 두었다가, 복구된 서버의 데이터 디렉터리로 복사합니다.
그룹의 다른 멤버에서 mysqld-auto.cnf 파일을 복사해 옵니다. 이때 해당 멤버가 손상된 멤버와 동일한 퍼시스턴트 시스템 변수 설정을 가지고 있어야 하며, 복구된 서버의 데이터 디렉터리에 이 파일을 복사합니다.
복구된 서버를 시작한 후 Group Replication을 재시작하기 전에, mysql 클라이언트를 통해 모든 시스템 변수를 퍼시스턴트 값으로 수동 설정합니다.

Restoring a Primary Member.
복구된 멤버가 그룹에서 primary인 경우, Group Replication distributed recovery 과정 동안 복구된 데이터베이스에 대한 쓰기를 방지해야 합니다. 클라이언트가 그룹에 접근하는 방식에 따라, 복구된 멤버가 네트워크에서 접속 가능해지면 멤버가 그룹에서 벗어나 있던 동안 놓쳤던 작업을 따라잡기 전에 복구된 멤버에서 DML 구문이 실행될 가능성이 있습니다. 이를 방지하려면, 복구된 서버를 시작하기 전에
서버 옵션 파일에서 다음 시스템 변수를 구성합니다:

1group_replication_start_on_boot=OFF
2super_read_only=ON
3event_scheduler=OFF

이 설정은 멤버가 시작 시 읽기 전용 상태가 되도록 보장하고, distributed recovery 과정 동안 멤버가 그룹을 따라잡는 동안 이벤트 스케줄러가 비활성화되도록 합니다. 또한 이 기간 동안 복구 중인 멤버에서 DML 작업을 수행할 수 없으므로, 클라이언트 측에서는 적절한 오류 처리를 제공해야 합니다.

복구 과정이 완전히 완료되고, 복구된 멤버가 나머지 그룹과 동기화되면 이 설정을 되돌릴 수 있습니다. 먼저 다음 구문을 사용해 이벤트 스케줄러를 재시작합니다:

1mysql> SET global event_scheduler=ON;

그런 다음 다음 번 멤버가 시작될 때 필요한 값이 적용되도록, 멤버의 옵션 파일에서 다음 시스템 변수를 다음 값으로 설정해야 합니다:

1group_replication_start_on_boot=ON
2super_read_only=OFF
3event_scheduler=ON