قصص فشل Patroni أو كيفية تحطيم مجموعة PostgreSQL الخاصة بك. أليكسي ليسوفسكي

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

سأخبرك قليلا عن نفسي. لقد بدأت كمسؤول نظام. عمل في تطوير الويب. أعمل في Data Egret منذ عام 2014. يتمثل نشاط الشركة في الاستشارات في مجال Postgres. ونحن نخدم Postgres بالضبط ، ونعمل مع Postgres كل يوم ، لذلك لدينا خبرات مختلفة تتعلق بالعملية.

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

بصرف النظر عن Postgres ، أنا أحب Linux. أحب أن أتجول فيه وأستكشف ، أحب أن أجمع النوى. أنا أحب الافتراضية ، والحاويات ، عامل ميناء ، Kubernetes. كل هذا يثير اهتمامي ، لأن عادات الإدارة القديمة تؤثر. أحب التعامل مع المراقبة. وأنا أحب postgres الأشياء المتعلقة بالإدارة ، أي النسخ الاحتياطي والنسخ الاحتياطي. وفي أوقات فراغي أكتب في Go. أنا لست مهندس برمجيات ، أنا فقط أكتب لنفسي في Go. وهذا يسعدني.

• أعتقد أن الكثير منكم يعلم أن Postgres لا يحتوي على HA (توافر عالي) خارج الصندوق. للحصول على HA ، تحتاج إلى تثبيت شيء ما وتهيئته وبذل جهد والحصول عليه.
• هناك العديد من الأدوات و Patroni هو واحد منهم يحل HA بشكل رائع وجيد للغاية. ولكن بوضعها كلها في معمل اختبار وتشغيلها ، يمكننا أن نرى أن كل شيء يعمل ، يمكننا إعادة إنتاج بعض المشاكل ، ونرى كيف يخدمها Patroni. وسنرى أن كل شيء يعمل بشكل رائع.
• لكن في الممارسة العملية ، واجهنا مشاكل مختلفة. وسأتحدث عن هذه المشاكل.
• سأخبرك كيف قمنا بتشخيصه ، وما الذي قمنا بتعديله - سواء ساعدنا أم لا.

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

وإخلاء صغير قبل أن نبدأ تقريرنا.

كل هذه المشاكل التي واجهتنا ، واجهتنا في أول 6-7-8 أشهر من العملية. بمرور الوقت ، توصلنا إلى أفضل ممارساتنا الداخلية. واختفت مشاكلنا. لذلك ، تم الإعلان عن التقرير منذ حوالي ستة أشهر ، عندما كان كل شيء جديدًا في رأسي وتذكرته تمامًا.

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

ما هو باتروني؟

• هذا نموذج لبناء HA. هذا ما ورد في الوثائق. ومن وجهة نظري ، هذا توضيح صحيح للغاية. Patroni ليس حلاً سحريًا لحل جميع مشاكلك ، أي أنك تحتاج إلى بذل جهد لإنجاحها وتحقيق الفوائد.
• هذه خدمة وكيل يتم تثبيتها على كل خدمة قاعدة بيانات وهي نوع من نظام init الخاص بـ Postgres. يبدأ Postgres ، ويوقف ، ويعيد التشغيل ، ويعيد التكوين ، ويغير طوبولوجيا المجموعة الخاصة بك.
• وفقًا لذلك ، من أجل تخزين حالة الكتلة ، يلزم تمثيلها الحالي ، كما يبدو ، نوعًا من التخزين. ومن وجهة النظر هذه ، اتخذ باتروني طريق تخزين الحالة في نظام خارجي. إنه نظام تخزين تكوين موزع. يمكن أن يكون Etcd أو Consul أو ZooKeeper أو kubernetes Etcd ، أي أحد هذه الخيارات.
• وإحدى ميزات Patroni هي أنك تحصل على أداة التسجيل التلقائي من العلبة ، فقط من خلال إعدادها. إذا أخذنا Repmgr للمقارنة ، فسيتم تضمين الملف هناك. مع Repmgr ، نحصل على تبديل ، ولكن إذا أردنا أداة تحويل تلقائي ، فسنحتاج إلى تهيئته بشكل إضافي. باتروني لديه بالفعل مُرشح أوتوماتيكي خارج الصندوق.
• وهناك أشياء أخرى كثيرة. على سبيل المثال ، صيانة التكوينات ، صب النسخ المتماثلة الجديدة ، النسخ الاحتياطي ، إلخ. ولكن هذا خارج نطاق التقرير ، لن أتحدث عنه.

والنتيجة الصغيرة هي أن المهمة الرئيسية لـ Patroni هي القيام بملف شخصي جيد وموثوق بحيث تظل مجموعتنا عاملة ولا يلاحظ التطبيق التغييرات في طوبولوجيا الكتلة.

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

قد يكسر:

• قد تنكسر Postgres. يمكن أن يكون نسخة رئيسية أو نسخة طبق الأصل ، وقد يفشل أحدهم.
• قد ينكسر Patroni نفسه.
• قد ينقطع DCS حيث يتم تخزين الحالة.
• ويمكن للشبكة أن تنكسر.

كل هذه النقاط سأأخذها في الاعتبار في التقرير.

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

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

لذا ، كان هناك ملف ، دعنا نذهب للتعامل مع ما حدث.

وهنا نحن مهتمون عندما حدث الملف. أي أننا مهتمون بهذه اللحظة التي تغيرت فيها حالة الكتلة.

لكن الملف لا يكون دائمًا فوريًا ، أي أنه لا يستغرق أي وحدة زمنية ، ويمكن أن يتأخر. يمكن أن تكون طويلة الأمد.

لذلك ، له وقت بدء ووقت انتهاء ، أي أنه حدث مستمر. ونقسم كل الأحداث إلى ثلاث فترات: لدينا وقت قبل الملف وأثناء الملف وبعده. وهذا يعني أننا نعتبر جميع الأحداث في هذا الجدول الزمني.

وأول شيء ، عندما حدث الملف ، نبحث عن سبب ما حدث ، وما هو سبب ما أدى إلى الملف.

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

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

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

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

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

بعد مرور بعض الوقت ، عندما خفت العبء ، تمكن Patroni الخاص بنا من التواصل مع العملاء مرة أخرى. استؤنف العمل الطبيعي. وأصبح نفس الخادم Pgdb-2 هو الخادم الرئيسي مرة أخرى. أي أنه كان هناك قلب صغير ، بسبب استقالة العقدة من صلاحيات السيد ، ثم استعادتها مرة أخرى ، أي ، عاد كل شيء كما كان.

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

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

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

كخيار ، يمكنك تحريف المعلمات ttl ، loop_wait ، retry_timeout ، أي محاولة النجاة من قمم التحميل قصيرة المدى هذه عن طريق زيادة هذه المعلمات. لكن هذا ليس الخيار الأنسب ، لأن هذا الحمل يمكن أن يكون طويلاً في الوقت المناسب. وسنتجاوز حدود هذه المعايير ببساطة. وهذا قد لا يساعد حقا.

المشكلة الأولى ، كما تفهم ، بسيطة. أخذنا DCS ووضعناه مع القاعدة ، لدينا مشكلة.

المشكلة الثانية تشبه الأولى. إنه مشابه من حيث أننا نواجه مرة أخرى مشاكل التشغيل البيني مع نظام DCS.

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

يصبح المعلم القديم نسخة طبق الأصل ، وهنا يعمل باتروني ، كما ينبغي أن يكون. يتم تشغيله pg_rewind لإرجاع سجل المعاملات ثم الاتصال بالسيد الجديد للحاق بالسيد الجديد. هنا يعمل باتروني كما ينبغي.

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

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

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

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

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

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

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

هناك خيارات:

• إن أبسط خيار مكتوب ، في رأيي ، حتى في الوثائق ، هو تعطيل عمليات التحقق من القنصل ، أي تمرير مصفوفة فارغة. ونخبر وكيل القنصل بعدم استخدام أي شيكات. من خلال هذه الفحوصات ، يمكننا تجاهل عواصف الشبكة هذه وعدم بدء ملف.
• خيار آخر هو التحقق مرتين من raft_multiplier. هذه معلمة لخادم القنصل نفسه. بشكل افتراضي ، يتم تعيينه على 5. هذه القيمة موصى بها من قبل الوثائق لبيئات التدريج. في الواقع ، هذا يؤثر على وتيرة الرسائل بين أعضاء شبكة القنصل. في الواقع ، تؤثر هذه المعلمة على سرعة اتصال الخدمة بين أعضاء كتلة القنصل. وبالنسبة للإنتاج ، يوصى بالفعل بتقليله بحيث تتبادل العقد الرسائل في كثير من الأحيان.
• هناك خيار آخر توصلنا إليه وهو زيادة أولوية عمليات القنصل من بين العمليات الأخرى لجدولة عمليات نظام التشغيل. هناك معلمة "لطيفة" ، فهي تحدد فقط أولوية العمليات التي يأخذها برنامج جدولة نظام التشغيل في الاعتبار عند الجدولة. لقد قمنا أيضًا بتخفيض القيمة اللطيفة لوكلاء القنصل ، أي زيادة الأولوية بحيث يمنح نظام التشغيل عمليات القنصل مزيدًا من الوقت للعمل وتنفيذ التعليمات البرمجية الخاصة بهم. في حالتنا ، هذا حل مشكلتنا.
• خيار آخر هو عدم استخدام القنصل. لدي صديق مؤيد كبير لـ Etcd. ونحن نتجادل معه بانتظام أيهما أفضل إتجه أم قنصل. ولكن من حيث أيهما أفضل ، عادة ما نتفق معه على أن القنصل لديه وكيل يجب أن يعمل على كل عقدة مع قاعدة بيانات. أي أن تفاعل Patroni مع مجموعة القنصل يمر من خلال هذا الوكيل. ويصبح هذا الوكيل عنق الزجاجة. إذا حدث شيء ما للوكيل ، فلن يعد بإمكان Patroni العمل مع مجموعة القنصل. هذه هي المشكلة. لا يوجد وكيل في خطة Etcd. يمكن لـ Patroni العمل مباشرة مع قائمة من خوادم Etcd والتواصل معهم بالفعل. في هذا الصدد ، إذا كنت تستخدم Etcd في شركتك ، فمن المحتمل أن تكون Etcd خيارًا أفضل من القنصل. لكننا في عملائنا مقيدون دائمًا بما يختاره العميل ويستخدمه. ولدينا في الغالب قنصل لجميع العملاء.
• والنقطة الأخيرة هي مراجعة قيم المعلمات. يمكننا رفع هذه المعايير على أمل أن تكون مشاكل الشبكة قصيرة المدى لدينا قصيرة ولا تقع خارج نطاق هذه المعلمات. بهذه الطريقة يمكننا تقليل عدوانية Patroni إلى التوصيف التلقائي في حالة حدوث بعض مشاكل الشبكة.

أعتقد أن الكثيرين ممن يستخدمون باتروني يعرفون هذا الأمر.

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

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

في هذه الحالة ، أصبحت النسخة المتماثلة الثانية هي النسخة الرئيسية. كل شيء هنا.

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

في هذه الحالة ، ليس لدينا سجل معاملات ولا يمكن بدء النسخة المتماثلة. وفقًا لذلك ، قمنا بإيقاف Postgres بخطأ. وبالتالي فهي ليست في الكتلة.

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

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

ما هي الخيارات؟

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

ولكن هناك مشكلة هنا ، أنه عندما ينتقل السيد إلى النسخة المتماثلة ، فإنه يحذف الفتحات ويحذف مقاطع WAL مع الفتحات. وللتخلص من هذه المشكلة ، قررنا رفع المعامل wal_keep_segments. يتم تعيينه افتراضيًا إلى 8 شرائح. قمنا برفعها إلى 1 وبحثنا في مقدار المساحة الخالية التي لدينا. وتبرعنا بـ 000 جيجا للحفظ والقطع. أي عند التبديل ، لدينا دائمًا احتياطي يبلغ 16 جيجا بايت من سجلات المعاملات على جميع العقد.

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

لدينا قاعدة إنتاج. هناك بالفعل مشاريع قيد التنفيذ.

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

يقول فريق المنتج إنه يجب أن تكون هناك بعض البيانات ، لكننا نراها من مصدر واحد ، لكننا لا نراها في قاعدة البيانات. وعلينا أن نفهم ما حدث لهم.

من الواضح أن pg_rewind قد فاتهم. لقد فهمنا ذلك على الفور ، لكننا ذهبنا لنرى ما كان يحدث.

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

تم إعادة تشغيل سيدنا القديم. وتم تسجيل باتروني في التشغيل التلقائي. إطلاق Patroni. ثم بدأ Postgres. بتعبير أدق ، قبل بدء Postgres وقبل جعله نسخة طبق الأصل ، أطلق Patroni عملية pg_rewind. وفقًا لذلك ، قام بمسح جزء من سجلات المعاملات وتنزيل سجلات جديدة وتوصيلها. هنا عمل باتروني بذكاء ، كما هو متوقع. تمت استعادة الكتلة. كان لدينا 3 عقد ، بعد العقد 3 - كل شيء رائع.

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

نحتاج إلى إيجاد الموضع في سجل المعاملات حيث توقف السيد القديم. في هذه الحالة ، هذه هي العلامة. ونحتاج إلى علامة ثانية ، أي المسافة التي يختلف بها المعلم القديم عن الجديد.

نأخذ الفرق المعتاد في pg_wal_lsn ونقارن بين هاتين العلامتين. وفي هذه الحالة ، نحصل على 17 ميغا بايت. كثيرًا أو قليلًا ، الجميع يقرر بنفسه. لأن 17 ميغا ليست كبيرة بالنسبة لشخص ما ، فهي كثيرة وغير مقبولة بالنسبة لشخص ما. هنا ، يقرر كل فرد بنفسه وفقًا لاحتياجات العمل.

لكن ما الذي اكتشفناه لأنفسنا؟

أولاً ، يجب أن نقرر بأنفسنا - هل نحتاج دائمًا إلى Patroni لبدء التشغيل التلقائي بعد إعادة تشغيل النظام؟ غالبًا ما يحدث أنه يتعين علينا الذهاب إلى المعلم القديم ، ونرى إلى أي مدى قد ذهب. ربما تفقد أجزاء من سجل المعاملات ، وانظر ما هو موجود. ولفهم ما إذا كان بإمكاننا فقد هذه البيانات أو ما إذا كنا بحاجة إلى تشغيل النظام الرئيسي القديم في الوضع المستقل لسحب هذه البيانات.

وفقط بعد ذلك يجب أن نقرر ما إذا كان بإمكاننا تجاهل هذه البيانات أو يمكننا استعادتها ، وربط هذه العقدة كنسخة متماثلة إلى مجموعتنا.

بالإضافة إلى ذلك ، هناك معلمة "max_lag_on_failover". بشكل افتراضي ، إذا كانت ذاكرتي تخدمني ، فإن قيمة هذه المعلمة هي 1 ميغا بايت.

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

ولكن هناك مشكلة تتمثل في أن تأخر النسخ المتماثل في مجموعة Patroni و DCS يتم تحديثه في فترة زمنية معينة. أعتقد أن 30 ثانية هي القيمة الافتراضية ttl.

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

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

وهناك أخبار جيدة. عندما يتقدم السيد القديم ، يمكنه المضي قدمًا بسبب بعض العمليات في الخلفية. أي أنه كان هناك نوع من الفراغ التلقائي ، فقد كتب البيانات وحفظها في سجل المعاملات. ويمكننا بسهولة تجاهل هذه البيانات وفقدانها. لا توجد مشكلة في هذا.

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

هنا لدينا فريق منتج كتب أن منتجهم يواجه مشاكل مع Postgres. في الوقت نفسه ، لا يمكن الوصول إلى المعلم نفسه ، لأنه غير متوفر عبر SSH. ولا يحدث ملف التعريف التلقائي أيضًا.

تم إجبار هذا المضيف على إعادة التشغيل. بسبب إعادة التشغيل ، حدث ملف تلقائي ، على الرغم من أنه كان من الممكن عمل ملف تلقائي يدوي ، كما أفهم الآن. وبعد إعادة التشغيل ، سنرى بالفعل ما كان لدينا مع السيد الحالي.

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

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

نظرنا في نظام dmesg (سجل النواة). ورأينا أن لدينا مشاكل مع أحد الأقراص. كان النظام الفرعي للقرص هو برنامج Raid. نظرنا إلى / proc / mdstat ورأينا أننا فقدنا محرك أقراص واحد. أي أن هناك غارة مكونة من 8 أقراص ، ونفتقد أحدها. إذا نظرت بعناية إلى الشريحة ، يمكنك أن ترى في الإخراج أنه ليس لدينا sde هناك. عندنا ، من الناحية المشروطة ، انقطع القرص. أدى هذا إلى حدوث مشكلات بالقرص ، كما واجهت التطبيقات مشكلات عند العمل مع مجموعة Postgres.

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

وكان هناك مثل هذا التفكير - هل يمكن أن تساعدنا المبارزة أو برامج المراقبة؟ اعتقدنا أنه بالكاد سيساعدنا في هذه الحالة ، لأنه أثناء المشاكل استمر باتروني في التفاعل مع مجموعة DCS ولم ير أي مشكلة. أي ، من وجهة نظر DCS و Patroni ، كان كل شيء على ما يرام مع الكتلة ، على الرغم من وجود مشاكل في القرص في الواقع ، كانت هناك مشاكل في توفر قاعدة البيانات.

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

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

وكيف بدأ كل هذا؟ بدأت ، كما في المشكلة السابقة ، بفرامل قرصية. لقد ارتكبنا لمدة ثانيتين.

كان هناك انقطاع في الاتصالات ، أي تمزق العملاء.

كانت هناك عوائق متفاوتة الخطورة.

وبالتالي ، فإن النظام الفرعي للقرص لا يستجيب بشكل كبير.

والشيء الأكثر غموضًا بالنسبة لي هو طلب الإغلاق الفوري الذي وصل. يحتوي Postgres على ثلاثة أوضاع للإغلاق:

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

من أرسل هذه الإشارة؟ عمليات الخلفية في Postgres لا ترسل مثل هذه الإشارات إلى بعضها البعض ، أي إنها kill-9. إنهم لا يرسلون مثل هذه الأشياء إلى بعضهم البعض ، بل يتفاعلون فقط مع مثل هذه الأشياء ، أي أن هذه إعادة تشغيل طارئة لـ Postgres. من أرسلها ، لا أعرف.

نظرت إلى الأمر "الأخير" ورأيت شخصًا واحدًا قام أيضًا بتسجيل الدخول إلى هذا الخادم معنا ، لكنني كنت خجولًا جدًا بحيث لا يمكنني طرح سؤال. ربما كان قتل -9. كنت أرى القتل -9 في السجلات ، لأن يقول Postgres أن الأمر استغرق قتل -9 ، لكنني لم أره في السجلات.

بالنظر إلى أبعد من ذلك ، رأيت أن Patroni لم يكتب إلى السجل لفترة طويلة جدًا - 54 ثانية. وإذا قارنا طوابع زمنية ، فلن تكون هناك رسائل لمدة 54 ثانية تقريبًا.

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

لدينا نسخة طبق الأصل التي أصبحت سيدًا. وهناك رد ثان. وكانت هناك مشاكل في النسخة المتماثلة الثانية. حاولت إعادة التشكيل. كما أفهمها ، حاولت تغيير recovery.conf وإعادة تشغيل Postgres والاتصال بالسيد الجديد. إنها تكتب رسائل كل 10 ثوانٍ تحاول القيام بها ، لكنها لا تنجح.

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

في مرحلة ما ، نجحت ، لكن النسخ المتماثل لم يبدأ.

تخميني الوحيد هو أنه كان هناك عنوان رئيسي قديم في recovery.conf. وعندما ظهر سيد جديد ، لا تزال النسخة المتماثلة الثانية تحاول الاتصال بالسيد القديم.

عندما بدأ Patroni العمل على النسخة المتماثلة الثانية ، بدأت العقدة في العمل ولكنها لم تتمكن من التكرار. وتم تشكيل تأخر في النسخ ، والذي بدا شيئًا كهذا. وهذا يعني أن العقد الثلاثة كانت في مكانها الصحيح ، لكن العقدة الثانية تخلفت عن الركب.

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

وهنا أخطأت. كان علي أن آتي وأرى ما كان في recovery.conf لاختبار فرضيتي القائلة بأننا كنا على اتصال بالسيد الخطأ. ولكن بعد ذلك كنت أتعامل مع هذا ولم يخطر ببالي ، أو رأيت أن النسخة المتماثلة كانت متخلفة ويجب إعادة تعبئتها ، أي أنني عملت بطريقة ما بلا مبالاة. كان هذا مفاصلي.

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

بدأ النسخ المتماثل. ولكن بعد دقيقة سقطت بسبب خطأ مفاده أن سجلات المعاملات ليست مناسبة لها.

اعتقدت أنني سأعيد التشغيل مرة أخرى. أعدت تشغيل Patroni مرة أخرى ، ولم أقم بإعادة تشغيل Postgres ، لكنني أعدت تشغيل Patroni على أمل أن يبدأ قاعدة البيانات بطريقة سحرية.

بدأ النسخ المتماثل مرة أخرى ، لكن العلامات الموجودة في سجل المعاملات كانت مختلفة ، ولم تكن مماثلة لمحاولة البدء السابقة. توقف النسخ المتماثل مرة أخرى. وكانت الرسالة مختلفة قليلاً بالفعل. ولم تكن مفيدة للغاية بالنسبة لي.

ثم يحدث لي - ماذا لو قمت بإعادة تشغيل Postgres ، في هذا الوقت أقوم بعمل نقطة تفتيش على المعلم الحالي لتحريك النقطة في سجل المعاملات إلى الأمام قليلاً بحيث يبدأ التعافي من لحظة أخرى؟ بالإضافة إلى ذلك ، لا يزال لدينا مخزون من WAL.

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

هذه المشكلة بالنسبة لي هي واحدة من أكثر المشاكل غموضًا ، والتي ما زلت أحيرها بشأن ما حدث بالفعل هناك.

ما هي الآثار هنا؟ يمكن أن يعمل Patroni على النحو المنشود وبدون أي أخطاء. لكن في الوقت نفسه ، لا يعد هذا ضمانًا بنسبة 100٪ أن كل شيء على ما يرام معنا. قد تبدأ النسخة المتماثلة ، لكنها قد تكون في حالة شبه عاملة ، ولا يمكن للتطبيق العمل مع هذه النسخة المتماثلة ، لأنه ستكون هناك بيانات قديمة.

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

وبينما نتطرق إلى هذه القضايا ، سأقدم توصيات. حاولت دمجها في شريحتين. ربما ، يمكن دمج كل القصص في شريحتين وقصها فقط.

عند استخدام Patroni ، يجب أن يكون لديك مراقبة. يجب أن تعرف دائمًا وقت حدوث ملف تعريف تلقائي ، لأنه إذا كنت لا تعرف أن لديك ملف تعريف تلقائي ، فلا يمكنك التحكم في المجموعة. وهذا سيء.

بعد كل ملف ، يتعين علينا دائمًا التحقق يدويًا من الكتلة. نحتاج إلى التأكد من أن لدينا دائمًا عددًا محدثًا من النسخ المتماثلة ، ولا يوجد تأخير في النسخ المتماثل ، ولا توجد أخطاء في السجلات المتعلقة بالنسخ المتماثل المتدفق ، مع Patroni ، مع نظام DCS.

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

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

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

ما هي الأساليب التي اتبعتها؟ أولاً ، أنظر دائمًا عند وصول المدون. وهذا بالنسبة لي نقطة تحول. ألقي نظرة على ما حدث قبل الملف وأثناءه وبعده. يحتوي ملف التعليق على علامتين: هذا هو وقت البدء ووقت الانتهاء.

بعد ذلك ، أبحث في السجلات عن الأحداث قبل الملف ، والتي سبقت المدون ، أي أبحث عن أسباب حدوث الملف.

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

وأين ننظر عادة؟ انا انظر:

• أولاً ، إلى سجلات باتروني.
• بعد ذلك ، ألقي نظرة على سجلات Postgres ، أو سجلات DCS ، اعتمادًا على ما تم العثور عليه في سجلات Patroni.
• كما تقدم سجلات النظام في بعض الأحيان فهمًا لما تسبب في إنشاء الملف.

ما هو شعوري تجاه باتروني؟ لدي علاقة جيدة جدا مع باتروني. في رأيي ، هذا هو أفضل ما يوجد اليوم. أنا أعرف العديد من المنتجات الأخرى. هذه هي Stolon و Repmgr و Pg_auto_failover و PAF. 4 أدوات. حاولت كل منهم. باتروني هو المفضل لدي.

إذا سألوني: "هل أوصي باتروني؟". سأقول نعم ، لأنني أحب باتروني. وأعتقد أنني تعلمت كيف أطبخها.

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

هناك بعض القصص الشيقة عن أشخاص يطلقون النار على أقدامهم. مليء بالمعلومات. تقرأ وتفهم أنه ليس من الضروري القيام بذلك. أنا علامة نفسي.

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

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

هذا كل شئ. اذا لديك سؤال، اسأل.

الأسئلة

شكرا على التقرير! إذا كنت لا تزال بحاجة إلى البحث بعناية شديدة بعد أحد الملفات ، فلماذا نحتاج إلى ملف تلقائي؟

لأنها أشياء جديدة. لقد كنا معها لمدة عام فقط. من الأفضل أن تكون آمنًا. نريد أن نأتي ونرى أن كل شيء يعمل بالفعل بالطريقة التي ينبغي أن يكون. هذا هو مستوى عدم ثقة الكبار - من الأفضل إعادة التحقق والاطلاع.

على سبيل المثال ، ذهبنا في الصباح ونظرنا ، أليس كذلك؟

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

شكرا لك!

شكرا جزيلا على القصة الرائعة! إذا قمنا بنقل مجموعة DCS في مكان ما بعيدًا عن مجموعة Postgres ، فحينئذٍ تحتاج هذه المجموعة أيضًا إلى الصيانة بشكل دوري؟ ما هي أفضل الممارسات التي تحتاج إلى إيقاف تشغيل بعض أجزاء مجموعة DCS ، والشيء الذي يجب القيام به معهم ، وما إلى ذلك؟ كيف يبقى هذا الهيكل كله على قيد الحياة؟ وكيف تفعل هذه الأشياء؟

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

بمعنى ، هل فهمت بشكل صحيح أنني بحاجة إلى تعطيل Patroni وتعطيل الملف وتعطيل كل شيء قبل القيام بأي شيء مع المضيفين؟

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

شكرا جزيلا!

شكرا جزيلا لتقريرك! كيف يشعر فريق المنتج حيال فقدان البيانات؟

لا تهتم فرق المنتج ، ويخشى قادة الفريق.

ما هي الضمانات الموجودة؟

الضمانات صعبة للغاية. الكسندر كوكوشكين لديه تقرير "كيفية حساب RPO و RTO" ، أي وقت الاسترداد ومقدار البيانات التي يمكن أن نخسرها. أعتقد أننا بحاجة إلى العثور على هذه الشرائح ودراستها. بقدر ما أتذكر ، هناك خطوات محددة حول كيفية حساب هذه الأشياء. كم عدد المعاملات التي يمكن أن نخسرها ، وكم البيانات التي يمكن أن نخسرها. كخيار ، يمكننا استخدام النسخ المتزامن على مستوى Patroni ، لكن هذا سيف ذو حدين: إما أن يكون لدينا موثوقية البيانات ، أو نفقد السرعة. يوجد نسخ متزامن ، ولكنه أيضًا لا يضمن حماية بنسبة 100٪ ضد فقدان البيانات.

أليكسي ، شكرا للتقرير الرائع! هل لديك خبرة في استخدام Patroni للحماية من المستوى الصفري؟ هذا هو ، بالاقتران مع الاستعداد المتزامن؟ هذا هو السؤال الأول. والسؤال الثاني. لقد استخدمت حلولًا مختلفة. استخدمنا Repmgr ، ولكن بدون برنامج autofiler ، والآن نخطط لتضمين autofiler. ونعتبر باتروني حلاً بديلاً. ماذا يمكنك أن تقول كمزايا مقارنة بـ Repmgr؟

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

فيما يتعلق بالسؤال الثاني ، فقد استخدمنا Repmgr وما زلنا نفعل مع بعض العملاء لأسباب تاريخية. ماذا يمكن ان يقال؟ يأتي Patroni مع مُحرّر تلقائي خارج الصندوق ، ويأتي Repmgr مع مُحرّر تلقائي كميزة إضافية تحتاج إلى التمكين. نحتاج إلى تشغيل البرنامج الخفي Repmgr على كل عقدة ومن ثم يمكننا تكوين autofiler.

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

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

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

بشكل تقريبي ، يصبح DCS خدمة لنا لا تقل أهمية عن القاعدة نفسها؟

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

شكرا لك!

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