ترحيل سلس (تقريبًا) بين إصدارات PostgreSQL الرئيسية باستخدام النسخ المتماثل المنطقي

في True Engineering ، في مشروع واحد ، أصبحت الحاجة لتغيير إصدار PostgreSQL من 9.6 إلى 11.1.

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

لذلك ، تقرر ، نحن نهاجر. بالطبع ، يمكنك رفع نسخة جديدة من خادم PostgreSQL بالتوازي مع القديم ، وإيقاف التطبيق ، واستخدام تفريغ / استعادة (أو pg_upgrade) لنقل قاعدة البيانات ، وبدء التطبيق مرة أخرى. لم يناسبنا هذا الحل بسبب الحجم الكبير للقاعدة ، بالإضافة إلى ذلك ، يعمل التطبيق في وضع القتال ، ولا يوجد سوى بضع دقائق للتوقف.

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

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



TL ؛ د

• تحول كل شيء (لا يخلو من العكازات ، مقال عنها).
• يمكنك الترحيل داخل إصدار PostgreSQL من 9.4 إلى 11.x ، من أي إصدار إلى أي ، إلى أسفل أو لأعلى.
• يساوي وقت التوقف عن العمل الوقت الذي يستغرقه التطبيق الخاص بك لإعادة الاتصال بخادم قاعدة البيانات الجديد (في حالتنا ، كانت إعادة تشغيل التطبيق بالكامل ، ولكن بشكل واضح ، "الخيارات الممكنة").

لماذا لم يناسبنا حل "الجبهة"؟

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

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

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

معلومات عامة

pglogical هو نظام تكرار منطقي يستخدم فك التشفير المنطقي الأصلي في PostgreSQL ويتم تنفيذه كملحق PostgreSQL. يتيح لك تكوين النسخ المتماثل الانتقائي باستخدام نموذج الاشتراك / النشر. لا يتطلب إنشاء مشغلات في قاعدة البيانات أو استخدام أي أدوات مساعدة خارجية للنسخ المتماثل.

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

إعداد النسخ المتماثل يدويًا باستخدام pglogical يدويًا ليس تافهًا للغاية ، على الرغم من أنه من حيث المبدأ من الممكن تمامًا. لحسن الحظ ، هناك أداة مساعدة لجهة خارجية pgrepup لأتمتة عملية التكوين ، والتي سوف نستخدمها.

مذكرة مساحة القرص

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

في حالتنا ، كانت تعديلات قاعدة البيانات مطلوبة ، بالإضافة إلى تنسيق التخزين أثناء الترحيل ما بين 9.6 و 11 "تضخم" ليس لصالح الإصدار الأخير ، لذلك كان لا بد من زيادة مساحة القرص ليس 2 ، ولكن بنحو 2.2 مرة. الحمد LVM ، ويمكن القيام بذلك في عملية الهجرة على الطاير.

بشكل عام ، تعتني به.

تثبيت PostgreSQL 11 على ماجستير

ملاحظة: نستخدم Oracle Linux ، وسيتم توضيح كل ما يلي لهذا التوزيع. من المحتمل أن تتطلب توزيعات Linux الأخرى مراجعة صغيرة مع ملف ، لكن من غير المحتمل أن تكون كبيرة.

#   yum install https://download.postgresql.org/pub/repos/yum/11/redhat/rhel-7-x86_64/pgdg-oraclelinux11-11-2.noarch.rpm #   postgresql11 yum install postgresql11 postgresql11-devel postgresql11-server postgresql11-contrib #   /usr/pgsql-11/bin/postgresql-11-setup initdb 

يقع datadir القديم في /var/lib/pgsql/9.6/data ، الجديد في / var / lib / pgsql / 11 / data

انسخ إعدادات الوصول ( pg_hba.conf ) وإعدادات الخادم ( postgresql.conf ) من 9.6 إلى 11.

لتشغيل خادمي PostgreSQL على نفس الجهاز ، في تهيئة تهيئة postgresql.conf 11 ، قم بتغيير المنفذ إلى 15432 (المنفذ = 15432).

هنا ، عليك أن تفكر مليا في ما تحتاج إلى فعله في الإصدار الجديد من PostgreSQL على وجه التحديد في حالتك ، بحيث يبدأ بـ postgresql.conf (ويمكن أن يعمل التطبيق الخاص بك في النهاية). في حالتنا ، كان مطلوبًا تثبيت ملحقات PostgreSQL المستخدمة من قبلنا في الإصدار الجديد. هذا خارج نطاق المقالة ، فقط اجعل PostgreSQL الجديد يبدأ العمل ، ويتناسب معك تمامًا :)

 #  ,  ,  shared libraries, whatever... # .... #  systemctl enable postgresql-11 systemctl start postgresql-11 

نحن ننظر / var / lib / pgsql / 11 / data / pg_log / . هل كل شيء بخير؟ نواصل!

تثبيت وتكوين pgrepup

 #  python yum install python yum install python2-pip #  pgrepup pip install pgrepup #   pgrepup config 

الفروق الدقيقة:

1. بوصفنا app_owner ، فإننا نحدد المستخدم الذي تعمل بموجبه خوادم PostgreSQL.
2. بالنسبة لقاعدة البيانات ، حدد template1 .
3. اسم المستخدم وكلمة المرور - البيانات للوصول الخارق. في حالتنا ، تم تحديد طريقة الثقة في pg_hba.conf للاتصالات المحلية للمستخدم postgres ، بحيث يمكنك تحديد كلمة مرور تعسفية.

تكوين النسخ المتماثل

 #   pgrepup check 

نحصل على إخراج قائمة بالعديد من المعلمات التي يجب تكوينها على النحو المطلوب.

مثال نتائج التحقق:





يجب إزالة جميع الأخطاء أثناء عملية التحقق. في إعدادات كلا الخادمين يجب تعيين wal_level = LOGICAL (من أجل فك التشفير المنطقي للعمل) ، والإعدادات اللازمة لمحرك النسخ المتماثل (عدد فتحات و wal_senders ). تلميحات الأداة المساعدة pgrepup مفيدة للغاية ؛ لا ينبغي أن تثار الأسئلة في معظم النقاط.

نصنع جميع الإعدادات اللازمة التي يطلبها pgrepup.

في كلا الملفين pg_hba.conf نضيف أذونات للمستخدم الذي سيقوم بالنسخ المتماثل ، كل ذلك في موجه pgrepup:

 host replication pgrepup_replication 127.0.0.1/32 md5 host all pgrepup_replication 127.0.0.1/32 md5 

إضافة المفاتيح الأساسية

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

في حالتنا ، PK لم يكن في كل مكان ، لذلك ، في وقت النسخ المتماثل ، تحتاج إلى إضافته ، وفي نهاية النسخ المتماثل ، إذا لزم الأمر ، احذفه.

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

 ALTER TABLE %s ADD COLUMN temporary_pk BIGSERIAL NOT NULL PRIMARY KEY 

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

تثبيت ملحق pglogical

يمكن العثور على تعليمات تثبيت الامتداد هنا . يجب تثبيت الامتداد على كلا الخادمين.

 #       curl https://access.2ndquadrant.com/api/repository/dl/default/release/9.6/rpm | bash curl https://access.2ndquadrant.com/api/repository/dl/default/release/11/rpm | bash #   yum install postgresql96-pglogical postgresql11-pglogical 

إضافة تحميل المكتبة في postgresql.conf من كلا الخادمين:

 shared_preload_libraries = 'pglogical' 

تثبيت ملحق pgl_ddl_deploy

هذا ملحق مساعد يستخدمه pgrepup للنسخ المتماثل المنطقي لـ DDL.

 #      git clone https://github.com/enova/pgl_ddl_deploy.git #       PATH=/usr/pgsql-9.6/bin/:$PATH USE_PGXS=1 make USE_PGXS=1 make install make clean #       PATH=/usr/pgsql-11/bin/:$PATH make CLANG=true make install 

إضافة تحميل المكتبة في postgresql.conf من كلا الخادمين:

 shared_preload_libraries = 'pglogical,pgl_ddl_deploy' 

التحقق من التغييرات

 #   postgresql systemctl restart postgresql-11 

الآن باستخدام pgrepup check أنك بحاجة إلى التأكد من أن كل شيء أصبح pgrepup check مع الخادم الهدف وأن جميع التعليقات المتعلقة بالخادم الهدف قد تم التخلص منها تمامًا.

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

 #  systemctl restart postgresql-9.6 #  pgrepup check 

الآن في إخراج الأمر ، يجب وضع علامة على جميع العناصر على أنها موافق.

يبدو أنه يمكنك بدء الترحيل ، ولكن ...

إصلاح الخلل pgrepup

يوجد العديد من الأخطاء في الإصدار الحالي من pgrepup التي تجعل الترحيل مستحيلًا. تم إرسال طلبات السحب ، ولكن للأسف ، يتم تجاهلها ، لذا سيتعين عليك إجراء التصحيحات يدويًا.

نذهب إلى مجلد تثبيت pgrepup (حالتنا هي /usr/lib/python2.7/site-packages/pgrepup/commands/ ).

افعلها مرة واحدة. في كل ملف * .py ، أضف **kwargs المفقودة في وصف الوظيفة. الصورة أفضل من ألف كلمة:



ارتكب هنا .

هل اثنين. في setup.py نقوم بالبحث عن "sh -c" ، إدخالين ، جميع أوامر shell متعددة الأسطر تحتاج إلى أن تكون سطرًا واحدًا.

ارتكب هنا .

ابدأ الترحيل

 #  pgrepup setup 

باستخدام هذا الأمر ، يقوم إعداد pgrepup بإعداد كلا الخادمين لبدء النسخ المتماثل ، وإنشاء مستخدم ، وتكوين pglogical ، ونقل مخطط قاعدة البيانات.

 #   pgrepup start 

قال ، "دعنا نذهب!" ولوح بيده:



النسخ المتماثل قيد التشغيل. يمكن رؤية الموقف الحالي باستخدام الأمر pgrepup status :



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

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

 SELECT * FROM pg_replication_origin_status ORDER BY remote_lsn DESC; SELECT *,pg_xlog_location_diff(s.sent_location,s.replay_location) byte_lag FROM pg_stat_replication s; SELECT query FROM pg_stat_activity WHERE application_name='subscription_copy' 

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



وهذا يعني أن الوقت قد حان لإعداد العبد الجديد.

تثبيت PostgreSQL 11 على الرقيق

هنا كل شيء بسيط وحسب الكتاب المدرسي ، لا توجد فروق دقيقة.

 #   yum install https://download.postgresql.org/pub/repos/yum/11/redhat/rhel-7-x86_64/pgdg-oraclelinux11-11-2.noarch.rpm #  postgresql 11 yum install postgresql11 postgresql11-devel postgresql11-server postgresql11-contrib #      su - postgres pg_basebackup -h db-master.hostname -p 15432 -D /var/lib/pgsql/11/data/ -R -P -U replication -X stream -c fast 

انسخ إعدادات الوصول ( pg_hba.conf ) وإعدادات الخادم ( postgresql.conf ) من 9.6 إلى 11. في تهيئة postgresql.conf 11 ، قم بتغيير المنفذ إلى 15432 (المنفذ = 15432)

 #  systemctl enable postgresql-11 systemctl start postgresql-11 

 #     Master SELECT *,pg_wal_lsn_diff(s.sent_lsn,s.replay_lsn) AS byte_lag FROM pg_stat_replication s; #     Slave SELECT now()-pg_last_xact_replay_timestamp(); 

المجاميع الفرعية

بعد كل هذه الإجراءات ، نحصل على نظام النسخ المتماثل الصعب هذا:



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

تبديل التطبيق إلى الإصدار الجديد من PostgreSQL

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

للمتعة ، سوف نقوم بالرد على كلا السؤالين "نعم" والمضي قدما.

نوقف التطبيق.

 # ,   , : SELECT * FROM pg_stat_activity; 

 #    #       sequences. pgrepup stop 

 #      pgrepup uninstall 

 #  master: #    systemctl disable postgresql-9.6 #   ,  ,  . systemctl stop postgresql-9.6 systemctl stop postgresql-11 #  slave: #    systemctl disable postgresql-9.6 #   ,  ,  . systemctl stop postgresql-9.6 systemctl stop postgresql-11 

نرجع المنفذ القياسي في التكوين postgresql.conf من الإصدار الجديد إلى Master and Slave.

على Slave الجديد ، نقوم أيضًا بتغيير المنفذ إلى المنفذ القياسي في recovery.conf .

على طول الطريق ، هناك اقتراح من الخطيئة لمزيد من تغيير المنفذ على أن يصبح الإصدار القديم غير نشط:
نحن نكشف عن المنفذ غير القياسي في postgresql.conf من الإصدار القديم إلى Master and Slave.
على Slave القديم ، نقوم أيضًا بتغيير المنفذ إلى منفذ غير قياسي في recovery.conf .

 #   master systemctl enable postgresql-11 systemctl start postgresql-11 #   slave: systemctl enable postgresql-11 systemctl start postgresql-11 

تحقق من السجلات.

تحقق من حالة النسخ المتماثل على Master.

 SELECT *,pg_wal_lsn_diff(s.sent_lsn,s.replay_lsn) AS byte_lag FROM pg_stat_replication s; 

نطلق التطبيق. نحن سعداء لمدة نصف ساعة.

وأخيرا ، أدب مفيد حول هذا الموضوع:

• pglogical
• تعليمات التثبيت ل pglogical
• مستندات pglogical
• ترقية PostgreSQL من 9.4 إلى 10.3 باستخدام pglogical
• pgrepup - ترقية PostgreSQL باستخدام النسخ المتماثل المنطقي
• pgrepup - PostgreSQL تكرار وترقية
• ترقية PostgreSQL من 9.6 إلى 10 مع الحد الأدنى من التوقف باستخدام pglogical

حظا سعيدا