Replication lag neyi bozar?
Replika gecikmesi teknik olarak kaynak veritabanındaki değişikliklerin replikaya geç ulaşmasıdır. Kullanıcı açısından ise daha basittir: az önce yaptığı işlem listede görünmez, rapor eski sayıyı gösterir veya arama sonucu tutarsızlaşır.
Okuma/yazma ayrımı kullanan sistemlerde bu etki daha belirgindir. Yazma primary üzerinde olur, okuma replikadan yapılır. Replika geride kalırsa sistem aynı anda hem doğru hem yanlış gibi davranabilir.
- Kullanıcı kendi yaptığı değişikliği hemen göremeyebilir.
- Raporlama sorguları iş kararını eski veriyle besleyebilir.
- Failover sırasında gerideki replika veri kaybı riski doğurabilir.
- Binlog büyümesi disk baskısı ve yedek/PITR maliyeti yaratabilir.
Önce replikanın gerçekten geride olup olmadığını görün
MySQL sürümüne göre SHOW SLAVE STATUS veya SHOW REPLICA STATUS çıktısı kullanılır. Yeni yazılarda REPLICA terimi tercih edilir; eski sistemlerde SLAVE alan adları hâlâ görülebilir.
Tek bir Seconds_Behind_Source değeri her şeyi anlatmaz. IO thread çalışıyor mu, SQL thread çalışıyor mu, son hata ne, relay log büyüyor mu, bunlar birlikte okunmalıdır.
Replika durumunu okuma
SHOW REPLICA STATUS\G -- Eski MySQL sürümlerinde: SHOW SLAVE STATUS\G
Gecikmenin yaygın nedenleri
Replika gecikmesi her zaman ağ sorunu değildir. Primary üzerinde büyük transaction çalışmış olabilir, replikada raporlama sorguları kaynak tüketiyor olabilir, disk yavaş kalmış olabilir veya DDL işlemi replika tarafında uzun sürüyordur.
Özellikle büyük tek transactionlar replikayı uzun süre bekletebilir. Uygulama küçük küçük yazıyor gibi görünse bile arka plandaki toplu iş tek transaction içinde milyonlarca satır değiştirebilir.
- Uzun transaction: replikada tek seferde uygulanması zaman alır.
- Ağ veya IO gecikmesi: relay log birikir.
- Ağır raporlama: replikanın SQL thread’i kaynak bulamaz.
- DDL veya indeks değişikliği: replikada da aynı etkiyi üretir.
- Binlog saklama süresi: disk ve kurtarma penceresiyle birlikte düşünülmelidir.
Toparlama planı acele failover değildir
Replika gerideyken failover yapmak çoğu zaman daha büyük sorun üretir. Önce gecikmenin artmaya devam edip etmediğini, replikadaki son uygulanan konumu ve kullanıcı etkisini anlamak gerekir.
Eğer replika yalnızca raporlama yüzünden yoruluyorsa raporlama trafiğini kısmak yeterli olabilir. Eğer primary üzerinde büyük yazım devam ediyorsa önce o işlemin bitmesi beklenebilir. Körlemesine yeniden başlatma, bazı durumlarda yalnızca teşhis kanıtını kaybettirir.
Olay notu için replika kontrol şablonu
Başlangıç zamanı: Etkilenen replika: Seconds_Behind_Source: IO thread: SQL thread: Son hata: Primary üzerinde uzun transaction var mı: Replikada ağır rapor sorgusu var mı: Failover uygun mu: Bir sonraki kontrol zamanı: