في Citymobil نستخدم قاعدة بيانات MySQL كمخزن رئيسي للبيانات المستمرة. لدينا العديد من مجموعات قواعد البيانات لمختلف الخدمات والأغراض.

يعد التوافر المستمر للسيد مؤشرا حاسما لأداء النظام بأكمله وأجزائه الفردية. يؤدي الاسترداد التلقائي للمجموعة في حالة حدوث فشل رئيسي إلى تقليل وقت الاستجابة للحادث ووقت توقف النظام بشكل كبير. في هذه المقالة، سألقي نظرة على تصميم عالي التوفر (HA) لمجموعة MySQL بناءً على منسق ماي إس كيو إل وعناوين IP الافتراضية (VIP).

حل HA يعتمد على VIP

أولاً، سأخبرك بإيجاز ما هو نظام تخزين البيانات لدينا.

نحن نستخدم نظام النسخ المتماثل الكلاسيكي مع نسخة رئيسية واحدة يمكن الوصول إليها للكتابة ونسخ متماثلة متعددة للقراءة فقط. يمكن أن تحتوي المجموعة على عقدة رئيسية متوسطة - عقدة تكون نسخة متماثلة وعقدة رئيسية للآخرين. يصل العملاء إلى النسخ المتماثلة من خلال HAProxy، مما يسمح بتوزيع الأحمال بشكل متساوٍ وسهولة القياس. يرجع استخدام HAProxy إلى أسباب تاريخية، ونحن حاليًا بصدد الانتقال إلى ProxySQL.

يتم إجراء النسخ المتماثل في الوضع شبه المتزامن بناءً على GTID. وهذا يعني أنه يجب على نسخة متماثلة واحدة على الأقل تسجيل المعاملة قبل اعتبارها ناجحة. يوفر وضع النسخ المتماثل هذا التوازن الأمثل بين الأداء وأمان البيانات في حالة فشل العقدة الرئيسية. بشكل أساسي، يتم نقل جميع التغييرات من النسخة الرئيسية إلى النسخ المتماثلة باستخدام Row Based Replication (RBR)، ولكن قد يكون لدى بعض العقد mixed binlog format.

يقوم المنسق بتحديث حالة طوبولوجيا المجموعة بشكل دوري، ويحلل المعلومات الواردة، وفي حالة ظهور مشاكل، يمكنه تشغيل إجراء الاسترداد التلقائي. المطور مسؤول عن الإجراء نفسه، حيث يمكن تنفيذه بطرق مختلفة: استنادًا إلى VIP أو DNS أو باستخدام خدمات اكتشاف الخدمة أو الآليات المكتوبة ذاتيًا.

إحدى الطرق البسيطة لاستعادة النسخة الرئيسية في حالة فشلها هي استخدام عناوين VIP العائمة.

ما تحتاج إلى معرفته حول هذا الحل قبل المضي قدمًا:

• VIP هو عنوان IP غير مرتبط بواجهة شبكة فعلية محددة. إذا فشلت إحدى العقد أو أثناء الصيانة المجدولة، فيمكننا تحويل VIP إلى مورد آخر بأقل وقت توقف.
• يعد تحرير وإصدار عنوان IP افتراضي عملية رخيصة وسريعة.
• للعمل مع VIP، تحتاج إلى الوصول إلى الخادم عبر SSH، أو استخدام أدوات مساعدة خاصة، على سبيل المثال، keepalived.

دعونا نلقي نظرة على المشاكل المحتملة مع معالجنا ونتخيل كيف يجب أن تعمل آلية الاسترداد التلقائي.

اختفى اتصال الشبكة بالجهاز الرئيسي، أو ظهرت مشكلة على مستوى الأجهزة، والخادم غير متاح

1. يقوم المنسق بتحديث طوبولوجيا المجموعة، حيث تشير كل نسخة متماثلة إلى أن السيد غير متوفر. يبدأ المنسق عملية اختيار نسخة متماثلة مناسبة لدور السيد الجديد ويبدأ عملية الاسترداد.
2. نحن نحاول إزالة VIP من السيد القديم - دون جدوى.
3. تتحول النسخة المتماثلة إلى دور السيد. يتم إعادة بناء الطوبولوجيا.
4. إضافة واجهة شبكة جديدة مع VIP. نظرًا لعدم إمكانية إزالة VIP، نبدأ في إرسال طلب بشكل دوري في الخلفية ARP مجاني. يتيح لك هذا النوع من الطلب/الاستجابة تحديث جدول تعيين عنوان IP وMAC على المحولات المتصلة، وبالتالي إعلامك بانتقال VIP الخاص بنا. هذا يقلل من الاحتمالية split brain عند عودة السيد القديم.
5. تتم إعادة توجيه كافة الاتصالات الجديدة على الفور إلى السيد الجديد. تفشل الاتصالات القديمة ويتم إجراء الاستدعاءات المتكررة لقاعدة البيانات على مستوى التطبيق.

الخادم يعمل في الوضع العادي، حدث فشل على مستوى نظام إدارة قواعد البيانات (DBMS).

تشبه الخوارزمية الحالة السابقة: تحديث الهيكل وبدء عملية الاسترداد. نظرًا لأن الخادم متاح، فقد نجحنا في تحرير VIP على الخادم القديم، ونقله إلى الخادم الجديد، وإرسال العديد من طلبات ARP. لا ينبغي أن تؤثر العودة المحتملة للسيد القديم على المجموعة المعاد بناؤها وتشغيل التطبيق.

مشاكل أخرى

فشل النسخ المتماثلة أو الماجستير المتوسطة لا يؤدي إلى الإجراءات التلقائية ويتطلب التدخل اليدوي.

تتم دائمًا إضافة واجهة الشبكة الافتراضية بشكل مؤقت، أي أنه بعد إعادة تشغيل الخادم، لا يتم تعيين VIP تلقائيًا. يبدأ كل مثيل لقاعدة البيانات في وضع القراءة فقط بشكل افتراضي، ويقوم المنسق تلقائيًا بتبديل الملف الرئيسي الجديد للكتابة ويحاول التثبيت read only على السيد القديم. تهدف هذه الإجراءات إلى تقليل الاحتمالية split brain.

قد تنشأ مشكلات أثناء عملية الاسترداد، والتي يجب أيضًا إخطارها من خلال واجهة مستخدم المنسق بالإضافة إلى أدوات المراقبة القياسية. لقد قمنا بتوسيع REST API بإضافة هذه الميزة (PR قيد المراجعة حاليًا).

ويرد أدناه الرسم التخطيطي العام لحل HA.

اختيار سيد جديد

المنسق ذكي بما فيه الكفاية ويحاول الاختيار النسخة الأكثر ملاءمة بصفته سيدًا جديدًا وفقًا للمعايير التالية:

• النسخة المتماثلة تتخلف عن السيد.
• إصدار MySQL الرئيسي والنسخة المتماثلة؛
• نوع النسخ المتماثل (RBR، SBR أو مختلط)؛
• الموقع في نفس مراكز البيانات أو في مراكز مختلفة؛
• توفر errant GTID — المعاملات التي تم تنفيذها على النسخة المتماثلة وليست على النسخة الرئيسية؛
• يتم أيضًا أخذ قواعد الاختيار المخصصة في الاعتبار.

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

وقت الاستجابة والاسترداد

في حالة وقوع حادث، من المهم تقليل وقت توقف النظام، لذلك دعونا نأخذ في الاعتبار معلمات MySQL التي تؤثر على إنشاء وتحديث هيكل المجموعة بواسطة المنسق:

• slave_net_timeout - عدد الثواني التي تنتظر خلالها النسخة المتماثلة وصول بيانات جديدة أو إشارة نبضات قلب من الجهاز الرئيسي قبل التعرف على الاتصال المفقود وإعادة الاتصال. كلما انخفضت القيمة، زادت سرعة تحديد النسخة المتماثلة لقطع الاتصال بالجهاز الرئيسي. قمنا بتعيين هذه القيمة على 5 ثواني.
• MASTER_CONNECT_RETRY — عدد الثواني بين محاولات إعادة الاتصال. في حالة حدوث مشكلات في الشبكة، ستسمح القيمة المنخفضة لهذه المعلمة بإعادة الاتصال السريع وتمنع بدء عملية استرداد المجموعة. القيمة الموصى بها هي 1 ثانية.
• MASTER_RETRY_COUNT — الحد الأقصى لعدد محاولات إعادة الاتصال.
• MASTER_HEARTBEAT_PERIOD - الفاصل الزمني بالثواني وبعد ذلك يرسل السيد إشارة نبضات القلب. الافتراضيات إلى نصف القيمة slave_net_timeout.

خيارات المنسق:

• DelayMasterPromotionIfSQLThreadNotUpToDate - إذا كان متساويا true، فلن يتم تطبيق الدور الرئيسي على النسخة المتماثلة المرشحة حتى يكمل مؤشر ترابط SQL الخاص بالنسخة المتماثلة جميع المعاملات غير المطبقة من سجل الترحيل. نحن نستخدم هذا الخيار لتجنب فقدان المعاملات عندما تتأخر جميع النسخ المتماثلة المرشحة.
• InstancePollSeconds — وتيرة بناء وتحديث الطوبولوجيا.
• RecoveryPollSeconds — تردد تحليل الطوبولوجيا. إذا تم اكتشاف مشكلة، فسيتم بدء استرداد الهيكل. هذا ثابت، يساوي 1 ثانية.

يتم استقصاء كل عقدة نظام المجموعة بواسطة المنسق مرة واحدة كل مرة InstancePollSeconds ثواني عند اكتشاف مشكلة، يتم فرض حالة الكتلة محدث، ومن ثم يتم اتخاذ القرار النهائي لإجراء عملية الاسترداد. من خلال تجربة قاعدة بيانات مختلفة ومعلمات منسقة، تمكنا من تقليل وقت الاستجابة والاسترداد إلى 30 ثانية.

اختبار موقف

لقد بدأنا باختبار مخطط HA مع تطوير محلي اختبار مقاعد البدلاء ومواصلة التنفيذ في بيئات الاختبار والإنتاج. المنصة المحلية مؤتمتة بالكامل استنادًا إلى Docker وتتيح لك تجربة تكوين المنسق والشبكة، وتوسيع نطاق المجموعة من 2-3 خوادم إلى عدة عشرات، وإجراء التمارين في بيئة آمنة.

أثناء التدريبات، نختار إحدى طرق محاكاة المشكلة: إطلاق النار على السيد على الفور باستخدام kill -9، قم بإنهاء العملية بهدوء وإيقاف الخادم (docker-compose stop) ، محاكاة مشاكل الشبكة باستخدام iptables -j REJECT أو iptables -j DROP. ونتوقع النتائج التالية:

• سوف يكتشف المنسق المشاكل مع السيد ويحدث الهيكل في مدة لا تزيد عن 10 ثوانٍ؛
• سيبدأ إجراء الاسترداد تلقائيًا: سيتغير تكوين الشبكة، وسينتقل دور السيد إلى النسخة المتماثلة، وسيتم إعادة بناء الهيكل؛
• سيصبح الملف الرئيسي الجديد قابلاً للكتابة، ولن يتم فقدان النسخ المتماثلة الحية أثناء عملية إعادة البناء؛
• ستبدأ كتابة البيانات إلى السيد الجديد وتكرارها؛
• إجمالي وقت الاسترداد لن يزيد عن 30 ثانية.

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

النتائج

تعد صحة عقدة نظام التخزين الرئيسية إحدى المهام الرئيسية لـ SRE وفريق العمليات. إن تنفيذ المنسق وحل HA المعتمد على VIP قد أتاح لنا تحقيق النتائج التالية:

• الكشف الموثوق عن المشاكل المتعلقة بطوبولوجيا مجموعة قاعدة البيانات؛
• الاستجابة التلقائية والسريعة للحوادث ذات الصلة بالرئيسية، مما يقلل من وقت توقف النظام.

لكن الحل له حدوده وعيوبه:

• سيتطلب توسيع نطاق مخطط HA إلى العديد من مراكز البيانات شبكة L2 واحدة بينهما؛
• قبل تعيين VIP على السيد الجديد، نحتاج إلى تحريره على السيد القديم. تكون العملية متسلسلة، مما يزيد من وقت الاسترداد؛
• يتطلب تحرير VIP وصول SSH إلى الخادم، أو أي طريقة أخرى لاستدعاء الإجراءات عن بعد. نظرًا لأن الخادم أو قاعدة البيانات تواجه مشكلات تسببت في عملية الاسترداد، فلا يمكننا التأكد من اكتمال عملية إزالة VIP بنجاح. وهذا يمكن أن يؤدي إلى ظهور خادمين لهما نفس عنوان IP الظاهري ومشكلة split brain.

لتجنب split brain، يمكنك استخدام الطريقة حجر ("أطلق النار على العقدة الأخرى في الرأس")، والتي تعزل أو تعطل عقدة المشكلة تمامًا. هناك طرق أخرى لتنفيذ التوفر العالي للمجموعة: مزيج من VIP و DNS، واكتشاف الخدمة وخدمات الوكيل، والنسخ المتماثل المتزامن وغيرها من الأساليب التي لها عيوبها ومزاياها.

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

المصدر: www.habr.com