MySQL InnoDB Cluster günlük işletim ve arıza senaryoları (MySQL Shell 8.4)

Kurulum değil: zaten çalışan bir InnoDB Cluster'ın (Group Replication + MySQL Router, MySQL Shell AdminAPI ile kurulmuş) günlük işletimi ve arıza kurtarması için senaryo bazlı runbook. Bir senaryo kartı seçin: sağlık kontrolü, üye ekleme (clone / incremental) ve çıkarma (force dahil), düşen üyeyi geri katma, tüm cluster kapandıktan sonra yeniden başlatma (rebootClusterFromCompleteOutage), çoğunluk kaybında forceQuorumUsingPartitionOf, planlı primary değişimi, Router ekleme / yeniden bootstrap, cluster seçenekleri (consistency, expelTimeout, memberWeight, autoRejoinTries, exitStateAction) ve metadata için rescan(). Her senaryo teşhis → güvenlik ağı → uygulama → doğrulama → sonrası düzenindedir. Cluster'ı ilk kez kuracaksanız InnoDB Cluster kurulum rehberini, klasik source–replica replikasyonu için replikasyon işletim rehberini, 8.0 → 8.4 geçişi için upgrade rehberini açın.

Yapı: 3–9 MySQL node'u (single-primary) + MySQL Router

Senaryolar

• Cluster durumu ve sağlık kontrolü (her şey yolunda mı?) — Salt-okur: cluster.status({extended: 1}), üyelerin rolü/durumu/sürümü, uygulama kuyrukları, Router listesi ve error log; hiçbir şey değişmez, kesinti yok. Emin değilseniz ya da bir alarm geldiyse buradan başlayın; son adım sizi doğru senaryoya yönlendirir.
• Yeni üye ekle (addInstance: clone / incremental) — Cluster'a yeni bir MySQL node'u eklemek, tolerans artırmak (3 → 5) ya da çıkarılmış bir node'u geri almak istiyorsunuz. Cluster yazmaya açık kalır; clone sırasında donor'da disk/ağ yükü oluşur, yeni node yeniden başlar.
• Üyeyi çıkar (removeInstance, gerekirse force) — Bir node'u kalıcı olarak cluster'dan çıkarmak istiyorsunuz (donanım iadesi, küçültme) ya da node kayıp ve metadata'dan silinmesi gerekiyor (force). Secondary çıkarılırken kesinti olmaz; primary çıkarılırsa birkaç saniyelik yazma kesintisi olur.
• Düşen üyeyi geri kat (MISSING / ERROR / OFFLINE) — Bir üye yeniden başladı, ağ kesintisi yaşadı ya da gruptan atıldı (expelled); çoğunluk çalışıyor ve uygulama yazabiliyor. rejoinInstance ile üye eksiklerini alıp geri döner; cluster'da kesinti olmaz.
• Tüm cluster kapandı: yeniden başlat (rebootClusterFromCompleteOutage) — Elektrik / veri merkezi / hipervizör kesintisi gibi bir nedenle tüm node'lar kapandı ve açıldı; Group Replication hiçbir üyede çalışmıyor, uygulama yazamıyor (kesinti sürüyor). Cluster en güncel üyeden yeniden başlatılır.
• Çoğunluk kaybı (NO_QUORUM): kalan üyelerle zorla quorum kur — Üyelerin çoğu aynı anda kayboldu (ör. 3'te 2), kalanlar NO_QUORUM ile yazmayı durdurdu (yazmalar askıda kalır). Kaybolanların gerçekten kapalı olduğundan eminseniz kalan bölümle cluster yeniden çalıştırılır. Yanlış kullanım split-brain yaratır; bir üye kaybı (çoğunluk duruyor) bu senaryo değildir.
• Planlı primary değişimi (setPrimaryInstance) — Bakım (OS patch, donanım), yük dengesi ya da DR provası için primary rolünü belirli bir secondary'ye planlı olarak devretmek istiyorsunuz. Yazmalar birkaç saniye bekler, açık transaction'lar bitirilir; Router yeni primary'ye kendiliğinden yönlendirir.
• Router ekle ya da yeniden bootstrap et — Yeni bir uygulama sunucusuna Router kurmak, Router'ı (sürüm yükseltme, yeniden kurulan cluster, routerErrors uyarısı) yeniden bootstrap etmek ya da eski Router kayıtlarını temizlemek istiyorsunuz. Yeniden bootstrap sırasında o Router'a bağlı uygulama bağlantıları kısa süre kopar.
• Cluster seçeneklerini değiştir (consistency, expelTimeout, memberWeight…) — Failover tutarlılığı, ağ dalgalanmasında üye atılma süresi, failover önceliği, otomatik yeniden katılma ya da hata durumunda üyenin davranışını ayarlamak istiyorsunuz. Cluster çalışırken değiştirilir, restart gerekmez; consistency yeni oturumlarda etkili olur.
• Metadata'yı gerçek grupla eşitle (rescan) — cluster.status() metadata'da olmayan bir üyeden ya da artık grupta olmayan eski bir kayıttan söz ediyor (elle START GROUP_REPLICATION yapılmış, eski üye silinmemiş, sunucu yeniden kurulmuş). Kesinti yok; yalnız metadata güncellenir.

Başlamadan önce

• İşlem yapılacak node'larda MySQL Shell … ve MySQL … kurulu; cluster InnoDB Cluster kurulum rehberiyle ya da eşdeğer biçimde AdminAPI ile kurulmuş (metadata var). İşletim sistemi root'u yerel mysql ile parolasız bağlanabiliyor. Formdaki cluster adını dba.getCluster().getName(), üye adreslerini cluster.status() topolojisindeki ip:port satırlarından alın.
• … hesabının parolası biliniyor (her node'da aynı). MySQL Shell her bağlantıda parolayı sorar; --save-passwords=never ile kaydetmez.
• Node'lar birbirine MySQL portlarından (……:……, ……) ve Group Replication iletişim portlarından erişebiliyor.
• Yeni node'da MySQL … cluster üyeleriyle aynı alt sürümde kurulu (clone şartı), GTID açık, server_id diğer node'lardan farklı ve kurulum rehberindeki Group Replication ayarları my.cnf'te; firewall/SELinux portları açık.
• Router sunucusu node'lara MySQL portundan erişebiliyor… ve repo.mysql.com'a çıkabiliyor….
• Değişiklik için onay, bakım penceresi (gerekiyorsa) ve uygulama ekibiyle iletişim hazır.

Rehberin aşamaları

• Durum: cluster, üyeler ve Router (salt-okur) — Ayrıntılı cluster durumunu al ve kaydet · Üyeleri ve kuyrukları SQL ile kontrol et · Group Replication hata kayıtlarını tara · Router üzerinden RW/RO yönlendirmesini kontrol et · Sonucu yorumla ve doğru senaryoyu seç
• 1. Teşhis: yeni node ve cluster hazır mı? — Yeni node'un sürümünü ve kimliğini kontrol et · Cluster durumunu ve üye sürümlerini kontrol et
• 2. Güvenlik ağı — Mevcut topolojiyi kaydet
• 3. Uygulama: üyeyi ekle — Yeni node'u yapılandır ve yönetici hesabını oluştur · Yeni node'un uygunluğunu cluster tarafından denetle · Node'u cluster'a ekle (…)
• 4. Doğrulama — Yeni üyenin ONLINE olduğunu doğrula
• 5. Sonrası — Router, izleme ve envanteri güncelle
• 1. Teşhis: üyeyi çıkarmak güvenli mi? — Hedef üyenin durumunu ve kalan toleransı göster
• 2. Güvenlik ağı — Mevcut topolojiyi kaydet
• 3. Uygulama: üyeyi çıkar — Üyeyi cluster'dan çıkar… (force)…
• Force ile çıkarılan node geri gelirse — Geri gelen node'da Group Replication'ı durdur ve temizle
• 4. Doğrulama — Kalan üyeleri doğrula
• 5. Sonrası — Tek sayı, Router ve izleme
• 1. Teşhis: üye neden düştü, geri katılabilir mi? — Cluster'ın gözünden hedef üyenin durumu · Hedef node'da MySQL'in ve Group Replication'ın durumunu göster · Errant transaction kontrolü (hedefte olup cluster'da olmayan)
• 2. Güvenlik ağı — Mevcut durumu kaydet
• 3. Uygulama: üyeyi geri kat — Üyeyi rejoinInstance ile geri kat
• 4. Doğrulama — Üyenin ONLINE olduğunu doğrula
• 5. Sonrası — Kök neden ve otomatik geri katılma
• 1. Teşhis: tüm cluster gerçekten kapalı mı, en güncel üye hangisi? — Her node'da MySQL'i başlat ve Group Replication durumunu göster · Shell'e en güncel üyeyi sor (dryRun)
• 2. Güvenlik ağı — Tüm node'ların GTID kümesini kaydet
• 3. Uygulama: cluster'ı en güncel üyeden başlat — Cluster'ı yeniden başlat
• 4. Doğrulama — Tüm üyelerin ONLINE olduğunu doğrula
• 5. Sonrası — Router, uygulama ve kök neden
• 1. Teşhis: quorum gerçekten kayıp mı? — Ayakta kalan node'dan cluster durumunu göster
• 2. Güvenlik ağı: kaybolan üyeleri yalıt — Kaybolan node'ların kapalı olduğundan emin ol (fencing) · Kalan bölümün durumunu kaydet
• 3. Uygulama: zorla quorum kur — Kalan bölümle quorum kur
• 4. Doğrulama ve kaybolan üyeleri geri alma — Yazmanın açıldığını doğrula · Kaybolan üyeleri geri kat (…)
• 5. Sonrası — Topolojiyi gözden geçir
• 1. Teşhis: hedef primary olmaya uygun mu? — Üyelerin durumunu ve sürümlerini kontrol et
• 2. Güvenlik ağı — Mevcut durumu kaydet
• 3. Uygulama: primary'yi değiştir — Primary rolünü …'e devret