Orchestrator لـ MySQL: لماذا لا يمكن بناء مشروع آمن من الفشل بدونه

بدأ أي مشروع كبير مع زوج من الخوادم. أولاً ، كان هناك خادم DB واحد ، ثم تمت إضافة العبيد إليه لتوسيع نطاق القراءة. وهنا توقف! سيد واحد ، ولكن العديد من العبيد. إذا غادر أحد العبيد ، فسيكون كل شيء على ما يرام ، ولكن إذا غادر السيد ، فسيكون الأمر سيئًا: وقت التوقف ، يرفع المسؤولون في الصابون الخادم. ماذا أفعل؟ حجز السيد. لقد كتب زميلي بافيل بالفعل مقالة حول هذا الموضوع ، ولن أكررها. بدلاً من ذلك ، سأخبرك لماذا تحتاج بالتأكيد إلى Orchestrator لـ MySQL!

لنبدأ بالسؤال الرئيسي: "كيف سنحول الرمز إلى جهاز جديد عندما يغادر المعالج؟"

• أحب المخطط مع VIP (Virtual IP) أكثر من غيرها ، سنتحدث عنه أدناه. إنها الأبسط والأكثر وضوحًا ، على الرغم من وجود قيود واضحة عليها: يجب أن يكون السيد ، الذي سنحفظه ، في الجزء L2 مع جهاز جديد ، أي يمكنك نسيان العاصمة الثانية. وبطريقة جيدة ، إذا اتبعت القاعدة القائلة بأن L2 الكبير شرير ، لأن L2 على الرف فقط ، وبين الرفوف L3 ، ومثل هذا المخطط له المزيد من القيود.
• يمكنك تسجيل اسم DNS في الشفرة وحلها من خلال / etc / hosts. في الواقع ، لن يكون هناك قرار. الاستفادة من المخطط: لا توجد خاصية تقييد للطريقة الأولى ، أي يمكنك أيضًا تنظيم وحدات تحكم متقاطعة. ولكن بعد ذلك يطرح السؤال الواضح ، مدى السرعة من خلال Puppet-Ansible يمكننا تقديم التغيير إلى / etc / hosts.
• يمكنك تغيير الطريقة الثانية قليلاً: في جميع خوادم الويب ، نضع التخزين المؤقت لنظام أسماء النطاقات ، والذي من خلاله سيتم نقل الرمز إلى قاعدة البيانات الرئيسية. يمكنك تسجيل TTL 60 لإدخال DNS هذا. يبدو أن الطريقة جيدة مع التنفيذ السليم.
• مخطط مع اكتشاف الخدمة ، يتضمن استخدام القنصل وغيرها.
• خيار مثير للاهتمام مع ProxySQL . من الضروري لف كل حركة المرور إلى MySQL من خلال ProxySQL ، يمكن لـ ProxySQL تحديد الشخص الرئيسي الآن. بالمناسبة، عن واحد من الخيارات لاستخدام هذا المنتج يمكن العثور عليها في بلدي المادة .

قام مؤلف Orchestrator ، الذي يعمل في Github ، أولاً بتنفيذ المخطط الأول مع VIP ، ثم أعاد تصميمه إلى مخطط مع القنصل.

مخطط البنية التحتية النموذجية:

سأصف على الفور المواقف الواضحة للنظر فيها:

• VIP- . : , , Orchestrator failover ; , VIP . .
• . ifdown, — ifup vip. , failover , splitbrain.
• , Orchestrator , VIP / , VIP, arping , VIP .
• يجب أن يكون لدى جميع العبيد read_only = 1 ، وبمجرد أن تقوم بترقية العبد إلى السيد ، يجب أن يكون read_only = 0.
• لا تنس أن أي عبد اخترناه لهذا يمكن أن يصبح سيدًا (لدى Orchestrator آلية كاملة للتفضيل ، والتي ينبغي اعتبار العبد كمرشح لسيد جديد في المقام الأول ، أي واحد في الثانية ، وأي عبد لا ينبغي اختياره على الإطلاق تحت أي ظرف من الظروف رئيس). إذا أصبح العبد سيدًا ، فسيظل حمل العبد عليه وستتم إضافة الحمل الرئيسي ، ويجب أخذ ذلك في الاعتبار.

لماذا تحتاج إلى Orchestrator بالتأكيد إذا لم يكن لديك واحد؟

• لدى Orchestrator واجهة رسومية سهلة الاستخدام للغاية تعرض الهيكل بأكمله (انظر الصورة أدناه).
• يمكن لـ Orchestrator تتبع العبيد وراءهم وحيث يتم نسخ النسخ المتماثل بشكل عام (لدينا نصوص لإرسال الرسائل القصيرة إلى Orchestrator).
• يخبرك Orchestrator بالشرائح التي بها خطأ خاطئ GTID.

واجهة Orchestrator:

ما هو خطأ GTID؟

هناك متطلبان أساسيان لكي يعمل Orchestrator:

• من الضروري تمكين pseudo GTID على جميع الأجهزة في مجموعة MySQL ، لدينا GTID ممكّن.
• من الضروري أن يكون هناك نوع واحد من binlogs في كل مكان. كان لدينا مثل هذا التكوين الذي كان فيه الصف على السيد وعلى معظم العبيد ، وظل الوضع المختلط تاريخيًا على اثنين. ونتيجة لذلك ، لم يرغب Orchestrator ببساطة في ربط هؤلاء العبيد بالسيد الجديد.

تذكر أن أهم شيء في عبدة الإنتاج هو اتساقها مع السيد! إذا كان لديك معرّف المعاملات العالمية (GTID) ممكّنًا على كل من الرئيسي والعبد ، فيمكنك استخدام وظيفة gtid_subset لمعرفة ما إذا كانت طلبات تغيير البيانات نفسها قد تم تنفيذها بالفعل على هذه الأجهزة. اقرأ المزيد عن هذا هنا .

وبالتالي ، يوضح لك Orchestrator من خلال خطأ خاطئ GTID أن هناك معاملات على الرقيق غير موجودة في المعالج. لماذا يحدث ذلك؟

• Read_only = 1 لم يتم تمكينه على الرقيق ، قام شخص ما بتوصيل وتنفيذ طلب لتغيير البيانات.
• Super_read_only = 1 لم يتم تمكينه على العبد ، ثم قام المسؤول ، بعد خلط الخادم ، بالدخول وتنفيذ طلب هناك.
• إذا أخذت في الاعتبار كلتا الفقرتين السابقتين ، فهناك خدعة أخرى: في MySQL ، يقع طلب تدفق المدونات أيضًا في الحاوية ، لذلك عندما تقوم بالتدفق في المرة الأولى ، سيظهر خطأ GTID على المعالج وعلى جميع العبيد. كيف تتجنب ذلك؟ في perona-5.7.25-28 ، ظهر الإعداد binlog_skip_flush_commands = 1 ، والذي يحظر كتابة التدفق إلى binlogs. يوجد خلل في mysql.com .

أنا ألخص كل ما سبق. إذا كنت لا تريد استخدام Orchestrator في وضع تجاوز الفشل حتى الآن ، فضعه في وضع المراقبة. ثم سيكون لديك دائمًا أمام عينيك خريطة لتفاعل أجهزة MySQL ومعلومات واضحة حول نوع النسخ المتماثل على كل جهاز ، سواء كان العبيد وراءهم ، والأهم من ذلك - مدى الاتساق الذي لديهم مع السيد!

السؤال الواضح هو: "كيف يجب أن يعمل Orchestrator؟" يجب أن يختار سيدًا جديدًا من العبيد الحاليين ، ثم يعيد ربط جميع العبيد به (هذا هو الغرض من GTID ؛ إذا كنت تستخدم الآلية القديمة مع binlog_name و binlog_pos ، فإن تبديل العبد من الرئيسي الحالي إلى العبد الجديد أمر مستحيل ببساطة!). قبل أن يأتي إلينا Orchestrator ، كان عليّ أن أفعل كل هذا يدويًا. تحطم السيد القديم بسبب وحدة تحكم عربات التي تجرها الدواب ، كان لديه حوالي 10 عبيد. كنت بحاجة إلى نقل VIP من سيد إلى أحد العبيد وإعادة ربط جميع العبيد الآخرين به. كم عدد وحدات التحكم التي كان علي فتحها ، وكم عدد الأوامر المتزامنة للدخول ... اضطررت إلى الانتظار حتى الساعة 3 صباحًا ، وإزالة الحمل من جميع العبيد ، باستثناء اثنين ، وجعل السيارة الأولى من سيدين ، وربط السيارة الثانية بها على الفور ،لذلك ، خذ جميع العبيد الآخرين إلى السيد الجديد وأعد الحمل. بشكل عام ، الرعب ...

كيف يعمل Orchestrator عندما يدخل وضع تجاوز الفشل؟ يتم إظهار ذلك بسهولة أكبر من خلال مثال الحالة التي نريد فيها جعل المعلم آلة أكثر قوة وحداثة من الآن.

يوضح الشكل منتصف العملية. ما الذي تم فعله حتى هذه اللحظة؟ قلنا أننا نريد أن نجعل نوعًا من العبيد سيدًا جديدًا ، وبدأ Orchestrator للتو في إعادة ربط جميع العبيد الآخرين به ، ويعمل السيد الجديد كآلة عبور. مع هذا المخطط ، لا تحدث أخطاء ، يعمل جميع العبيد ، يقوم Orchestrator بإزالة VIP من المعلم القديم ، ونقله إلى المعلم الجديد ، وجعل read_only = 0 ونسيان المعلم الرئيسي. الكل! فترة تعطل خدمتنا هي وقت نقل VIP ، وهي 2-3 ثوان.

هذا كل شيء لهذا اليوم ، شكرا لكم جميعا. قريبا سيكون هناك مقال ثان حول Orchestrator. قال أحد الأبطال في الفيلم السوفياتي الشهير "المرآب" ، "لن أخوض معه الذكاء!" لذا ، يا Orchestrator ، سأذهب معك في الذكاء!