Aurora MySQL의 바이너리 로그 복제 지연 문제 해결

이 섹션에서는 바이너리 로그 복제본으로 구성된 Aurora MySQL의 바이너리 로그 복제 지연에 대한 지침을 제공합니다. 복제 아키텍처, 병렬 복제, 종속성 추적, 모니터링 및 구성 모범 사례를 다룹니다.

바이너리 로그 복제는 MySQL 호환 데이터베이스 간에 데이터를 복제합니다. 이 섹션에서 다루는 바이너리 로그 복제는 비동기식입니다. 즉, 소스는 트랜잭션을 커밋하기 전에 복제본이 변경 사항 적용을 확인할 때까지 기다리지 않습니다. 이는 반동기식 복제에는 적용되지 않습니다. 반동기식 복제에서 소스는 커밋하기 전에 하나 이상의 복제본이 트랜잭션 수신을 확인할 때까지 기다립니다. 예를 들어 Amazon RDS for MySQL의 다중 AZ DB 클러스터는 이 섹션의 범위를 벗어나는 반동기식 복제를 사용합니다. 복제본은 I/O 스레드를 통해 소스에 대한 지속적인 연결을 유지하여 바이너리 로그 이벤트를 지속적으로 스트리밍합니다. 이 섹션은 Aurora MySQL이 복제본인 모든 binlog 복제 토폴로지에 적용됩니다. 소스는 다른 Aurora MySQL 클러스터, Amazon RDS for MySQL, 온프레미스 MySQL 또는 Amazon EC2의 MySQL일 수 있습니다. 이 섹션은 Aurora MySQL이 MySQL 호환 대상에 복제하는 소스일 때에도 적용됩니다.

지금 지연 시간이 급증하고 있나요? 배경 자료를 건너뛰고 복제 지연 병목 현상 식별부터 시작하여 I/O 스레드와 SQL 스레드 중 어느 쪽이 병목 현상을 일으키는지 확인한 다음, 해당 시나리오의 링크(I/O 스레드 지연 문제 해결 또는 SQL 스레드 지연 문제 해결)로 이동하세요.

MySQL 복제 아키텍처

MySQL 복제는 특수 스레드를 통해 구현됩니다.

복제 프로세스는 다음과 같이 작동합니다.

복제 지연 병목 현상 식별

복제 지연은 I/O 스레드 또는 SQL 스레드의 두 영역에서 발생할 수 있습니다. 첫 번째 단계는 어떤 구성 요소가 지연되고 있는지 확인하는 것입니다.

Source_Log_File:       mysql-bin.000045
Read_Source_Log_Pos:   524288000
Relay_Source_Log_File: mysql-bin.000045
Exec_Source_Log_Pos:   524200000

File:     mysql-bin.000045
Position: 1073741824

I/O 스레드 지연 문제 해결

I/O 스레드는 소스에서 바이너리 로그 이벤트를 가져와 릴레이 로그에 기록하는 역할을 합니다. 일반적인 원인 및 해결 방법:

I/O 스레드 지연에 대한 최적화 전략

SQL 스레드 지연 문제 해결

I/O 스레드가 소스를 따라잡았지만 Seconds_Behind_Source가 증가하고 있다면, SQL 스레드에서 병목 현상이 발생하고 있는 것입니다. 지연을 정량화하려면 15분 동안 모니터링하며, 소스의 binlog 생성 속도(SHOW MASTER STATUS의 Position 변경 수치)와 복제본의 SQL 스레드 적용 속도(Exec_Source_Log_Pos 변경 수치)를 비교합니다.

일반적인 원인 및 해결 방법:

SELECT t.table_schema, t.table_name
FROM information_schema.tables t
  LEFT JOIN information_schema.table_constraints tc
    ON t.table_schema = tc.table_schema
    AND t.table_name = tc.table_name
    AND tc.constraint_type = 'PRIMARY KEY'
WHERE tc.constraint_type IS NULL
  AND t.table_type = 'BASE TABLE'
  AND t.table_schema NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys')
ORDER BY 1;

SELECT trx_id, trx_started, trx_rows_modified, trx_query
FROM information_schema.innodb_trx
WHERE trx_rows_modified > 10000
ORDER BY trx_started;

SELECT database_name, table_name,
    MIN(last_update) AS oldest_stat_update,
    DATEDIFF(NOW(), MIN(last_update)) AS stats_age_in_days
FROM mysql.innodb_index_stats
WHERE database_name NOT IN ('mysql', 'sys')
GROUP BY database_name, table_name
HAVING stats_age_in_days > 7
ORDER BY stats_age_in_days DESC;

복제본 측 복제 필터를 통한 적용 워크로드 감소

Aurora MySQL 버전 3.01.0 이상에서는 복제본 측 복제 필터를 지원합니다. 이 필터를 활용하면 적용 시 관련 없는 데이터베이스나 테이블을 건너뛸 수 있어 SQL 스레드의 워크로드가 줄어듭니다. 복제본 측 필터는 SQL 스레드에 의해 적용됩니다. 즉, I/O 스레드는 소스에서 모든 바이너리 로그 이벤트를 계속 가져오므로 이러한 필터는 네트워크 전송량이 아닌 적용 작업만 줄여줍니다. 소스 측 필터(데이터베이스 수준에서만 작동)와 달리 복제본 측 필터는 replicate-do-table 및 replicate-ignore-table을 사용하여 테이블 수준의 세분화를 지원합니다. 자세한 내용은 Aurora MySQL을 사용한 복제 필터 구성 섹션을 참조하세요.

다중 스레드 복제(MTR)

MTR을 사용하면 복제본이 독립적인 트랜잭션을 병렬로 적용합니다. 단일 대용량 트랜잭션을 병렬 부분으로 분할할 수 없습니다. 병렬 처리 수준은 소스에서 기록한 종속성 정보에 의해 제한됩니다.

MTR이 활성화되면(replica_parallel_workers >= 2) SQL 어플라이어가 코디네이터 스레드와 여러 워커 스레드로 분할됩니다. 코디네이터는 릴레이 로그에서 트랜잭션을 읽으며, 각 트랜잭션에 소스가 포함하는 논리적 타임스탬프(last_committed 및 sequence_number)를 검사합니다. 그런 다음 사용 가능한 워커 스레드에 독립적인 트랜잭션을 할당하여 병렬로 실행합니다. 두 트랜잭션은 데이터 종속성을 공유하지 않는 경우, 즉 서로 다른 행을 수정하는 경우 독립적입니다. 소스는 구성된 종속성 추적 방법을 사용하여 커밋 시 이러한 종속성을 결정하고 바이너리 로그에 기록합니다. 복제본은 소스가 허용하는 것 이상으로 병렬 처리를 늘릴 수 없습니다.

MTR이 권장 기본값

MTR이 활성화된 상태에서 복제본을 실행하는 것이 좋습니다. MTR은 MySQL 8.0.27 이상(해당 릴리스를 기반으로 하는 Aurora MySQL 3 버전 포함)에서 기본적으로 활성화되어 있습니다(replica_parallel_workers=4). 이전 버전(Aurora MySQL 2.12.1 이상 또는 8.0.27 이전 MySQL 릴리스 기반 버전)에서는 replica_parallel_workers를 2 이상의 값으로 설정하여 명시적으로 활성화해야 합니다. MTR을 활성화 상태로 유지하면 병렬 처리를 사용할 수 없을 때 비용이 거의 발생하지 않으며, 워크로드가 허용할 때마다 복제본이 병렬 처리의 이점을 활용할 수 있습니다.

MTR은 다음과 같은 경우 지연을 줄이지 못합니다.

소스에 대한 종속성 추적

소스는 binlog_transaction_dependency_tracking 파라미터를 사용하여 병렬로 적용할 수 있는 트랜잭션을 결정합니다. 권장 값: WRITESET.

병렬 유형(replica_parallel_type)

replica_parallel_type 파라미터는 트랜잭션이 워커 스레드 간에 분산되는 방식을 결정합니다. 두 가지 옵션이 있습니다.

MTR 구성

병렬 워커 설정을 변경한 후 복제를 다시 시작합니다.

CALL mysql.rds_stop_replication;
CALL mysql.rds_start_replication;

Aurora 전용 복제 최적화

Aurora MySQL은 바이너리 로그 복제 성능을 개선하기 위해 다음과 같은 기능을 제공합니다. 다음 표는 각 기능의 이용 가능 여부, 기본 상태, 활성화 방법을 요약한 것입니다.

병렬 복제 모니터링

다음 방법을 사용하여 복제 성능을 모니터링하고 병렬 적용의 병목 현상을 식별하세요.

성능 스키마

MTR 모니터링을 위한 주요 테이블:

워커 스레드 간에 작업이 얼마나 균등하게 분산되는지 평가하려면 다음 쿼리를 사용합니다.

SELECT
  a.channel_name,
  rw1.thread_id AS replica_worker_thread_id,
  ts1.count_star AS number_of_trx_executed,
  ROUND((ts1.count_star / sum_count_star) * 100, 2) AS percent_of_trx_executed_by_worker
FROM (
  SELECT rw.channel_name, SUM(ts.count_star) AS sum_count_star
  FROM performance_schema.events_transactions_summary_by_thread_by_event_name AS ts
    JOIN performance_schema.replication_applier_status_by_worker AS rw
      ON ts.thread_id = rw.thread_id
  GROUP BY rw.channel_name
) AS a
JOIN performance_schema.replication_applier_status_by_worker AS rw1
  ON a.channel_name = rw1.channel_name
JOIN performance_schema.events_transactions_summary_by_thread_by_event_name AS ts1
  ON rw1.thread_id = ts1.thread_id;

한두 개의 워커가 대부분의 트랜잭션을 처리하는 경우, 이는 병렬 처리를 제한하는 높은 트랜잭션 종속성을 나타냅니다. 소스에서 WRITESET 종속성 추적으로 전환하는 것이 좋습니다.

I/O 스레드와 SQL 스레드의 위치가 서로 가깝지만 Seconds_Behind_Source가 계속 증가하는 경우, 코디네이터 스레드 자체가 병목 현상의 원인일 수 있습니다. performance_schema.replication_applier_status_by_coordinator에서 버퍼링 지연을 확인하세요. 코디네이터 병목 현상은 일반적으로 트랜잭션 종속성이 심하거나, 단일 코디네이터 스레드가 과부하되어 이벤트를 충분히 빠르게 분산시키지 못하는 상황을 나타냅니다.

오류 로그 다중 스레드 복제본 통계

log_error_verbosity=3(기본값)일 때 Aurora MySQL은 다중 스레드 복제본 통계를 MySQL 오류 로그에 주기적으로 기록합니다. 다음 방법으로 이러한 항목을 볼 수 있습니다.

오류 로그에서 다중 스레드 복제본 통계 항목을 찾으려면 다음 예에 표시된 문자열을 검색합니다. MySQL 오류 로그는 이 내부 문자열에 레거시 용어를 사용하지만, 이 문서 전반에서는 권장 용어인 “replica”를 사용합니다.

다음은 오류 로그 항목의 예입니다.

2026-05-10 14:54:28.045308 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 7215200; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 1203644200 waited (count) when Workers occupied = 1022462 waited when Workers occupied = 62349203500

분석할 주요 필드:

실제 예제: 병렬 적용 병목 현상 진단

다음 예제에서는 앞서 설명한 모니터링 소스를 사용하여 일반적인 병렬 적용 병목 현상을 진단하는 방법을 보여줍니다. 각 예제는 동일한 증상, 즉 Seconds_Behind_Source가 지속적으로 증가하고 SQL 스레드가 병목 현상의 원인임을 이미 확인한 상황(복제 지연 병목 현상 식별 참조)에서 시작하며, 다중 스레드 복제본 통계와 성능 스키마를 활용해 수정 조치를 결정합니다.

예제 1: 워커 프로비저닝 부족

CloudWatch에서 ReplicaLag 지표는 30분 동안 0초에 가깝던 상태에서 약 400초까지 지속적으로 증가합니다. 복제본의 CPU 사용률은 약 55%로 유지되므로 복제본이 CPU 집약적 상태인 것은 아닙니다.

지연이 발생하는 위치를 확인하려면 60초 간격으로 SHOW REPLICA STATUS를 두 번 실행합니다. Read_Source_Log_Pos는 약 1.2GB 진전되는 반면, Exec_Source_Log_Pos는 약 300MB만 진전됩니다. I/O 스레드는 소스를 잘 따라잡고 있지만 SQL 스레드가 뒤처지고 있으며, SQL 스레드가 병목 현상의 원인입니다.

MTR은 replica_parallel_workers=4로 활성화되어 있습니다. 오류 로그에서 최신 다중 스레드 복제본 통계를 검색합니다(오류 로그 다중 스레드 복제본 통계 참조).

2026-05-10 14:54:28.045308 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 123; events assigned = 9876544; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 8455000 waited (count) when Workers occupied = 2456789 waited when Workers occupied = 110293847000

주요 필드 해석:

진단: 코디네이터에 적용 준비가 완료된 독립 트랜잭션보다 이를 실행할 워커의 수가 지속적으로 더 적습니다. 클럭 충돌 대기 시간은 무시할 수 있는 수준이므로 병렬 처리는 종속성이 아닌 워커 수에 의해 제한됩니다.

조치: replica_parallel_workers를 복제본의 vCPU 수(예: db.r6g.4xlarge의 경우 16)로 늘리고 복제를 다시 시작합니다.

CALL mysql.rds_stop_replication;
CALL mysql.rds_start_replication;

확인: 이후 통계 라인에 대기 시간이 거의 사라지고 ReplicaLag가 5초 미만으로 돌아온 것으로 표시됩니다.

2026-05-10 15:02:14.882201 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 31840552; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 9120000 waited (count) when Workers occupied = 41233 waited when Workers occupied = 5980411000

“waited when Workers occupied”가 약 110초에서 약 6초로 줄어들었고, 처리량(할당된 이벤트 수)이 세 배 이상 증가했습니다. CPU 사용률이 80%에 가까워지거나 대기 시간이 더 이상 감소하지 않으면 워커 수 늘리기를 중단하세요.

예제 2: COMMIT_ORDER 종속성 추적은 동시성이 낮은 워크로드를 직렬화함

소스는 4~8개의 애플리케이션 스레드만 동시에 커밋하는 OLTP 워크로드를 실행하는 Amazon RDS for MySQL 인스턴스입니다. 복제본은 db.r6g.4xlarge이며, replica_parallel_workers=16 및 replica_parallel_type=LOGICAL_CLOCK으로 설정되어 있습니다. 16개의 워커가 있음에도 불구하고, ReplicaLag는 약 600초로 유지되고 복제본 CPU 사용률은 약 20%에 불과하여 워커가 유휴 상태인 것처럼 보입니다.

먼저 성능 스키마의 worker-distribution 쿼리를 사용하여 워커 간에 트랜잭션이 얼마나 균등하게 분산되는지 확인합니다.

+--------------+--------------------------+------------------------+-----------------------------------+
| channel_name | replica_worker_thread_id | number_of_trx_executed | percent_of_trx_executed_by_worker |
+--------------+--------------------------+------------------------+-----------------------------------+
|              |                       45 |                1903556 |                             96.41 |
|              |                       46 |                  23104 |                              1.17 |
|              |                       47 |                  18995 |                              0.96 |
|              |                       48 |                  16720 |                              0.85 |
.
.
+--------------+--------------------------+------------------------+-----------------------------------+

위의 출력은 워커 스레드 16개 중 처음 4개를 보여줍니다. 한 워커가 트랜잭션의 96% 이상을 적용하고, 나머지 15개는 거의 유휴 상태입니다(나머지 워커는 각각 0.05% 미만을 실행함). 적용은 사실상 직렬로 진행됩니다.

그런 다음 오류 로그의 다중 스레드 복제본 통계를 통해 이를 확인합니다.

2026-05-10 15:22:11.110432 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 2014500; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 98712340000 waited (count) when Workers occupied = 50122 waited when Workers occupied = 1209847000

이는 용량 문제가 아니라 종속성 문제임을 나타냅니다. 소스에서 종속성 추적 방법을 확인하세요.

SELECT @@global.binlog_transaction_dependency_tracking;

+-------------------------------------------------+
| @@global.binlog_transaction_dependency_tracking |
+-------------------------------------------------+
| COMMIT_ORDER                                    |
+-------------------------------------------------+

근본 원인: COMMIT_ORDER를 사용하면, 소스가 동일한 바이너리 로그 그룹 커밋에서 어떤 트랜잭션들이 함께 커밋되었는지를 기반으로 병렬 실행 가능한 트랜잭션을 결정합니다. 이처럼 동시성이 낮은 워크로드에서는 한 번에 소수의 스레드만 커밋하므로 그룹 커밋 크기가 매우 작습니다. 그 결과, 소스는 거의 모든 트랜잭션에 이전 트랜잭션의 sequence_number와 동일한 last_committed 값을 부여하여, 해당 트랜잭션이 그 바로 앞의 트랜잭션에 종속되어 있는 것으로 표시합니다. 그러면 복제본은 이러한 트랜잭션이 완전히 관련 없는 행을 수정하더라도 트랜잭션을 차례대로 적용해야 하며, 이 때문에 16개의 워커 중 15개가 유휴 상태로 머물게 됩니다.

조치: 소스를 커밋 타이밍과 독립적인 행 수준 종속성 추적으로 전환합니다. 이를 동적으로 설정하고 클러스터(또는 DB) 파라미터 그룹에 저장합니다.

SET GLOBAL binlog_transaction_dependency_tracking = WRITESET;

WRITESET은 각 트랜잭션이 수정하는 행의 해시를 계산하므로, 서로 다른 행을 수정하는 트랜잭션은 독립적인 타임스탬프를 부여받아 커밋 시기에 관계없이 병렬로 적용될 수 있습니다. WRITESET는 프라이머리 키가 없는 테이블에 대해 빈 쓰기 세트를 생성하므로 모든 테이블에 프라이머리 키가 있는지 확인합니다(SQL 스레드 지연 문제 해결 참조). MySQL 8.4에서는 WRITESET가 기본값으로 설정되었으므로 이 파라미터는 더 이상 존재하지 않습니다.

확인: 변경 후 worker-distribution 쿼리 결과, 모든 워커에 작업이 균등하게 분산된 것으로 나타납니다(16개 중 처음 4개만 표시되며, 각 워커는 이제 약 6%의 트랜잭션을 처리함).

+--------------+--------------------------+------------------------+-----------------------------------+
| channel_name | replica_worker_thread_id | number_of_trx_executed | percent_of_trx_executed_by_worker |
+--------------+--------------------------+------------------------+-----------------------------------+
|              |                       45 |                 132540 |                              6.30 |
|              |                       46 |                 125610 |                              5.97 |
|              |                       47 |                 129774 |                              6.17 |
|              |                       48 |                 122901 |                              5.84 |
.
.
+--------------+--------------------------+------------------------+-----------------------------------+

또한 오류 로그 통계에서 클럭 충돌이 줄어들고 ReplicaLag가 거의 0으로 줄어든 것을 볼 수 있습니다.

2026-05-10 15:41:55.204713 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 19874100; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 412300000 waited (count) when Workers occupied = 88122 waited when Workers occupied = 7019847000

“waited at clock conflicts”가 약 99초에서 약 0.4초로 감소했고, 처리량이 약 10배 증가했으며, 병목 현상의 원인이 종속성에서 워커 용량으로 바뀌었습니다. 이 시점에서 예제 1과 같이 워커 수를 조정할 수 있습니다.

예제 3: 프라이머리 키 부재로 인해 복제본에서 전체 테이블 스캔이 강제 수행됨

ReplicaLag는 대규모 UPDATE 및 DELETE 문을 실행하는 야간 배치 작업 중에 급증한 후 복구됩니다. 급증하는 동안 복제본 CPU 사용률은 보통 수준이지만 워커 하나가 멈춘 것처럼 보입니다.

복제본에서 SHOW PROCESSLIST를 실행하고 복제 워커 스레드를 살펴봅니다. 한 워커가 한 번에 몇 초 동안 동일한 문에서 Updating 상태를 유지합니다.

+----+-------------+------+---------+----------+------+
| Id | User        | db   | Command | State    | Time |
+----+-------------+------+---------+----------+------+
| 12 | system user | app  | Connect | Updating |   38 |
+----+-------------+------+---------+----------+------+

SQL 스레드 지연 문제 해결의 탐지 쿼리를 사용하여 프라이머리 키가 없는 복제된 테이블을 확인하세요.

+--------------+----------------+
| table_schema | table_name     |
+--------------+----------------+
| app          | events_archive |
+--------------+----------------+

근본 원인: ROW 기반 바이너리 로깅을 사용하는 경우 UPDATE 또는 DELETE 이벤트의 각 행은 복제본에서 먼저 그 위치를 찾아야 적용할 수 있습니다. 테이블에 프라이머리 키 또는 고유한 NOT NULL 키가 없는 경우 복제본은 영향을 받는 모든 행에 대해 전체 테이블 스캔을 수행합니다. 수백만 개의 행이 있는 테이블에서 배치 작업은 수백만 번의 전체 스캔으로 이어지며, 이를 적용하는 워커가 멈춰 적용 진행이 차단되고 지연이 증가합니다.

조치: 테이블에 프라이머리 키를 추가합니다. 명시적 키를 즉시 정의할 수 없는 경우 sql_generate_invisible_primary_key 파라미터를 ON으로 설정하여 생성된 보이지 않는 프라이머리 키(GIPK)(MySQL 8.0.30 이상 기반의 Aurora MySQL 3 버전에서 사용 가능)를 활성화합니다. 그러면 새 테이블에 자동 프라이머리 키가 부여됩니다(SQL 스레드 지연 문제 해결 참조).

확인: 프라이머리 키를 추가한 후 워커는 더 이상 Updating에 머무르지 않고 SQL 스레드 적용 속도가 복구되며 다음 배치 기간 동안 ReplicaLag가 기준선으로 돌아갑니다.

예제 4: 단일 대용량 트랜잭션을 병렬화할 수 없음

ReplicaLag는 매일 예측 가능한 시간에 급격히 증가했다가 몇 분 동안 유지된 다음 거의 0으로 떨어집니다. WRITESET 종속성 추적이 활성화되어 있고, replica_parallel_workers=16이며, 모든 테이블에 프라이머리 키가 있으므로 이전 예제는 적용되지 않습니다.

급증하는 동안 worker-distribution 쿼리 시 하나의 워커가 사용 중이고 나머지는 유휴 상태인 것으로 나타나지만, 예제 2와 달리 오류 로그에는 높은 클럭 충돌이나 워커 점유 대기가 표시되지 않습니다.

2026-05-10 02:13:40.551922 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 95; events assigned = 4120000; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 1530000 waited (count) when Workers occupied = 980 waited when Workers occupied = 210440000

종속성 대기와 워커 점유 대기가 모두 낮지만 워커 하나만 활성 상태입니다. 따라서 종속성 병목 현상(예제 2)과 워커 용량 병목 현상(예제 1)은 모두 배제됩니다.

performance_schema.replication_applier_status_by_worker에서 사용 중인 워커를 검사하거나 SHOW PROCESSLIST를 실행합니다. 급증이 지속하는 내내, 단일 워커가 하나의 트랜잭션을 적용하고 있습니다. 소스에서 애플리케이션 작업이 하나의 큰 문(예: 수백만 개의 행에 영향을 미치는 DELETE FROM orders WHERE created_at < '2025-01-01')을 단일 트랜잭션으로 실행합니다.

근본 원인: MTR은 독립적인 트랜잭션 간에 병렬화되며, 단일 트랜잭션을 워커 간에 분할할 수 없습니다. 대용량 트랜잭션은 정확히 한 워커에 의해 적용되므로 워커 추가, WRITESET로 전환 또는 프라이머리 키 추가는 도움이 되지 않습니다. 자세한 내용은 다중 스레드 복제(MTR) 섹션을 참조하세요.

조치: 소스에서 대규모 작업을 더 작은 배치로 분할합니다(예: 배치 사이에 짧은 일시 중지 시간을 두면서 트랜잭션당 수천 행의 청크 단위로 삭제). 작은 트랜잭션은 독립적으로 커밋되므로 복제본이 이를 워커 간에 분산시킬 수 있습니다. 가능하면 트래픽이 적은 기간에 대량 작업을 예약합니다.

확인: 작업을 배치 처리한 후 일간 ReplicaLag 급증이 완화되며, worker-distribution 쿼리 시 배치가 단일 워커가 아닌 여러 워커에 분산된 것으로 나타납니다.

모니터링 모범 사례

복제 지연 최소화 모범 사례

다음 권장 사항은 복제 지연을 최소화하기 위한 주요 조치를 요약한 것입니다. 각 주제에 대한 자세한 지침은 상호 참조 링크를 참조하세요.