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

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

حل VIP HA

أولاً ، سأتحدث باختصار عن شكل نظام تخزين البيانات لدينا.

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

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

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

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

ما تحتاج إلى معرفته حول هذا الحل قبل الانتقال:

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

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

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

, . , , .
VIP — .
. .
VIP. VIP , gratuitous ARP. / IP- MAC-, VIP. split brain .
يتم إعادة توجيه جميع الاتصالات الجديدة على الفور إلى الرئيسي الجديد. فشل الاتصالات القديمة ، يتم إجراء مكالمات متكررة لقاعدة البيانات على مستوى التطبيق.

الخادم يعمل في الوضع العادي ؛ حدث فشل على مستوى DBMS

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

مشاكل أخرى

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

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

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

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

اختيار معالج جديد

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

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

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

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

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

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

خيارات Orchestrator:

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

يقوم العقيد باستطلاع كل عقدة عنقودية مرة كل 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 SSH- , . , , , VIP . IP- split brain.

لتجنب ذلك split brain، يمكنك استخدام طريقة STONITH ("Shoot The Other Node In The Head") ، والتي تعمل على عزل العقدة المشكلة أو فصلها تمامًا. هناك طرق أخرى لتنفيذ التوافر العالي للمجموعة: مزيج من VIP و DNS ، واكتشاف الخدمات وخدمات الوكيل ، والنسخ المتزامن ، وطرق أخرى لها عيوبها ومزاياها.

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

Orchestrator و VIP كحل HA لكتلة MySQL