آسف ، لقد كسرت الانتعاش الخاص بك

في PostgreSQL منذ الأزمنة القديمة للغاية بالفعل الإصدار 8.0 الذي تم إصداره مرة أخرى في عام 2005 ، تم استخدام ملف التكوين الخاص recovery.conf للاستعادة إلى نقطة زمنية محددة. فيما بعد بدأ استخدام نفس الملف لوضع الاستعداد وتكرار النسخ.

ومع ذلك ، منذ الإصدار التالي من PostgreSQL 12 ، لن يعمل recovery.conf بعد الآن: لقد كسرته.
لكن لماذا؟

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

بعد إعادة التشغيل المجدولة التالية للنسخ المتماثلة ، فقط بسبب الحاجة إلى تغيير معلمات النسخ المتماثل ، قررت استلامها ، ولكن ما هي تكلفة تعليم PostgreSQL لإعادة قراءة primary_conninfo في SIGHUP؟ كل شيء تحول بشكل سيء. من حيث المبدأ ، تحتاج إلى تغيير متغير واحد فقط في عملية بدء التشغيل ومن هناك طلب إعادة تشغيل WalReceiver - وهذا كل شيء ، سيستمر النسخ المتماثل مع العنوان الجديد بشكل صحيح. يبقى لتنفيذ هذا بشكل صحيح. بعد بضعة أسابيع ، أنهيت التصحيح من خلال تطبيق re-reading recovery.conf على إشارة SIGHUP ، في حين أن هذا التصحيح لم يكسر سلوك قاعدة البيانات الحالية.

بعد ذلك ، وبعد أن تحلى بالشجاعة ، أرسله إلى القائمة البريدية لمطور PostgreSQL. ما أجابه مايكل باكير بسرعة:

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

عفوًا ، اتضح أنني سألت محرك البحث السؤال الخطأ. لم يكن السؤال حول إعادة قراءة recovery.conf ، ولكن حول تحويل المعلمات من recovery.conf منفصلة إلى البنية التحتية GUC (التكوين الموحد الكبير) المستخدمة لجميع المعلمات DBMS الأخرى. هذا ، بالتأكيد لا ، نحن لسنا بحاجة إلى مثل هذا التصحيح ، نحن لا نريد هذا. لنقم أولاً بنقل جميع هذه الإعدادات من recovery.conf إلى البنية الأساسية للإعدادات القياسية لدينا.

في هذه الأخبار القاتمة ، أحرقت وفكرت: "لكن دعنا ننقل!". قرأت المناقشات المؤرشفة حول استعلام البحث الصحيح ، وفتحت آخر مناقشة تم العثور عليها حول إعدادات النقل (تم التفضل بتقديم الارتباط بواسطة Michael Paquier في إجابته ، وأشكره بشكل منفصل ، وكذلك للإجابة السريعة). في ذلك الوقت ، في مايو 2018 ، تم التخلي عن التصحيح لأكثر من عام. لذلك ، هنا نبدأ. أم أنه من الأصح قول "متابعة"؟ وفقًا لخطة الترفيه:

1. قراءة وقائمة التغييرات إلى أحدث إصدار من التصحيح
2. تحليل التغييرات في التصحيح ونقل ما يلزم إلى الإصدار الحالي من قاعدة الشفرة
3. إصلاح جميع الإشارات إلى recovery.conf ومعلماته في الوثائق
4. اختبارات إصلاح
5. إرسال تصحيح جديد إلى القائمة البريدية
6. الحصول على أي ردود فعل
7. لتصحيح شيء ما وفقًا للرغبات والعودة إلى الفقرة 5
8. لتلقي رفض قبول التصحيح مرة أخرى (في سنة ونصف)

يبدو وكأنه خطة عمل؟ حسنًا ، ها نحن نسير معه!

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

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

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

وبعد بضعة أيام ، أي في 25 نوفمبر من عام 2018 ، وافق بيتر إيسنتراوت حقًا على هذا التصحيح :

يتم الآن ضبط إعدادات الاسترداد في postgresql.conf (أو مصادر GUC الأخرى). حاليا ، جميع الإعدادات المتأثرة هي PGC_POSTMASTER ؛ هذا يمكن صقله في كل حالة على حدة.
يتم الآن بدء الاسترداد بواسطة ملف recovery.signal. يبدأ وضع الاستعداد من خلال ملف standby.signal. اختفى إعداد الاستعداد. إذا تم العثور على ملف recovery.conf ، فسيصدر خطأ.
تمت إعادة تسمية إعداد trigger_file إلى promot_trigger_file كجزء من الحركة.
تم دمج فصل الوثائق "تكوين الاسترداد" في "تكوين الخادم".
pg_basebackup -R الآن بإلحاق الإعدادات إلى postgresql.auto.conf ويقوم بإنشاء ملف standby.signal.
المؤلف: فوجي ماساو <ماساو (نقطة) فوجي (في) جوجل (نقطة) كوم>
المؤلف: سايمون ريجز <سيمون (في) 2nd الربع (نقطة) كوم>
المؤلف: Abhijit Menon-Sen <ams (at) 2nd Quadrant (dot) com>
المؤلف: سيرجي كورنيلوف <sk (at) zsrv (dot) org>

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

إذن ما الذي تغير

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

اختفى إعداد standby_mode القديم. الآن ، بالإضافة إلى حقيقة وجود recovery.conf لتمكين وضع الاسترداد ، يتم استبداله بملفين (من أي محتوى ، وعادةً ما يكون فارغًا):

• PGDATA / recovery.signal - الخليفة الإيديولوجي standby_mode = off ، سيتم تنفيذ الاستعادة من الأرشيف إلى النقطة المحددة في التكوينات ؛
• PGDATA / standby.signal $ - على التوالي ، standby_mode = على. سوف نرى هذا الملف على جميع النسخ المتماثلة.

إذا وجدت عملية بدء تشغيل قاعدة البيانات كلا الملفين ، فإننا نعتبر أننا في وضع الاستعداد.

إذا ، من أجل الوضوح ، للحد من المعلمة يتغير إلى لوحة:

الانتعاش القديم	PostgreSQL 12+ postgresql.conf
primary_conninfo	primary_conninfo
primary_slot_name	primary_slot_name
trigger_file	تعزيز_trigger_file
recovery_min_apply_delay	recovery_min_apply_delay
recovery_target	recovery_target
recovery_target_name	recovery_target_name
recovery_target_time	recovery_target_time
recovery_target_xid	recovery_target_xid
recovery_target_lsn	recovery_target_lsn
recovery_target_inclusive	recovery_target_inclusive
recovery_target_timeline	recovery_target_timeline
recovery_target_action	recovery_target_action
rest_command	rest_command
archive_cleanup_command	archive_cleanup_command
recovery_end_command	recovery_end_command

يمكنك أن ترى أنه قد تم تغيير أقل قليلا من لا شيء. في الوقت الحالي (باستثناء البادئة تعزيز فقط لـ promot_trigger_file) ، تتم تسمية جميع المعلمات الجديدة تمامًا مثل المعلمات القديمة وتأخذ نفس القيم الممكنة. رغم أنه في الواقع لا يزال هناك تغيير فيما يتعلق بإعدادات هدف الاسترداد. لا أعرف ما إذا كان أي شخص قد استخدم هذا من قبل ، ولكنه كان سلوكًا موثقًا وكان من الممكن تحديد عدة recovery_target أو recovery_target_lsn أو recovery_target_name أو recovery_target_time أو recovery_target_xid في نفس الوقت. على سبيل المثال

recovery_target_lsn = '1/1D9FEA00' recovery_target_xid = '5238954' 

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

 recovery_target_lsn = '1/1D9FEA00' recovery_target_lsn = '1/16AC7D0' 

هذا مقبول ، سنستعيد قيمة الإعدادات المحددة أخيرًا.

وبشكل عام ، هذا كل ما يجب قوله حول التغييرات المرئية من خارج PostgreSQL. ظلت pg_basebackup -R (--write-recovery-conf) في مكانها وتفعل ما هو المقصود منها ، الآن فقط ستضيف معلمات إلى postgresql.auto.conf بدلاً من recovery.conf وإنشاء ملف standby.signal

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

لقد نشرت بالفعل تصحيحًا يتيح تغيير primary_conninfo و primary_slot_name أثناء الطيران. دعونا نرى ما يحدث.

آسف ، لقد كسرت الانتعاش الخاص بك

محدث 7 أبريل 2019

في اليوم الأخير قبل تجميد الميزات الإصدار 12 ، يمكنك تلخيص. لم يتم تضمين تغيير إعدادات النسخ المتماثل في الإصدار. بالطبع ، هذه قصة غريبة أيضًا. ذات مرة ، كان تصحيح Simon Riggs الذي اتخذته أساسًا يتضمن تعديلات بالفعل لإعادة تشغيل جهاز الاستقبال عند تغيير إعدادات الاتصال. اخترتها في تصحيح منفصل مع استكمال التوثيق والاختبارات. وبعد 6 تحديثات التصحيح وشهرين من المناقشة ، تظهر الحقيقة الواضحة أنه في حالة إعادة تشغيل جهاز الاستقبال ، ستحاول قاعدة البيانات التبديل إلى استعادة الملفات من restore_command. سلوك جهاز دولة بسيط تمامًا ، يتم تشغيله عن طريق إيقاف تشغيل جهاز الاستقبال لأي سبب. لكن تبين أن هذا "شيء لا نريده". حسنا ، في وقت سابق كان من المستحيل أن أقول؟ حسناً ، لقد قمت بإعادة تصميمه بطريقة ما ، لكن التقويم كان لديه بالفعل الالتزام النهائي بالإصدار 12 ولم يبحث أحد هنا. بشكل عام ، هذا ليس شيئًا سريعًا ، كما تفعل التصحيحات في PostgreSQL. لكن لديّ كل الحق في تضمين نفسي في قائمة الأشخاص بفضلهم الذين أدرجت REINDEX CONCURRENTLY الأكثر ملحمية التي لم تنته بعد في الإصدار 12!

تجدر الإشارة في النهاية إلى أن هناك عددًا من الإعدادات لديها الفرصة للتغيير أثناء التنقل: archive_cleanup_command و promot_trigger_file و recovery_end_command و recovery_min_apply_delay