Replika bozuldu / yeniden senkron gerek
Replika/standby ile primary arasındaki senkron bozuldu. Replikasyonun durup durmadığını, ne kadar geride olduğunu ve pozisyon/GTID kopması olup olmadığını belirleyip; hata atlama, bekleme ya da yeniden kurulum (reseed) arasında doğru yola giriyoruz. Split-brain uyarısı dahildir.
Replikasyonun genel durumu ne?
Önce replikasyon sağlığını oku: uygulama thread'ler çalışıyor mu, gecikme (lag) ne kadar, bir hata var mı? Ayrıca iki düğümün birden yazma kabul etmediğini (split-brain) doğrula.
SHOW REPLICA STATUS\G
-- Bak: Replica_IO_Running, Replica_SQL_Running, Seconds_Behind_Source, Last_Error, Retrieved/Executed_Gtid_Set- Replikasyon durmuş / hata veriyor
- Çalışıyor ama çok geride (lag büyük)
- GTID/pozisyon kopmuş, tutarsız — yeniden kur
- İki düğüm de primary gibi yazıyor (split-brain şüphesi)
Hata onarılabilir mi yoksa yeniden kurulum mu gerek?
Uygulama hatasını incele. Bazı hatalar (duplicate key, eksik satır) tek olayı güvenle atlayarak çözülebilir; ancak veri tutarsızlığı/bozulma varsa tek doğru yol replikayı yeniden kurmaktır.
SHOW REPLICA STATUS\G
-- Bak: Last_SQL_Errno, Last_SQL_Error, Last_IO_Errno, Last_IO_Error- Tek/az sayıda uygulanabilir hata (atlanabilir)
- Onarılamaz tutarsızlık / bozulma
Gecikme geçici mi kalıcı mı?
Lag'in zaman içindeki eğilimine bak. Geçici bir yük patlamasından sonra kapanıyor (yakalıyor) mu, yoksa sürekli açılıyor ve replika primary'yi asla yakalayamıyor mu?
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source değerini birkaç kez ölç: azalıyor mu artıyor mu?- Geçici yük artışı; lag kapanıyor
- Sürekli açılıyor; yakalayamıyor
Çözüm: Uygulanabilir hatayı dikkatle atla
Replikasyon tek bir uygulama hatasında (ör. duplicate key) durmuşsa ve verinin gerçekten tutarlı olduğundan eminsen, o olayı atlayarak akışı sürdürebilirsin. Bu son çare niteliğindedir; kör atlama sessiz veri sapması yaratır.
Çözüm: Replikayı yeniden kur (reseed / rebuild)
Pozisyon/GTID kopmuş, veri sapmış ya da onarılamaz hata varsa tek güvenilir yol replikayı primary'den alınan taze bir kopyayla yeniden kurmaktır.
Kök neden: Geçici yük artışı (lag kapanıyor)
Replikasyon sağlıklı; primary'deki geçici bir yazma patlaması veya ağ dalgalanması nedeniyle lag açıldı ama replika yakalıyor.
Kök neden: Replika primary'yi yakalayamıyor
Uygulama (apply/redo) tarafı, primary'nin ürettiği değişiklik hızına yetişemiyor; lag sürekli büyüyor. Genelde tek thread'li apply, yavaş replika donanımı ya da ağ darboğazı.
UYARI: Split-brain (iki primary) — veri kaybı riski
İki düğüm de primary rolde yazma kabul ediyorsa, her iki tarafta çakışan değişiklikler oluşur; bu veri kaybına yol açabilecek en tehlikeli durumdur. Önce yazmayı tek düğüme indirgemek şarttır.