تكرار MySQL بعد انقطاع VPN: اقرأ المرحلتين أولًا
المسار المتقطع ليس معاملات مفقودة. اقرأ المستقبِل والمطبِّق كلًا على حدة، ثم تحقق مما لا يزال المصدر يحتفظ به.
تتحول مراقبة التكرار إلى الأحمر عندما يسقط VPN، والغريزة هي إعادة تعيين موضع. تلك الغريزة هي كيف يتحول انقطاع الشبكة إلى مشكلة بيانات. المسار الساقط لا يقول شيئًا عما تلقته النسخة المتماثلة أو طبّقته، وهما مرحلتان بحالتين. اقرأهما على حدة قبل تغيير أي شيء.
مرحلتان، إجابتان منفصلتان
النسخة المتماثلة غير المتزامنة التقليدية تؤدي وظيفتين. يتصل المستقبِل بالمصدر، ويسحب الأحداث، ويكتبها في سجل الترحيل محليًا. يقرأ المطبِّق سجل الترحيل ذلك وينفّذ الأحداث على النسخة المتماثلة. عندما ينقطع المسار، يتوقف المستقبِل فورًا بينما يواصل المطبِّق العمل على أي متراكم موجود بالفعل على القرص. لذا ينتج انقطاع واحد سؤالين مختلفين: هل عاد الاتصال، وهل طُبّق العمل المتراكم؟ التعامل معهما كسؤال واحد يخلط حالتين في إجابة مضللة.
تعافي المستقبِل يخبرك أن المسار قائم. لكنه لا يقول شيئًا عن مدى تأخر المطبِّق، ولا عمّا إذا واجه خطأ أثناء انقطاعه.
اقرأ القناة بالعبارة الصحيحة
في MySQL 8.4، يُرجع SHOW REPLICA STATUS صفًا واحدًا لكل قناة مُهيّأة، لذا اقرأ صف القناة التي تقصدها بدلًا من أول صف مدرج. يفصل Replica_IO_Running بين مستقبِل متصل وآخر يتصل أو متوقف، ويصف Replica_SQL_Running المطبِّق. اقرأ أعمدة الخطأ إلى جانبها، لأن مستقبِلًا يعيد الاتصال ويفشل فورًا يترك رسالة لن يُظهرها أي علم حالة. تستخدم الإصدارات الأقدم أسماء أعمدة مختلفة، فلا تترجم وصفة قديمة بمجرد إعادة تسمية الأوامر.
تحقق أيضًا من هوية المصدر وأي مرشّحات مُهيّأة. النسخة المتماثلة الموجَّهة إلى مصدر خاطئ، أو المرشَّحة أضيق مما تظن، تُبلّغ عن صحة بينما تكرّر شيئًا غير ما تتوقعه.
لماذا يمكن لرقم تأخّر صفري أن يكذب
تقارن قيمة التأخّر الطابع الزمني لآخر حدث مطبَّق بالوقت الحالي. عندما يكون المستقبِل متوقفًا منذ ساعة، يمكن للمطبِّق أن يعمل عبر المتراكم ويصل إلى نهاية ما تلقاه، وعندها يهبط الرقم إلى الصفر رغم أن النسخة المتماثلة متأخرة ساعة عن المصدر. يقيس المقياس طابور المطبِّق، لا حداثة النسخة المتماثلة.
قارن بدلًا من ذلك المعاملات المنفَّذة بما يتوفر لدى المصدر. تلك المقارنة تصمد أمام مستقبِل متوقف.
الاحتفاظ يحدد نافذة الاستعادة الحقيقية
يتطلب اللحاق أن يظل المصدر محتفظًا بالمعاملات التي تحتاجها النسخة المتماثلة. بمجرد إزالتها، لا تستطيع النسخة جلبها، ولا يغيّر أي قدر من إعادة الاتصال ذلك.
مع التموضع التلقائي GTID يكون الفشل صريحًا: تطلب النسخة المتماثلة تاريخًا لم يعد المصدر يحتفظ به وترفض المتابعة. الخيارات حينها هي الحصول على الأحداث المفقودة من مصدر لا يزال يملكها، أو إعادة البناء من نسخة احتياطية وتركها تلحق. تجاوز الفجوة ليس لحاقًا، ويترك نسخة متماثلة بياناتها ناقصة بهدوء. خطط النافذة بمقارنة مدة الانقطاع المتوقعة باحتفاظ السجل الثنائي على المصدر ومعدل التغيير، لأن تلك الأرقام الثلاثة تحدد ما إذا كان الانقطاع قابلًا للاستعادة أصلًا.
تحقق من اللحاق، لا من لون مؤشر
استعد المسار، بما في ذلك تحليل الأسماء وأمان النقل، ثم راقب ما إذا كانت القناة القائمة تعيد الاتصال وفق سياستها. امنحها فترة محددة قبل التدخل، وسجّل تقدّم الاستقبال والتطبيق عند طرفي تلك الفترة. قناة تعيد التشغيل وقناة محدَّثة هما نتيجتان مختلفتان.
أكّد أن المطبِّق وصل إلى موضع المصدر الحالي، لا مجرد نهاية المتراكم القديم. تحقق من عدم انتظار أي خطأ في المطبِّق، لأن حدثًا فاشلًا واحدًا يوقف التقدّم بينما يواصل المستقبِل الإبلاغ عن كونه متصلًا. ثم سجّل الأدلة: اسم القناة، وحالتا المرحلتين، والموضع المنفَّذ، والوقت. المؤشر الأخضر ادعاء؛ والموضع حقيقة.