MySQL Replikasyon Gecikmesi: Neden Gecikiyor ve Nasıl Kapatılır?
IO ve SQL thread gecikmesini ayırt eder, yaygın nedenleri (büyük transaction, PK'sız tablo, tek thread) bulur ve gecikmeyi kapatma adımlarını verir.
Operasyonel Güvenlik ve Risk Uyarısı
Bu runbook müdahale adımları içerir; birçok adım yazma etkilidir (KILL, terminate, DROP, RESIZE). Önce test ortamında deneyin, üretimde adımları sırayla ve doğrulayarak uygulayın.
1. Belirti / Symptom
- `Seconds_Behind_Source` büyüyor (M15 > 30 sn).
- Replica'dan okuyan uygulamalar eski veri görüyor.
- Daha kötüsü: `Replica_IO_Running` veya `Replica_SQL_Running` = `No`.
2. Etki / Impact
Okuma tutarsızlığı, failover'da veri kaybı riski (RPO bozulur), yedek replica'dan alınıyorsa tutarsız yedek.
3. Teşhis / Diagnosis
SHOW REPLICA STATUS\G -- 8.0.22 öncesi: SHOW SLAVE STATUS\GBakılacaklar: `Replica_IO_Running`, `Replica_SQL_Running`, `Seconds_Behind_Source`, `Last_IO_Error`, `Last_SQL_Error`, `Retrieved_Gtid_Set` / `Executed_Gtid_Set`.
- **IO gecikmesi:** `Retrieved` kaynağın gerisinde. Ağ veya kaynak/replica disk sorunu.
- **SQL (apply) gecikmesi:** `Retrieved` güncel, `Executed` geride. Replica olayları yeterince hızlı uygulayamıyor. **En yaygın durum.**
- **Thread durmuş:** `Last_SQL_Error` içinde nedene bakın (örn. 1062 duplicate key, 1032 satır bulunamadı).
- **Tek büyük transaction** (toplu UPDATE/DELETE, büyük `LOAD DATA`): `SHOW PROCESSLIST` içinde SQL thread aynı olayda uzun süredir.
- **Primary key'i olmayan tablolar** (S29): `row` formatında her satır için tam tablo taraması yapılır, çok yavaştır.
- **Paralel uygulama kapalı:** tek thread, kaynakta çok thread yazıyor.
- Replica disk I/O doygunluğu veya replica'da ek yük (raporlama sorguları, yedek).
4. Müdahale / Response
STOP REPLICA SQL_THREAD;
SET GLOBAL replica_parallel_type = 'LOGICAL_CLOCK';
SET GLOBAL replica_parallel_workers = 8;
SET GLOBAL replica_preserve_commit_order = ON;
START REPLICA SQL_THREAD;(5.7: `slave_parallel_type`, `slave_parallel_workers`.)
SET GLOBAL sync_binlog = 0;
SET GLOBAL innodb_flush_log_at_trx_commit = 2;STOP REPLICA;
SET GTID_NEXT = '<uuid>:<n>';
BEGIN; COMMIT;
SET GTID_NEXT = 'AUTOMATIC';
START REPLICA;Atlamadan sonra `pt-table-checksum` ile tutarlılığı doğrulayın.
5. **Kalıcı çözüm:** Tüm tablolara primary key ekleyin; büyük toplu işlemleri küçük parçalara bölün (örn. 1000-5000 satırlık batch'ler); `binlog_transaction_dependency_tracking = WRITESET` (primary'de) paralelliği artırır.
5. Doğrulama / Verification
- `Seconds_Behind_Source` düşüyor ve 0'a yaklaşıyor, M15 normale döndü.
- `Replica_IO_Running` ve `Replica_SQL_Running` = `Yes`, `Last_*_Error` boş.
- Gecikme kapandıktan sonra gevşetilen ayarlar eski haline getirildi.
6. Geri Alma / Rollback
- Gevşetilen dayanıklılık ayarlarını eski haline alın: `sync_binlog = 1`, `innodb_flush_log_at_trx_commit = 1`.
- Paralel uygulama sorun çıkarırsa `replica_parallel_workers = 0` ile tek thread'e dönün.
- Atlanan GTID geri alınamaz; gerekirse replica'yı yeniden kurun.