VPN kəsişindən sonra MySQL replikasiyası: əvvəlcə hər iki mərhələni oxuyun

VPN düşəndə replikasiya monitorinqi qırmızıya çevrilir və ilk instinkt mövqeyi sıfırlamaqdır. Bu instinkt şəbəkə kəsilməsinin məlumat probleminə çevrilmə üsuludur. Düşmüş yol replikanın nə aldığı və ya nə tətbiq etdiyi barədə heç nə demir və bunlar iki vəziyyəti olan iki mərhələdir. Nəyisə dəyişməzdən əvvəl onları ayrıca oxuyun.

İki mərhələ, iki ayrı cavab

Adi asinxron replika iki iş görür. Qəbuledici mənbəyə qoşulur, hadisələri çəkir və onları yerli olaraq relay jurnalına yazır. Tətbiqedici həmin relay jurnalını oxuyur və hadisələri replika üzərində icra edir. Yol qırılanda qəbuledici dərhal dayanır, tətbiqedici isə artıq diskdə olan yığımı işləməyə davam edir. Beləliklə, bir kəsinti iki fərqli sual doğurur: əlaqə geri qayıdıb və yığılmış iş tətbiq olunubmu? Onlara bir sual kimi yanaşmaq iki vəziyyəti yanıldıcı bir cavabda ortalayır.

Qəbuledicinin bərpa olması yolun işlədiyini bildirir. Bu, tətbiqedicinin nə qədər geridə olduğu və ya əlaqə kəsilmişkən xəta ilə üzləşib-üzləşmədiyi barədə heç nə demir.

Kanala düzgün ifadə ilə baxın

MySQL 8.4-də SHOW REPLICA STATUS hər konfiqurasiya edilmiş kanal üçün bir sətir qaytarır, ona görə sadalanan ilk sətir yerinə nəzərdə tutduğunuz kanalın sətrini oxuyun. Replica_IO_Running qoşulmuş qəbuledicini qoşulan və ya dayanmış qəbuledicidən ayırır, Replica_SQL_Running isə tətbiqedicini təsvir edir. Xəta sütunlarını onların yanında oxuyun, çünki yenidən qoşulub dərhal uğursuz olan qəbuledici heç bir status bayrağının göstərməyəcəyi mesaj qoyur. Köhnə buraxılışlar fərqli sütun adlarından istifadə edir, ona görə köhnə resepti yalnız əmrləri adlandırmaqla tərcümə etməyin.

Mənbə kimliyini və konfiqurasiya edilmiş filtrləri də yoxlayın. Yanlış mənbəyə yönəldilmiş və ya düşündüyünüzdən daha dar filtrlənmiş replika sağlam görünür, halbuki gözlədiyinizdən başqa bir şeyi replikasiya edir.

Niyə sıfır gecikmə rəqəmi yalan danışa bilər

Gecikmə dəyəri son tətbiq edilmiş hadisənin vaxt möhürünü cari vaxtla müqayisə edir. Qəbuledici bir saat dayandıqda tətbiqedici yığımı işləyib aldığı şeyin sonuna çata bilər və o anda rəqəm sıfıra düşür, halbuki replika mənbədən bir saat geridədir. Metrik tətbiqedicinin növbəsini ölçür, replikanın aktuallığını yox.

Əvəzinə icra edilmiş tranzaksiyaları mənbənin mövcud saxladığı ilə müqayisə edin. Bu müqayisə dayanmış qəbulediciyə tab gətirir.

Bərpa pəncərəsini əslində saxlama müddəti müəyyən edir

Yetişmək üçün mənbənin replikanın ehtiyac duyduğu tranzaksiyaları hələ saxlaması tələb olunur. Onlar təmizləndikdən sonra replika onları çəkə bilməz və nə qədər yenidən qoşulma olsa da bunu dəyişmir.

GTID avtomatik mövqeləşdirmə ilə uğursuzluq açıqdır: replika mənbənin artıq saxlamadığı tarixçəni istəyir və davam etməkdən imtina edir. Onda seçimlər itkin hadisələri hələ saxlayan mənbədən almaq və ya ehtiyat nüsxədən yenidən qurub yetişməsinə imkan verməkdir. Boşluğu atlamaq yetişmək deyil və məlumatı səssizcə natamam qalan replika buraxır. Pəncərəni gözlənilən kəsinti müddətini mənbədəki binar jurnal saxlama müddəti və dəyişiklik sürəti ilə müqayisə edərək planlaşdırın, çünki bu üç rəqəm kəsintinin ümumiyyətlə bərpa oluna biləcəyini həll edir.

Göstəricinin rəngini deyil, yetişməni yoxlayın

Yolu bərpa edin, o cümlədən ad həllini və nəqliyyat təhlükəsizliyini, sonra mövcud kanalın öz siyasəti ilə yenidən qoşulub-qoşulmadığını izləyin. Müdaxilə etməzdən əvvəl ona müəyyən interval verin və həmin intervalın hər iki ucunda qəbul və tətbiq tərəqqisini qeyd edin. Yenidən başlayan kanal və aktual olan kanal fərqli tapıntılardır.

Tətbiqedicinin mənbənin cari mövqeyinə çatdığını təsdiqləyin, sadəcə köhnə yığımın sonuna deyil. Tətbiqedicidə heç bir xətanın gözləmədiyini yoxlayın, çünki bir uğursuz hadisə tərəqqini dayandırır, qəbuledici isə qoşulmuş olduğunu bildirməyə davam edir. Sonra sübutları qeyd edin: kanal adı, hər iki mərhələnin vəziyyəti, icra olunmuş mövqe və vaxt. Yaşıl göstərici iddiadır; mövqe faktdır.