DBAtlas · Veritabanı operasyon atlası

Replika gecikmesini ve applier worker hatalarını izle (performance_schema)

MySQLReplikasyon

Komut

-- Receiver (I/O) thread: baglanti durumu ve son hata
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 worker'lar: hata, uygulanan GTID ve gercek gecikme
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;

Ne yapar?

SHOW REPLICA STATUS'un tek satırda özetlediği bilgiyi channel ve worker bazında verir: receiver thread durumu, her worker'ın son hatası, uygulanan / uygulanmakta olan GTID ve original commit timestamp'e göre hesaplanan gerçek gecikme.

Ne zaman kullanılır?

Seconds_Behind_Source güvenilmez göründüğünde (0 ile büyük değer arasında zıplama, NULL), multi-threaded replica'da hangi worker'ın takıldığını bulmak ve monitoring'e doğru bir lag metriği eklemek için.

Dikkat

current_lag_sec yalnız bir transaction uygulanırken anlamlıdır; replica boşta ise 0 döner. Receiver'ın da geride olup olmadığını görmek için LAST_QUEUED_TRANSACTION'ı kaynağın gtid_executed değeriyle karşılaştır. Original commit timestamp kaynağın saatine dayanır; sunucular arası saat farkı (NTP) sonucu saptırır. Seconds_Behind_Source büyük bir transaction'ın başında sıfıra yakın, sonunda birden yüksek görünür; uzun transaction'lar bu metriği yanıltır.

DBAtlas'ta aç →

İlgili