replica 지연 및 applier worker 오류 모니터링(performance_schema)

명령어

-- Receiver (I/O) thread: connection state and last error
SELECT CHANNEL_NAME, SERVICE_STATE, LAST_ERROR_NUMBER,
       LEFT(LAST_ERROR_MESSAGE, 100) AS last_error,
       LAST_QUEUED_TRANSACTION, LAST_HEARTBEAT_TIMESTAMP
FROM performance_schema.replication_connection_status;

-- Applier workers: error, applied GTID and real lag
SELECT CHANNEL_NAME, WORKER_ID, SERVICE_STATE, LAST_ERROR_NUMBER,
       LEFT(LAST_ERROR_MESSAGE, 120) AS last_error,
       LAST_APPLIED_TRANSACTION,
       APPLYING_TRANSACTION,
       IF(APPLYING_TRANSACTION = '', 0,
          TIMESTAMPDIFF(SECOND, APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP, NOW(6))) AS current_lag_sec,
       TIMESTAMPDIFF(MICROSECOND, LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP,
                     LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP) / 1000000 AS last_trx_lag_sec
FROM performance_schema.replication_applier_status_by_worker
ORDER BY CHANNEL_NAME, WORKER_ID;

하는 일

SHOW REPLICA STATUS가 한 행으로 요약하는 내용을 채널별·worker별로 세분화한다: receiver 스레드 상태, 각 worker의 마지막 오류, 적용 완료 / 적용 중인 GTID, 원본 커밋 타임스탬프로 계산한 실제 지연.

사용 시점

Seconds_Behind_Source를 신뢰하기 어려울 때(0과 큰 값 사이를 오가거나 NULL), 멀티스레드 replica에서 어느 worker가 멈췄는지 찾을 때, 모니터링에 정확한 지연 지표를 제공할 때.

주의

current_lag_sec는 트랜잭션이 적용 중일 때만 의미가 있으며 idle replica는 0을 반환한다. receiver도 뒤처졌는지 보려면 LAST_QUEUED_TRANSACTION을 source의 gtid_executed와 비교한다. 원본 커밋 타임스탬프는 source 시계를 기준으로 하므로 서버 간 시간 차이(NTP)가 결과를 왜곡한다. Seconds_Behind_Source는 대형 트랜잭션 시작 시 0 근처에 머물다가 끝날 때 급증하므로, 장시간 트랜잭션이 있으면 이 지표는 오해를 일으킨다.