VPN kopmasından sonra MySQL replikasyonu: önce iki aşamayı okuyun

VPN düştüğünde replikasyon izleme kırmızıya döner ve ilk dürtü bir konumu sıfırlamaktır. Tam da bu dürtü, bir ağ kesintisini veri sorununa dönüştürür. Düşen bir yol, replikanın ne aldığı veya ne uyguladığı hakkında hiçbir şey söylemez ve bunlar iki durumlu iki aşamadır. Herhangi bir şeyi değiştirmeden önce ikisini ayrı ayrı okuyun.

İki aşama, iki ayrı yanıt

Geleneksel bir eşzamansız replika iki iş yapar. Alıcı kaynağa bağlanır, olayları çeker ve bunları yerel olarak aktarma günlüğüne yazar. Uygulayıcı bu günlüğü okur ve olayları replika üzerinde yürütür. Yol koptuğunda alıcı hemen durur, uygulayıcı ise diskte zaten bulunan birikmiş işi işlemeye devam eder. Dolayısıyla tek bir kesinti iki farklı soru üretir: bağlantı geri geldi mi ve biriken iş uygulandı mı? Bunları tek soru olarak ele almak, iki durumu yanıltıcı bir yanıtta ortalar.

Alıcının toparlanması yolun ayakta olduğunu söyler. Uygulayıcının ne kadar geride olduğunu ya da bağlantı kesikken bir hatayla karşılaşıp karşılaşmadığını söylemez.

Kanalı doğru ifadeyle okuyun

MySQL 8.4'te SHOW REPLICA STATUS yapılandırılmış her kanal için bir satır döndürür, bu yüzden listedeki ilk satır yerine kastettiğiniz kanalın satırını okuyun. Replica_IO_Running bağlı bir alıcıyı bağlanan veya durmuş olandan ayırır, Replica_SQL_Running ise uygulayıcıyı tanımlar. Yanlarındaki hata sütunlarını da okuyun, çünkü yeniden bağlanıp hemen başarısız olan bir alıcı hiçbir durum bayrağının göstermeyeceği bir mesaj bırakır. Eski sürümler başka sütun adları kullanır, bu yüzden eski bir tarifi yalnızca komutları yeniden adlandırarak çevirmeyin.

Kaynağın kimliğini ve yapılandırılmış filtreleri de kontrol edin. Yanlış kaynağa yönelen ya da düşündüğünüzden daha dar filtrelenen bir replika, beklediğinizden farklı bir şeyi replike ederken sağlıklı olduğunu bildirir.

Sıfır gecikme neden yalan söyleyebilir

Gecikme değeri, son uygulanan olayın zaman damgasını geçerli zamanla karşılaştırır. Alıcı bir saat durmuşsa, uygulayıcı birikmiş işi bitirip aldığının sonuna ulaşabilir ve o anda replika kaynağın bir saat gerisinde olsa bile sayı sıfıra düşer. Bu ölçüt uygulayıcının kuyruğunu ölçer, replikanın güncelliğini değil.

Bunun yerine yürütülen işlemleri kaynağın sunduğuyla karşılaştırın. Bu karşılaştırma tıkanmış bir alıcıya dayanır.

Gerçek kurtarma penceresini saklama belirler

Yetişmek için kaynağın replikanın ihtiyaç duyduğu işlemleri hâlâ tutması gerekir. Bunlar temizlendiğinde replika onları getiremez ve ne kadar yeniden bağlanılırsa bağlanılsın bu değişmez.

GTID otomatik konumlandırmada hata açıktır: replika kaynağın artık tutmadığı bir geçmişi ister ve devam etmeyi reddeder. O zaman seçenekler, eksik olayları hâlâ elinde bulunduran bir kaynaktan almak ya da bir yedekten yeniden kurup yetişmesine izin vermektir. Boşluğu atlamak yetişmek değildir ve verisi sessizce eksik kalan bir replika bırakır. Pencereyi, beklenen kesinti süresini kaynaktaki ikili günlük saklaması ve değişim hızıyla karşılaştırarak planlayın, çünkü o üç sayı bir kesintinin kurtarılabilir olup olmadığına karar verir.

Gösterge rengini değil, yetişmeyi doğrulayın

Yolu geri getirin; ad çözümlemesi ve taşıma güvenliği buna dahildir, sonra mevcut kanalın kendi politikasına göre yeniden bağlanıp bağlanmadığını izleyin. Müdahale etmeden önce ona belirli bir aralık verin ve o aralığın iki ucunda alma ve uygulama ilerlemesini kaydedin. Yeniden başlayan bir kanal ile güncel bir kanal farklı bulgulardır.

Uygulayıcının kaynağın güncel konumuna ulaştığını doğrulayın, yalnızca eski birikmiş işin sonuna değil. Uygulayıcıda bir hatanın beklemediğini kontrol edin, çünkü tek bir başarısız olay ilerlemeyi durdururken alıcı bağlı olduğunu bildirmeye devam eder. Ardından kanıtları kaydedin: kanal adı, iki aşamanın durumu, yürütülen konum ve saat. Yeşil bir gösterge bir iddiadır; konum bir olgudur.