مقدمة

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

بالنسبة لهذا القرار ، نشأ سؤال معقول: إلى أي مدى ستكون مجموعة تجاوز الفشل؟ للتحقيق في ذلك ، قمت بتطوير منصة اختبار تحاكي حالات الفشل المختلفة على عقد الكتلة ، وتنتظر الاسترداد ، وتستعيد العقدة الفاشلة وتستمر في الاختبار في حلقة. في البداية ، كان هذا المشروع يسمى hapgsql ، ولكن بمرور الوقت شعرت بالملل من الاسم ، الذي يحتوي على حرف علة واحد فقط. لذلك ، بدأت في تسمية قواعد البيانات التي تتسامح مع الأخطاء (وعوامل IP العائمة التي تشير إليها) كروغان (شخصية من لعبة كمبيوتر ، يتم فيها تكرار جميع الأعضاء المهمة) ، والعقد والعناقيد والمشروع نفسه توشانكا (الكوكب الذي يعيش فيه krogans).

وافقت الإدارة الآن افتح مشروعًا لمجتمع مفتوح المصدر بموجب ترخيص MIT. سيتم قريبًا ترجمة README إلى اللغة الإنجليزية (لأنه من المتوقع أن يكون مطورو منظم ضربات القلب و PostgreSQL هم المستهلكون الرئيسيون) ، وقررت إصدار النسخة الروسية القديمة من README (جزئيًا) في شكل هذه المقالة.

يتم نشر المجموعات على الأجهزة الافتراضية فيرتثلبوإكس. في المجموع ، سيتم نشر 12 جهازًا افتراضيًا (إجمالي 36 جيجا بايت) ، والتي تشكل 4 مجموعات تجاوز الفشل (خيارات مختلفة). تتكون أول مجموعتين من خادمين PostgreSQL موجودين في مراكز بيانات مختلفة وخادم مشترك الشاهد c جهاز النصاب (تمت استضافته على جهاز افتراضي رخيص في مركز بيانات ثالث) يعمل على حل حالة عدم اليقين 50٪ / 50٪عن طريق الإدلاء بصوت واحد. المجموعة الثالثة في ثلاثة مراكز بيانات: سيد واحد ، وعبيدان ، لا جهاز النصاب. تتكون المجموعة الرابعة من أربعة خوادم PostgreSQL ، اثنان لكل مركز بيانات: واحد رئيسي ، والباقي نسخ متماثلة ، ويستخدم أيضًا الشاهد c جهاز النصاب. الرابع ينجو من فشل خادمين أو مركز بيانات واحد. يمكن توسيع نطاق هذا الحل إلى المزيد من النسخ المتماثلة إذا لزم الأمر.

خدمة الوقت NTPD تمت إعادة تكوينه أيضًا للتسامح مع الخطأ ، ولكنه يستخدم طريقة ntpd (وضع اليتيم). خادم مشترك الشاهد يعمل كخادم NTP مركزي ، ويوزع وقته على جميع المجموعات ، وبالتالي مزامنة جميع الخوادم مع بعضها البعض. لو الشاهد فشل أو تبين أنه معزول ، ثم سيبدأ أحد خوادم الكتلة (داخل الكتلة) في توزيع وقته. التخزين المؤقت المساعد وكيل HTTP رفعت أيضا إلى الشاهدبفضل مساعدتها ، يمكن للأجهزة الافتراضية الأخرى الوصول إلى مستودعات Yum. في الواقع ، من المرجح أن تتم استضافة خدمات مثل الوقت الدقيق والوكيل على خوادم مخصصة ، وفي الكشك يتم استضافتها على الشاهد فقط لحفظ عدد الأجهزة الافتراضية والمساحة.

إصدارات

v0. يعمل مع CentOS 7 و PostgreSQL 11 على VirtualBox 6.1.

هيكل الكتلة

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

بدلاً من ذلك ، يقوم النظام على فكرة النصاب القانوني. جميع العقد لها صوت ، ويمكن فقط لتلك التي ترى أكثر من نصف جميع العقد أن تعمل. هذا الرقم "نصف + 1" يسمى النصاب القانوني. إذا لم يتم الوصول إلى النصاب القانوني ، فإن العقدة تقرر أنها معزولة عن الشبكة ويجب عليها إيقاف تشغيل مواردها ، أي انها كذلك حماية انقسام الدماغ. إذا لم يعمل البرنامج المسؤول عن هذا السلوك ، فيجب أن تعمل هيئة مراقبة ، على سبيل المثال ، تعتمد على IPMI.

إذا كان عدد العقد زوجيًا (مجموعة في مركزين للبيانات) ، فقد ينشأ ما يسمى بعدم اليقين 50٪ / 50٪ (مناصفة) عندما تقسم عزل الشبكة الكتلة إلى نصفين تمامًا. لذلك ، يتم إضافته لعدد زوجي من العقد جهاز النصاب - برنامج خفي متسهل يمكن تشغيله على أرخص آلة افتراضية في مركز البيانات الثالث. يعطي صوته لأحد المقاطع (التي يراها) ، وبالتالي يحل نسبة 50٪ / 50٪ من عدم اليقين. اتصلت بالخادم الذي سيتم تشغيل جهاز النصاب عليه الشاهد (المصطلحات من repmgr ، أحببت ذلك).

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

Tuchanka1 (مخطط مضغوط)

هيكل

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

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

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

الفشل في المشاهدة

فشل في مشاهدة (جهاز النصاب) سأفكر فقط في مجموعة Tuchanka1 ، وستكون نفس القصة مع الآخرين. إذا فشل الشاهد ، فلن يتغير شيء في بنية الكتلة ، وسيستمر كل شيء في العمل بنفس الطريقة التي كان يعمل بها. لكن النصاب سيصبح 2 من 3 ، وبالتالي فإن أي فشل تالٍ سيكون قاتلاً للكتلة. لا يزال يتعين القيام به على وجه السرعة.

رفض Tuchanka1

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

Tuchanka2 (كلاسيكي)

هيكل

المخطط الكلاسيكي للعقدتين. يعمل السيد على واحدة ، ويعمل العبد في الثانية. كلاهما يمكنه تنفيذ الطلبات (العبد للقراءة فقط) ، لذلك يتم الإشارة إلى كليهما بواسطة IP العائم: krogan2 هو السيد ، krogan2s1 هو العبد. سيكون لكل من السيد والعبد التسامح مع الخطأ.

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

رفض Tuchanka2

في حالة فشل أحد مراكز البيانات الشاهد التصويت للثاني. في مركز البيانات العامل الوحيد ، سيتم رفع السيد ، وسيشير كل من IP العائم إليه: السيد والعبد. بالطبع ، يجب تكوين المثيل بطريقة تحتوي على موارد كافية (حدود الاتصال ، وما إلى ذلك) لقبول جميع الاتصالات والطلبات من IP العائم الرئيسي والتابع في نفس الوقت. أي ، أثناء التشغيل العادي ، يجب أن يكون لها هامش كافٍ للحدود.

Tuchanka4 (العديد من العبيد)

هيكل

بالفعل تطرف آخر. هناك قواعد بيانات بها الكثير من طلبات القراءة فقط (حالة نموذجية لموقع محمّل للغاية). Tuchanka4 هي حالة قد يكون فيها ثلاثة عبيد أو أكثر للتعامل مع مثل هذه الطلبات ، ولكن لا يزال هناك عدد قليل جدًا. مع وجود عدد كبير جدًا من العبيد ، سيكون من الضروري اختراع نظام تكرار هرمي. في الحالة الدنيا (في الصورة) ، يحتوي كل مركز من مركزي البيانات على خادمين ، يحتوي كل منهما على مثيل PostgreSQL.

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

رفض Tuchanka4

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

أول شيء يجب ملاحظته: لن تعمل جميع عناوين IP العائمة التابعة للرقيق ، ولكن واحدًا فقط. ومن أجل العمل بشكل صحيح معها ، سيكون من الضروري ذلك وكيل SQL أعاد توجيه جميع الطلبات إلى IP العائم المتبقي الوحيد ؛ و إذا وكيل SQL لا ، يمكنك سرد جميع توابع IP العائمة مفصولة بفواصل في عنوان URL للاتصال. في هذه الحالة ، مع libpq سيكون الاتصال بأول IP عامل ، كما هو الحال في نظام الاختبار التلقائي. ربما في المكتبات الأخرى ، على سبيل المثال ، JDBC ، لن يعمل هذا وهو ضروري وكيل SQL. يتم ذلك لأن عنوان IP العائم للعبيد يُحظر عليه الارتفاع في وقت واحد على خادم واحد ، بحيث يتم توزيعها بالتساوي بين الخوادم التابعة إذا كان هناك العديد منها.

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

Tuchanka3 (3 مراكز بيانات)

هيكل

هذه مجموعة لحالة يوجد فيها ثلاثة مراكز بيانات تعمل بكامل طاقتها ، لكل منها خادم قاعدة بيانات يعمل بكامل طاقته. في هذه الحالة جهاز النصاب لا حاجة. يعمل المعلم في مركز بيانات واحد ، ويعمل العبيد في المركزين الآخرين. النسخ المتماثل متزامن ، اكتب ANY (slave1 ، slave2) ، أي أن العميل سيتلقى تأكيدًا بالالتزام عندما يكون أي من العبيد أول من يستجيب بأنه قد قبل الالتزام. يشار إلى الموارد بواسطة IP عائم واحد للسيد واثنان للعبيد. على عكس Tuchanka4 ، فإن جميع عناوين IP الثلاثة العائمة تتسامح مع الخطأ. لموازنة استعلامات SQL للقراءة فقط ، يمكنك استخدام وكيل SQL (مع التسامح المنفصل مع الخطأ)، أو قم بتعيين IP عائم واحد لنصف العملاء، والنصف الآخر للثاني.

رفض Tuchanka3

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

قررت عدم تضمين وصف تفصيلي لهيكل الملف والنشر. إذا كنت ترغب في اللعب ، يمكنك قراءة كل هذا في README. أعطي فقط وصفا للاختبار الآلي.

نظام الاختبار الأوتوماتيكي

للتحقق من تحمل الخطأ للمجموعات مع تقليد الأخطاء المختلفة ، تم عمل نظام اختبار آلي. تم إطلاقه بواسطة برنامج نصي test/failure. يمكن أن يأخذ البرنامج النصي عدد المجموعات التي تريد اختبارها كمعلمات. على سبيل المثال ، هذا الأمر:

test/failure 2 3

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

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

1. هذا هو المكان الذي يتم فيه عرض إحصائيات الاختبار. مكبرات الصوت:
   • فشل - اسم الاختبار (الوظيفة في البرنامج النصي) الذي يحاكي الفشل.
   • رد فعل - المتوسط ​​الحسابي للوقت بالثواني الذي استعاد فيه العنقود أداءه. يتم قياسه من بداية البرنامج النصي الذي يحاكي الفشل ، وحتى اللحظة التي تستعيد فيها الكتلة صحتها وتكون قادرة على مواصلة تقديم الخدمات. إذا كان الوقت قصيرًا جدًا ، على سبيل المثال ، ست ثوانٍ (يحدث هذا في مجموعات مع العديد من العبيد (Tuchanka3 و Tuchanka4)) ، فهذا يعني أن العطل انتهى بهيئة تابعة غير متزامنة ولم تؤثر على الأداء بأي شكل من الأشكال ، لم يكن هناك مفاتيح حالة الكتلة.
   • الانحراف - يوضح انتشار (دقة) القيمة رد فعل بطريقة الانحراف المعياري.
   • عد كم مرة تم إجراء هذا الاختبار.
2. يتيح لك السجل القصير تقييم ما تقوم به الكتلة حاليًا. يتم عرض رقم التكرار (الاختبار) والطابع الزمني واسم العملية. يشير التنفيذ الطويل جدًا (> 5 دقائق) إلى نوع من المشاكل.
3. قلب (القلب) هو الوقت الحالي. لتقييم الأداء البصري سيد يتم كتابة الوقت الحالي باستمرار على جدوله باستخدام IP العائم للسيد. إذا نجحت ، يتم عرض النتيجة في هذه اللوحة.
4. فاز (النبض) - "الوقت الحالي" ، والذي تم تسجيله مسبقًا بواسطة البرنامج النصي قلب لإتقان ، اقرأ الآن من عبد من خلال IP العائم. يسمح لك بالتقييم البصري لأداء العبيد والنسخ المتماثل. لا توجد عبيد مع IP عائم في Tuchanka1 (لا يوجد عبيد يقدمون الخدمات) ، ولكن هناك حالتان (DB) ، لذلك لن يتم عرضها هنا فازو قلب المثيل الثاني.
5. مراقبة حالة الكتلة باستخدام الأداة pcs mon. يُظهر هيكل وتوزيع الموارد حسب العقد والمعلومات المفيدة الأخرى.
6. يعرض مراقبة النظام من كل آلة افتراضية للكتلة. قد يكون هناك المزيد من هذه اللوحات - كم عدد الأجهزة الافتراضية التي تمتلكها المجموعة. رسمان بيانيان تحميل وحدة المعالجة المركزية (معالجان في الأجهزة الافتراضية) ، اسم الجهاز الظاهري ، تحميل النظام (تم تسميته بمتوسط ​​التحميل لأنه بلغ متوسطه أكثر من 5 و 10 و 15 دقيقة) ، وبيانات المعالجة ، وتخصيص الذاكرة.
7. تتبع البرنامج النصي الذي يقوم بالاختبارات. في حالة حدوث عطل - انقطاع مفاجئ في العمل أو دورة انتظار لا نهاية لها - هنا يمكنك معرفة سبب هذا السلوك.

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

يتكون كل اختبار من العمليات التالية:

1. بدء وظيفة تحاكي خطأ.
2. مستعد؟ - انتظار استعادة صحة الكتلة (عند تقديم جميع الخدمات).
3. يتم عرض مهلة استرداد الكتلة (رد فعل).
4. حل - تم "إصلاح" الكتلة. بعد ذلك يجب أن تعود إلى حالة التشغيل الكامل وتكون جاهزة للخلل التالي.

فيما يلي قائمة بالاختبارات مع وصف لما يقومون به:

• شوكة: يخلق "نفاد الذاكرة" باستخدام قنبلة شوكة.
• خارج الفضاء: القرص الصلب ممتلئ. لكن الاختبار رمزي إلى حد ما ، مع الحمل الضئيل الذي تم إنشاؤه أثناء الاختبار ، عندما يفيض القرص الصلب ، لا تفشل PostgreSQL عادةً.
• بوستجرس-قتل: يقتل PostgreSQL بالأمر killall -KILL postgres.
• postgres-STOP: توقف PostgreSQL مع الأمر killall -STOP postgres.
• انقطاع التيار الكهربائي: "إلغاء تنشيط" الجهاز الظاهري باستخدام الأمر VBoxManage controlvm "виртуалка" poweroff.
• إعادة تعيين: يعيد تحميل الجهاز الظاهري بالأمر VBoxManage controlvm "виртуалка" reset.
• SBD STOP: يوقف البرنامج الخفي SBD بالأمر killall -STOP sbd.
• إيقاف التشغيل: عبر SSH يرسل أمرًا إلى الجهاز الظاهري systemctl poweroff، يتم إيقاف تشغيل النظام بأمان.
• إلغاء الارتباط: عزل الشبكة ، القيادة VBoxManage controlvm "виртуалка" setlinkstate1 off.

إنهاء الاختبار باستخدام أمر tmux القياسي "kill-window" السيطرة- ب &، أو عن طريق الأمر "detach-client" السيطرة- BD: في نفس الوقت ، اكتمل الاختبار ، تم إغلاق tmux ، تم إيقاف تشغيل الأجهزة الافتراضية.

تم تحديد المشكلات أثناء الاختبار

• بهذه اللحظة حراسة الخفي sbd يتعامل مع إيقاف الشياطين المرصودة ، ولكن لا يقوم بتجميدها. ونتيجة لذلك ، يتم حل الأعطال بشكل غير صحيح ، مما يؤدي إلى التجميد فقط كوروسينك и جهاز تنظيم ضربات القلب، لكن ليس معلقًا SBD. لفحص كوروسينك بالفعل PR # 83 (على GitHub في SBD)، تم قبوله في الفرع رئيسي. لقد وعدوا (في PR # 83) أنه سيكون هناك شيء مشابه لجهاز تنظيم ضربات القلب ، وآمل ذلك ريدهات 8 سوف تفعل. لكن مثل هذه "الأعطال" تخمينية ، ويمكن تقليدها بسهولة بشكل مصطنع باستخدام ، على سبيل المثال ، killall -STOP corosyncلكنهم لا يجتمعون أبدًا في الحياة الحقيقية.

• У جهاز تنظيم ضربات القلب في الإصدار الخاص بـ CentOS 7 تم تعيينه بشكل غير صحيح sync_timeout у جهاز النصاب، نتيجة ل إذا فشلت إحدى العقدة ، تتم إعادة تشغيل العقدة الثانية ببعض الاحتمالات، الذي كان من المفترض أن ينتقل إليه السيد. علاجه بالتكبير sync_timeout у جهاز النصاب أثناء النشر (في البرنامج النصي setup/setup1). لم يتم قبول هذا التعديل من قبل المطورين جهاز تنظيم ضربات القلب، بدلاً من ذلك وعدوا بإعادة صياغة البنية التحتية بطريقة (في بعض المستقبل غير المحدد) بحيث يتم حساب هذه المهلة تلقائيًا.

• إذا حددت أثناء تكوين قاعدة البيانات ذلك LC_MESSAGES (الرسائل النصية) يمكن استخدام Unicode ، على سبيل المثال ، ru_RU.UTF-8، ثم عند بدء التشغيل بوستجرس في بيئة لا تكون فيها اللغة المحلية هي UTF-8 ، على سبيل المثال ، في بيئة فارغة (هنا جهاز تنظيم ضربات القلب+pgsqlms(باف) يبدأ بوستجرس)، الذي - التي في السجل بدلاً من أحرف UTF-8 ، ستكون هناك علامات استفهام. لم يتفق مطورو PostgreSQL أبدًا على ما يجب فعله في هذه الحالة. يكلف ، عليك أن تضع LC_MESSAGES=en_US.UTF-8 عند تكوين (إنشاء) مثيل قاعدة بيانات.

• إذا تم تعيين wal_receiver_timeout (افتراضيًا هو 60 ثانية) ، فعند اختبار PostgreSQL-STOP على المعلم في مجموعتي tuchanka3 و tuchanka4 النسخ المتماثل لا يعيد الاتصال بسيد جديد. النسخ المتماثل هناك متزامن ، لذلك لا يتوقف العبد فقط ، ولكن أيضًا السيد الجديد. يحصل عن طريق ضبط wal_receiver_timeout = 0 عند تكوين PostgreSQL.

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

صورة كروغان مأخوذة من الفن المنحرف بإذن من المؤلف:

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