데브러너 (DevRunner)

19.4.2 Handling an Unexpected Halt of a Replica

replication이 서버의 예기치 않은 중지(때때로 crash-safe라고도 설명됨)에 대해 탄력성을 가지려면, 중지 전에 replica가 자신의 상태를 복구할 수 있어야 합니다. 이 섹션에서는 replication 중 replica가 예기치 않게 중지되었을 때의 영향과, replication을 계속할 수 있도록 복구 가능성을 최대화하도록 replica를 구성하는 방법을 설명합니다.

replica가 예기치 않게 중지된 후 재시작되면, replication SQL thread는 이미 실행된 트랜잭션에 대한 정보를 복구해야 합니다. 복구에 필요한 정보는 replica의 applier 메타데이터 리포지토리에 저장됩니다. 이 리포지토리는 기본적으로 mysql.slave_relay_log_info라는 이름의 InnoDB 테이블로 생성됩니다. 이 트랜잭션 스토리지 엔진을 사용함으로써, 재시작 시 정보는 항상 복구 가능합니다. applier 메타데이터 리포지토리에 대한 업데이트는 트랜잭션과 함께 커밋되며, 이는 해당 리포지토리에 기록된 replica의 진행 정보가, 예기치 않은 서버 중지 상황에서도 데이터베이스에 적용된 내용과 항상 일관성을 유지함을 의미합니다. applier 메타데이터 리포지토리에 대한 자세한 내용은 Section 19.2.4, “Relay Log and Replication Metadata Repositories”를 참조하십시오.

DML 트랜잭션과 원자 DDL 역시 데이터베이스에 변경 사항을 적용하는 것과 함께 하나의 원자 작업으로 replica의 applier 메타데이터 리포지토리 내 mysql.slave_relay_log_info 테이블의 replication 위치를 갱신합니다. 완전히 원자적이지 않은 DDL 문, 그리고 원자 DDL을 지원하지 않는 예외 스토리지 엔진을 포함한 그 밖의 모든 경우에는, 서버가 예기치 않게 중지되면 mysql.slave_relay_log_info 테이블은 복제된 데이터와 관련된 업데이트를 누락할 수 있습니다. 이 경우 업데이트를 복원하는 작업은 수동으로 수행해야 합니다. MySQL 9.5에서의 원자 DDL 지원 및 특정 문장의 replication에 대한 결과 동작에 대해서는 Section 15.1.1, “Atomic Data Definition Statement Support”를 참조하십시오.

replica가 예기치 않은 중지로부터 복구되는 과정은 replica의 구성에 따라 달라집니다. 복구 과정의 세부 동작은 선택한 replication 방법, replica가 싱글 스레드인지 멀티스레드인지, 그리고 관련 시스템 변수의 설정에 따라 영향을 받습니다.

복구 과정의 전체적인 목적은, 예기치 않은 중지가 발생하기 전에 replica의 데이터베이스에 이미 적용된 트랜잭션을 식별하고, 그 이후 replica가 놓친 트랜잭션을 찾아서 적용하는 것입니다.

GTID 기반 replication의 경우, 복구 과정에는 replica가 이미 수신했거나 커밋한 트랜잭션의 GTID가 필요합니다. 누락된 트랜잭션은 GTID 자동 위치 지정을 사용하여 source에서 가져올 수 있으며, 이는 source의 트랜잭션과 replica의 트랜잭션을 자동으로 비교하고 누락된 트랜잭션을 식별합니다.
파일 위치 기반 replication의 경우, 복구 과정에는 replica에 마지막으로 적용된 트랜잭션을 보여 주는 정확한 replication SQL thread(applier) 위치가 필요합니다. 그 위치를 기준으로 replication I/O thread(receiver)는 source의 바이너리 로그에서, 그 시점부터 replica에 적용되어야 할 모든 트랜잭션을 가져옵니다.

GTID 기반 replication을 사용하면, 예기치 않은 중지에 대해 탄력적인 replication 구성을 가장 쉽게 할 수 있습니다. GTID 자동 위치 지정을 사용하면, 적용된 트랜잭션 시퀀스에 공백이 있더라도 replica는 누락된 트랜잭션을 신뢰성 있게 식별하고 가져올 수 있습니다.

다음 정보는, replication의 제어 하에 있는 범위 내에서 복구를 보장하기 위해 서로 다른 유형의 replica에 적합한 설정 조합을 제공합니다.

주의

replication의 제어 범위를 벗어나는 몇 가지 요인이 replication 복구 과정과 복구 이후 replication의 전체 상태에 영향을 줄 수 있습니다. 특히 개별 스토리지 엔진의 복구 과정에 영향을 미치는 설정은, replica의 예기치 않은 중지 시 트랜잭션이 손실되고, 따라서 replication 복구 과정에 사용할 수 없게 되는 결과를 초래할 수 있습니다.

아래 목록에서 언급된 innodb_flush_log_at_trx_commit=1 설정은, 트랜잭션과 함께 InnoDB를 사용하는 replication 설정에서 핵심 설정입니다. 그러나, 특히 플러시 또는 동기화와 관련된 InnoDB나 다른 스토리지 엔진에 특화된 다른 설정 또한 영향을 미칠 수 있습니다. 선택한 스토리지 엔진이 크래시 세이프 설정에 대해 제시하는 권장 사항을 항상 확인하고 적용하십시오.

replica에서 다음 설정 조합은 예기치 않은 중지에 대해 가장 탄력적입니다:

GTID 기반 replication이 사용 중일 때 (gtid_mode=ON), SOURCE_AUTO_POSITION=1을 설정하여, source에 대한 연결에서 GTID 자동 위치 지정을 활성화하고 누락된 트랜잭션을 자동으로 식별하고 가져오도록 합니다. 이 옵션은 CHANGE REPLICATION SOURCE TO 문을 사용하여 설정합니다. replica에 replication 채널이 여러 개 있는 경우, 각 채널마다 이 옵션을 개별적으로 설정해야 합니다. GTID 자동 위치 지정의 동작 방식에 대한 자세한 내용은 Section 19.1.3.3, “GTID Auto-Positioning”을 참조하십시오. 파일 위치 기반 replication이 사용 중인 경우에는 SOURCE_AUTO_POSITION=1을 사용하지 않으며, 대신 replication 시작 위치를 제어하기 위해 바이너리 로그 위치 또는 릴레이 로그 위치를 사용합니다.
GTID 기반 replication이 사용 중일 때 (gtid_mode=ON), GTID_ONLY=1을 설정하여 replica가 복구 과정에서 GTID만 사용하도록 하고, replication 메타데이터 리포지토리에 바이너리 로그 및 릴레이 로그 파일 이름과 파일 위치를 더 이상 저장하지 않도록 합니다. 이 옵션은 CHANGE REPLICATION SOURCE TO 문을 사용하여 설정합니다. replica에 replication 채널이 여러 개 있는 경우, 각 채널마다 이 옵션을 개별적으로 설정해야 합니다. GTID_ONLY=1이 설정되면, 복구 중에는 파일 위치 정보가 무시되고, 올바른 파일 위치를 식별하는 대신, 이미 제공된 트랜잭션을 건너뛰기 위해 GTID 자동 건너뛰기가 사용됩니다. 이 전략은 relay_log_purge의 기본 설정을 사용하여 릴레이 로그를 정리(purge)하는 경우, 검사해야 할 릴레이 로그 파일이 하나뿐이라는 점에서 더 효율적입니다.
sync_relay_log=1을 설정하여, replication receiver thread가 수신한 각 트랜잭션이 릴레이 로그에 기록된 후 릴레이 로그를 디스크와 동기화하도록 지시합니다. 이는 applier 메타데이터 리포지토리 내에서 source의 바이너리 로그에서 읽은 현재 위치에 대한 replica의 기록이, 릴레이 로그에 저장된 트랜잭션 기록보다 앞서지 않도록 합니다. 이 설정은 가장 안전하지만, 디스크 쓰기 횟수가 많기 때문에 가장 느리기도 합니다.

s‍ync_relay_log > 1이거나, sync_relay_log=0(동기화가 운영체제에 의해 처리되는 경우)에서는, replica가 예기치 않게 중지되면 디스크에 동기화되지 않은 커밋된 트랜잭션이 존재할 수 있습니다. 이러한 트랜잭션은, 복구 중인 replica가 디스크에 마지막으로 동기화된 릴레이 로그 정보에 근거해 해당 트랜잭션을 건너뛰는 대신 다시 가져와서 적용하려고 할 경우, 복구 과정을 실패하게 만들 수 있습니다.

sync_relay_log=1 설정은 멀티스레드 replica에서 특히 중요하며, 릴레이 로그의 정보를 사용해 트랜잭션 시퀀스의 공백을 채울 수 없는 경우 복구 과정이 실패합니다. 싱글 스레드 replica의 경우, 복구 과정은 applier 메타데이터 리포지토리에 관련 정보가 존재하지 않을 때에만 릴레이 로그를 사용할 필요가 있습니다.

innodb_flush_log_at_trx_commit=1을 설정하여, 각 트랜잭션이 커밋되기 전에 InnoDB 로그를 디스크와 동기화합니다. 기본값인 이 설정은, 트랜잭션에 대한 정보가 더 이상 릴레이 로그에 의존하지 않도록 InnoDB 테이블과 InnoDB 로그가 디스크에 저장되도록 보장합니다. sync_relay_log=1 설정과 결합하면, 이 설정은 예기치 않은 중지 발생 시에도 replica의 트랜잭션 히스토리에서 릴레이 로그 파일을 정리하는 작업이 채울 수 없는 공백을 초래하지 않도록, InnoDB 테이블과 InnoDB 로그의 내용이 릴레이 로그의 내용과 항상 일관되도록 추가로 보장합니다.
relay_log_info_repository = TABLE을 설정하여, replication SQL thread 위치를 InnoDB 테이블인 mysql.slave_relay_log_info에 저장하고, 항상 정확한 기록을 보장하기 위해 트랜잭션 커밋과 함께 이를 갱신하도록 합니다. 이 설정은 기본값이며, FILE은 폐지 예정(deprecated)입니다. 시스템 변수 자체도 폐지 예정이므로, 이를 생략하고 기본값을 사용하도록 두십시오.

FILE을 사용하는 경우, 정보는 데이터 디렉터리에 있는 파일에 저장되며, 트랜잭션이 적용된 후에 갱신됩니다. 이는 replica가 어떤 단계에서 트랜잭션 처리 중에 중지되었는지에 따라, source와의 동기화를 잃을 위험 또는 파일 자체가 손상될 위험을 초래합니다. relay_log_info_repository = FILE을 사용하는 경우, 복구는 보장되지 않습니다.

relay_log_recovery = ON을 설정하여, 서버 시작 직후에 자동 릴레이 로그 복구를 활성화합니다. 이 글로벌 변수는 기본값이 OFF이며 런타임에서 읽기 전용이지만, replica가 예기치 않게 중지된 후 재시작할 때 --relay-log-recovery 옵션을 사용하여 ON으로 설정할 수 있습니다. 이 설정은 릴레이 로그 파일이 손상되었거나 불일치할 수 있으므로, 기존 릴레이 로그 파일을 무시한다는 점에 유의하십시오.

릴레이 로그 복구 과정은 새로운 릴레이 로그 파일을 시작하고, applier 메타데이터 리포지토리에 기록된 replication SQL thread 위치에서부터 source로부터 트랜잭션을 가져옵니다. 이전 릴레이 로그 파일은 replica의 일반적인 정리(purge) 메커니즘에 의해 시간이 지나면서 제거됩니다.

multithreaded replica의 경우, relay_log_recovery = ON을 설정하면 릴레이 로그에서 실행된 트랜잭션 시퀀스에 존재할 수 있는 불일치와 공백을 자동으로 처리합니다. 이러한 공백은 파일 위치 기반 replication이 사용 중일 때 발생할 수 있습니다(자세한 내용은 Section 19.5.1.35, “Replication and Transaction Inconsistencies”를 참조하십시오).

릴레이 로그 복구 과정은 START REPLICA UNTIL SQL_AFTER_MTS_GAPS 문이 사용하는 것과 동일한 방법으로 이러한 공백을 처리합니다. replica가 공백 없는 일관된 상태에 도달하면, 릴레이 로그 복구 과정은 replication SQL thread 위치에서부터 source로부터 추가 트랜잭션을 가져오는 작업을 계속합니다.

GTID 기반 replication이 사용 중인 경우, multithreaded replica는 먼저 SOURCE_AUTO_POSITION이 ON으로 설정되어 있는지 확인하고, 설정되어 있다면 건너뛰어야 할 트랜잭션과 건너뛰지 말아야 할 트랜잭션을 계산하는 단계를 생략하여, 이전 릴레이 로그가 복구 과정에 필요하지 않도록 합니다.