MySQL replikasyonu günlük işletim ve arıza senaryoları (8.0 / 8.4)

Kurulu bir source + replica topolojisinin (async / semi-sync, GTID ya da binlog konumu) günlük işletimi ve arıza kurtarma runbook'u: sağlık ve gecikme kontrolü, planlı switchover, failover, eski source'u geri katma, replica'yı yeniden kurma (clone / XtraBackup / mysqldump), errant GTID, 1062/1032 hataları, gecikmeli replica ile veri kurtarma, replica taşıma ve binlog temizliği. Her senaryo teşhis → güvenlik ağı → uygulama → doğrulama → sonrası düzenindedir. Kurulum rehberi değildir: replikasyonu ilk kez kurmak için «MySQL GTID replikasyonu», InnoDB Cluster (Group Replication) için «InnoDB Cluster işletim» rehberini açın.

Yapı: 1 source + 1..5 replica (async / semi-sync)

Senaryolar

• Durum ve gecikme kontrolü (replikasyon sağlıklı mı?) — Salt-okur: IO/SQL thread'leri, son hatalar, gerçek gecikme, semi-sync durumu ve errant GTID kontrolü; hiçbir şey değişmez, kesinti yok. Ne yapacağınızdan emin değilseniz buradan başlayın: son adım çıktıya göre doğru senaryoya yönlendirir.
• Planlı switchover (source rolünü bir replica'ya devret) — Source ve replica'lar sağlıklı; bakım, donanım değişimi ya da upgrade için source rolünü planlı olarak bir replica'ya devrediyorsunuz. Yazmalar birkaç dakika durur, veri kaybı olmaz; geri dönüş aynı senaryonun tersidir.
• Source kayıp: en ileri replica'ya failover — Source çöktü ya da erişilemiyor ve kısa sürede dönmeyecek (replica'larda IO thread Connecting, 2003/2013). En ileri replica yeni source yapılır, diğerleri ona bağlanır. Yazmalar yeni source açılana kadar kesiktir; async'te source'un son birkaç transaction'ı kaybolabilir.
• Failover sonrası eski source'u replica olarak geri kat — Failover yapıldı, eski source sunucusu geri geldi. Önce yazmaya kapatılır ve binlog'ları kopyalanır, errant transaction kontrol edilir; temizse doğrudan replica olur, değilse yeni source'tan yeniden kurulur. Yeni source'ta kesinti yok.
• Replica'yı sıfırdan yeniden kur (clone / XtraBackup / mysqldump) — Replica'nın ihtiyaç duyduğu binlog'lar source'ta silindi (1236), verisi source'tan ayrıştı, 1062/1032 tekrar tekrar geliyor ya da replica'nın diski kayboldu. Replica'nın tüm verisi source'un kopyasıyla değiştirilir; source açık kalır, hedef replica bu süre boyunca kullanılamaz.
• Errant GTID: replica'da source'ta olmayan transaction var — Replica'ya doğrudan yazılmış (super_read_only kapalıyken) ya da eski bir source'tan kalmış transaction'lar var; failover'da bu transaction'lar diğer replica'lara yayılır ya da 1236 ile replikasyonu durdurur. Çözüm: boş transaction, source'a uygulama ya da yeniden kurma. Kesinti yok.
• Replikasyon durdu: 1062 Duplicate entry / 1032 Can't find record — SQL thread bir veri hatasıyla durdu (Replica_SQL_Running: No, Last_SQL_Errno 1062/1032/1146/1677…). Önce satır source'taki hâline getirilir; olmazsa son çare olarak tek transaction atlanır. Yalnız bu replica etkilenir: geride kalır, ondan okuyan uygulama eski veri görür.
• Gecikmeli replica (SOURCE_DELAY): kur ya da silinen veriyi kurtar — Bir replica'yı bilinçli olarak N saniye geride tutmak (gecikme ayarla / kaldır) ya da yanlışlıkla silinen/değiştirilen veriyi (DROP, WHERE'siz DELETE/UPDATE) henüz uygulanmadan gecikmeli replica'dan geri almak istiyorsunuz. Source açık kalır.
• Replica'yı farklı bir source'a taşı (zincir / yeniden bağlama) — Bir replica'yı başka bir replica'nın altına (zincir / ara replica) ya da source'a geri bağlamak istiyorsunuz; veri kopyalanmaz, yalnız bağlantı değişir. Taşınan replica birkaç saniye durur.
• Binlog temizliği ve saklama süresi (disk doluyor) — Binlog'lar diski dolduruyor ya da saklama süresini ayarlamak istiyorsunuz; replica'ların ve PITR'nin hâlâ ihtiyaç duyduğu dosyalar silinmeden temizlenir. Kesinti yok.

Başlamadan önce

• Tüm sunucularda MySQL …… (8.0.26 ve sonrası)… aynı alt sürümde…, gtid_mode = ON ve enforce_gtid_consistency = ON…, binlog açık…; işletim sistemi root'u mysql ile parolasız bağlanabiliyor (auth_socket ya da ~/.mylogin.cnf). Topoloji replikasyon kurulum rehberiyle ya da eşdeğer biçimde kurulmuş.
• Rollerin girdilerle aynı olduğu doğrulandı: … (…)… kaybedilen eski source… şu anki source (read_only = 0, replica tanımı yok)…, listedeki sunucular replica.… Failover'da source yapılan: … (…).…
• … hesabının parolası biliniyor. Hesap her sunucunun IP'si için var ('…'@'<ip>', REQUIRE SSL); adımlar diğer sunuculardaki GTID kümesi gibi değerleri bu hesapla okur ve rol değişiminde replikasyon bağlantısında kullanır. Parolada ', " ve \ yok.
• Sunucular birbirine … portundan erişebiliyor.
• Tüm sunucularda iki semi-sync eklentisi de yüklü ve ACTIVE: rpl_semi_sync_source (semisync_source.so) ve rpl_semi_sync_replica (semisync_replica.so); rol değişiminde her sunucunun iki tarafı da açılıp kapatılır. Eski adlı rpl_semi_sync_master / rpl_semi_sync_slave (8.0.26 öncesi, 8.4'te kullanımdan kalkmış) yüklüyse adımlardaki rpl_semi_sync_source_enabled / rpl_semi_sync_replica_enabled değişkenleri yoktur: önce eski eklentiyi UNINSTALL PLUGIN ile kaldırıp yenisini kurun (aynı sunucuda ikisi birden yüklenemez; INSTALL PLUGIN salt-okur sunucuda reddedilir, super_read_only geçici kapatılır).
• Yeni source / ara sunucu olacak replica'da log_bin = ON ve log_replica_updates = ON (8.x'te varsayılan); aksi hâlde onun binlog'u source'tan gelen transaction'ları içermez ve diğer replica'lar ona bağlanamaz.
• Dosya aktarımı için ilgili sunucular arasında root SSH (anahtarla) erişimi var…: … → ……. Yoksa dosyaları kurumun onaylı yöntemiyle taşıyın; adımlar dosya yollarını gösterir.
• Donor (…) ve hedefte (…) MySQL ile aynı ana sürümde Percona XtraBackup kurulu; donor'da yedek hesabı bkpuser (auth_socket) var — XtraBackup rehberinin ilk iki aşaması.
• Değişiklik için onay ve iletişim kanalı hazır (uygulama ekibi, bakım penceresi). Rol değişiminde uygulamanın yazma adresi (VIP, DNS, ProxySQL / HAProxy / Router) kim tarafından ve nasıl değiştirileceği biliniyor.

Rehberin aşamaları

• Durum: source, replica'lar ve gecikme (salt-okur) — Source'un rolünü, binlog konumunu ve bağlı replica'ları göster · Replica'ların thread durumunu, hatalarını ve gecikmesini göster · Gerçek gecikmeyi ve uygulama kuyruğunu performance_schema'dan ölç · Errant GTID kontrolü (replica'da source'ta olmayan transaction var mı?) · Sonucu yorumla ve doğru senaryoyu seç
• 1. Teşhis: switchover'a hazır mı? — Source'u ve bağlı replica'ları kontrol et · Aday replica'nın uygunluğunu doğrula · Tüm replica'ların sağlıklı olduğunu kontrol et
• 2. Güvenlik ağı — Tüm sunucularda mevcut durumu kaydet
• 3. Uygulama: rolü devret — Uygulamanın yazmalarını durdur · Source'u yazmaya kapat ve son konumu al · Replica'ların source'a yetişmesini bekle · Adayı source yap (promote) · Eski source'u yeni source'un replica'sı yap · Diğer replica'ları yeni source'a bağla (…) …
• 4. Doğrulama — Yeni source'ta test yazması yap · Tüm sunucularda replikasyonu ve test satırını kontrol et
• 5. Sonrası — Test veritabanını sil ve işletimi güncelle
• 1. Teşhis: source gerçekten kayıp mı, hangi replica en ileri? — Source'a erişimi son kez dene (aday replica'dan) · Eski source'u ayır (fencing) · Her replica'da relay log'daki transaction'ların uygulanmasını bekle · En ileri replica'yı belirle · En ileri replica'yı belirle (konum tabanlı)
• 2. Güvenlik ağı — Replica'larda mevcut durumu kaydet
• 3. Uygulama: failover — Adayı source yap (promote) · Diğer replica'ları yeni source'a bağla (…) · Yeni source'ta yazmaları aç · Uygulamayı yeni source'a yönlendir
• 4. Doğrulama — Yeni source'ta test yazması yap · Replica'larda replikasyonu ve test satırını kontrol et
• 5. Sonrası — Kayıp transaction'ları, yedeği ve eski source'u planla
• 1. Teşhis: eski source temiz mi? — Eski source'un durumunu göster · Errant transaction'ları bul (yeni source ile karşılaştır) · Konum tabanlıda geri katma kararı
• 2. Güvenlik ağı — Eski source'u hemen yazmaya kapat ve durumunu kaydet · Errant transaction'ları ayrı dosyaya çıkar
• 3. Uygulama: replica olarak bağla — Eski source'u yeni source'a bağla
• 4. Doğrulama — Eski source'un replica olarak çalıştığını doğrula
• 5. Sonrası — Topolojiyi ve eski source'un geleceğini planla
• 1. Teşhis: errant küme nedir? — Errant GTID kümesini hesapla
• 2. Güvenlik ağı: errant transaction'ların içeriğini kaydet — Errant transaction'ları binlog'dan çöz ve kaydet
• 3. Uygulama: source'a boş transaction enjekte et — Errant GTID'leri source'ta boş transaction olarak çalıştır
• 3. Uygulama: errant transaction'ları source'a uygula — Errant transaction'ları dosyaya çıkar ve source'a kopyala · Transaction'ları source'a uygula
• 4. Doğrulama — Errant kümenin kalmadığını doğrula
• 5. Sonrası: tekrarını önle — Kök nedeni bul ve replica'ları koru
• 1. Teşhis: hangi transaction, hangi satır? — Hatayı ve hatalı transaction'ı göster · Hatalı transaction'ın satırlarını relay log'dan çöz · Satırı source'ta ve replica'da karşılaştır
• 2. Güvenlik ağı — Replica durumunu ve tablonun mevcut hâlini kaydet
• 3. Uygulama: replica'daki satırı düzelt — Düzeltme SQL'ini hazırla · Düzeltmeyi binlog'a yazmadan uygula ve replikasyonu başlat
• 3. Uygulama: hatalı transaction'ı atla (son çare) — Yalnız hatalı transaction'ı atla
• 4. Doğrulama — Satırı ve tablonun özetini iki tarafta karşılaştır
• 5. Sonrası — Kök nedeni bul
• 1. Teşhis — Replica'nın mevcut gecikme ayarını göster
• 2. Güvenlik ağı — Replica durumunu kaydet