يبدأ أي مشروع كبير بخادمين. في البداية كان هناك خادم قاعدة بيانات واحد، ثم تمت إضافة التابعين إليه لقياس القراءة. وبعد ذلك - توقف! هناك سيد واحد، ولكن هناك العديد من العبيد؛ إذا غادر أحد العبيد، فسيكون كل شيء على ما يرام، ولكن إذا غادر السيد، فسيكون الأمر سيئًا: وقت التوقف عن العمل، يحاول المسؤولون رفع الخادم. ما يجب القيام به؟ حجز سيد. لقد كتب زميلي بافيل بالفعل عن هذا ، لن أكرر ذلك. بدلاً من ذلك، سأخبرك لماذا تحتاج بالتأكيد إلى Orchestrator لـ MySQL!
لنبدأ بالسؤال الرئيسي: "كيف يمكننا تحويل الكود إلى جهاز جديد عندما يغادر السيد؟"
- يعجبني المخطط مع VIP (IP الظاهري) أكثر من غيره، وسنتحدث عنه أدناه. إنه الأبسط والأكثر وضوحًا، على الرغم من وجود قيود واضحة عليه: يجب أن يكون السيد الذي سنحتفظ به في قطاع L2 مع الجهاز الجديد، أي يمكننا أن ننسى DC الثاني. وبطريقة ودية، إذا اتبعت القاعدة القائلة بأن L2 الكبير يعد شرًا، لأن L2 موجود فقط لكل حامل، وL3 بين الرفوف، ومثل هذا المخطط به المزيد من القيود.
- يمكنك كتابة اسم DNS في الكود وحله من خلال /etc/hosts. في الواقع، لن يكون هناك حل. ميزة المخطط: لا يوجد أي قيود مميزة للطريقة الأولى، أي أنه من الممكن تنظيم DC عبر. ولكن بعد ذلك يطرح السؤال الواضح: ما مدى السرعة التي يمكننا بها تسليم التغيير إلى /etc/hosts عبر Puppet-Ansible؟
- يمكنك تغيير الطريقة الثانية قليلاً: تثبيت التخزين المؤقت لنظام أسماء النطاقات (DNS) على جميع خوادم الويب، والتي من خلالها سينتقل الرمز إلى قاعدة البيانات الرئيسية. يمكنك ضبط TTL 60 لهذا الإدخال في DNS. ويبدو أنه إذا تم تنفيذه بشكل صحيح، فإن الطريقة جيدة.
- مخطط اكتشاف الخدمة، مما يعني استخدام القنصل وما إلى ذلك.
- خيار مثير للاهتمام مع . تحتاج إلى توجيه كل حركة المرور إلى MySQL من خلال ProxySQL؛ حيث يمكن لـ ProxySQL نفسه تحديد من هو السيد. بالمناسبة، يمكنك أن تقرأ عن أحد الخيارات لاستخدام هذا المنتج في بلدي .
قام مؤلف Orchestrator، الذي يعمل في Github، بتطبيق المخطط الأول مع VIP أولاً، ثم قام بتحويله إلى مخطط مع القنصل.
تخطيط البنية التحتية النموذجية:
سأصف على الفور المواقف الواضحة التي يجب أخذها بعين الاعتبار:
- يجب ألا يتم تسجيل عنوان VIP في التكوين على أي من الخوادم. لنتخيل موقفًا: تمت إعادة تشغيل السيد، وأثناء التحميل، دخل Orchestrator في وضع تجاوز الفشل وجعل أحد العبيد سيدًا؛ ثم ارتفع السيد القديم، والآن VIP على سيارتين. هذا سيء.
- بالنسبة للمنسق، ستحتاج إلى كتابة برنامج نصي لاستدعاء السيد القديم والسيد الجديد. على السيد القديم تحتاج إلى تشغيل ifdown، وعلى السيد الجديد – ifup vip. سيكون من الجيد أن نذكر أيضًا في هذا البرنامج النصي أنه في حالة تجاوز الفشل، يتم ببساطة إيقاف تشغيل المنفذ الموجود على المفتاح الرئيسي القديم لتجنب أي انقسام في الدماغ.
- بعد أن يقوم Orchestrator باستدعاء البرنامج النصي الخاص بك لإزالة VIP و/أو إطفاء المنفذ الموجود على المحول أولاً، ثم استدعاء البرنامج النصي لرفع VIP على السيد الجديد، لا تنس استخدام أمر arping لإخبار الجميع بأن VIP الجديد أصبح الآن هنا.
- يجب أن يكون لدى جميع العبيد read_only=1، وبمجرد ترقية العبد إلى السيد، يجب أن يكون read_only=0.
- لا تنس أن أي عبد اخترناه لهذا يمكن أن يصبح سيدًا (يمتلك المنسق آلية تفضيل كاملة بالنسبة للعبد الذي يجب اعتباره مرشحًا لسيد جديد في المقام الأول، وأي عبد يجب أن يكون في المقام الثاني) لا يتم اختياره على الإطلاق تحت أي ظرف من الظروف الرئيسية). فإذا أصبح العبد سيدًا، فإن حمل العبد يبقى عليه ويضاف إليه حمل السيد، ويجب مراعاة ذلك.
لماذا تحتاج إلى منسق إذا لم يكن لديك واحدًا؟
- يمتلك Orchestrator واجهة رسومية سهلة الاستخدام للغاية تعرض الهيكل بأكمله (انظر لقطة الشاشة أدناه).
- يمكن لـ Orchestrator تتبع العبيد المتخلفين، وحيث يتعطل النسخ المتماثل بشكل عام (لدينا نصوص برمجية مرفقة بـ Orchestrator لإرسال الرسائل القصيرة).
- يخبرك المنسق عن العبيد الذين لديهم خطأ في GTID.
واجهة الأوركسترا:
ما هو GTID الخاطئ؟
هناك متطلبان رئيسيان لكي يعمل المنسق:
- من الضروري أن يتم تمكين GTID الزائف على كافة الأجهزة الموجودة في مجموعة MySQL؛ لقد تم تمكين GTID لدينا.
- من الضروري أن يكون هناك نوع واحد من binlogs في كل مكان، يمكنك استخدام البيان. كان لدينا تكوين يكون فيه السيد ومعظم العبيد لديهم صف، وظل اثنان تاريخيًا في الوضع المختلط. نتيجة لذلك، لم يرغب Orchestrator ببساطة في ربط هؤلاء العبيد بالسيد الجديد.
تذكر أن أهم شيء في إنتاج الرقيق هو اتساقه مع السيد! إذا تم تمكين معرف المعاملة العالمية (GTID) على كل من الجهازين الرئيسي والتابع، فيمكنك استخدام وظيفة gtid_subset لمعرفة ما إذا كانت نفس طلبات تغييرات البيانات قد تم تنفيذها بالفعل على هذه الأجهزة. يمكنك قراءة المزيد عن هذا .
وبالتالي، يوضح لك Orchestrator من خلال خطأ GTID أن هناك معاملات على العبد غير موجودة على السيد. لماذا يحدث هذا؟
- لم يتم تمكين Read_only=1 على الجهاز التابع؛ فقد قام شخص ما بالاتصال وأكمل طلبًا لتغيير البيانات.
- لم يتم تمكين Super_read_only=1 على العبد، ثم دخل المسؤول، بعد أن أربك الخادم، ونفذ الطلب هناك.
- إذا أخذت في الاعتبار النقطتين السابقتين، فهناك خدعة أخرى: في MySQL، يذهب طلب مسح السجلات الثنائية أيضًا إلى binlog، لذلك في أول عملية مسح، سيظهر خطأ GTID على السيد وجميع العبيد. كيفية تجنب هذا؟ قدم Perona-5.7.25-28 الإعداد binlog_skip_flush_commands=1، الذي يمنع كتابة التدفق في binlogs. يوجد موقع ثابت على موقع mysql.com .
اسمحوا لي أن ألخص كل ما سبق. إذا كنت لا تريد استخدام Orchestrator في وضع تجاوز الفشل بعد، فقم بوضعه في وضع المراقبة. ثم سيكون لديك دائمًا أمام عينيك خريطة لتفاعل أجهزة MySQL ومعلومات مرئية حول نوع النسخ المتماثل على كل جهاز، وما إذا كان العبيد متخلفين عن الركب، والأهم من ذلك، مدى اتساقهم مع السيد!
السؤال الواضح هو: "كيف يجب أن يعمل المنسق؟" يجب عليه تحديد سيد جديد من العبيد الحاليين، ثم إعادة توصيل جميع العبيد به (وهذا هو ما يلزم GTID من أجله؛ إذا كنت تستخدم الآلية القديمة مع binlog_name وbinlog_pos، فقم بتبديل العبد من السيد الحالي إلى سيد جديد هو ببساطة مستحيل!). قبل أن يكون لدينا Orchestrator، كان علي أن أفعل كل هذا يدويًا. كان السيد العجوز معلقًا بسبب وحدة تحكم Adaptec التي تجرها الدواب، وكان بها حوالي 10 عبيد. كنت بحاجة إلى نقل VIP من السيد إلى أحد العبيد وإعادة توصيل جميع العبيد الآخرين به. كم عدد وحدات التحكم التي كان علي فتحها، وكم عدد الأوامر المتزامنة التي أدخلتها... كان علي الانتظار حتى الساعة 3 صباحًا، وإزالة الحمل من جميع العبيد باستثناء اثنين، وصنع الجهاز الأول من جهازين رئيسيين، وإرفاق الجهاز الثاني على الفور إليه، لذا قم بتوصيل جميع العبيد الآخرين بالسيد الجديد وأعد الحمل. على العموم رهيب ...
كيف يعمل Orchestrator عندما يدخل في وضع تجاوز الفشل؟ يمكن توضيح ذلك بسهولة من خلال مثال لموقف نريد فيه أن نجعل السيد آلة أقوى وأكثر حداثة مما لدينا الآن.
يوضح الشكل منتصف العملية. ما الذي تم إنجازه بالفعل حتى هذه اللحظة؟ قلنا أننا نريد أن نجعل بعض العبيد هو السيد الجديد، بدأ Orchestrator ببساطة في إعادة ربط جميع العبيد الآخرين به، حيث يعمل السيد الجديد كآلة عبور. مع هذا المخطط، لا تحدث أي أخطاء، وتعمل جميع العبيد، ويزيل Orchestrator VIP من السيد القديم، وينقله إلى السيد الجديد، ويجعل read_only=0 وينسى السيد القديم. الجميع! وقت التوقف عن الخدمة لدينا هو وقت نقل VIP، وهو 2-3 ثواني.
هذا كل شيء لهذا اليوم، شكرا لكم جميعا. سيكون هناك مقال ثانٍ عن الأوركسترا قريبًا. وفي الفيلم السوفييتي الشهير «كراج»، قالت إحدى الشخصيات: «لن أذهب للاستطلاع معه!» لذا، أيها المنسق، سأذهب معك في رحلة استطلاع!
المصدر: www.habr.com