ترقية قاعدة بيانات PostgreSQL باستخدام التفريغ والاستعادة

ينطبق على: قاعدة بيانات Azure لـ PostgreSQL - خادم واحد

هام

قاعدة بيانات Azure ل PostgreSQL - خادم واحد على مسار التقاعد. نوصي بشدة بالترقية إلى Azure Database for PostgreSQL - Flexible Server. لمزيد من المعلومات حول الترحيل إلى قاعدة بيانات Azure ل PostgreSQL - خادم مرن، راجع ما يحدث لقاعدة بيانات Azure لخادم PostgreSQL الفردي؟.

إشعار

تنطبق المفاهيم الموضحة في هذه الوثائق على كل من Azure Database for PostgreSQL - الخادم الفردي وAzure Database for PostgreSQL - الخادم المرن.

يمكنك ترقية خادم PostgreSQL الموزع في Azure Database for PostgreSQL عن طريق ترحيل قواعد البيانات إلى خادم إصدار رئيسي أعلى باستخدام الأساليب التالية.

• أسلوب دون اتصال باستخدام PostgreSQL pg_dump وpg_restore التي تتحمل وقت تعطل لترحيل البيانات. يعالج هذا المستند أسلوب الترقية/الترحيل هذا.
• أسلوب متصل باستخدام Database Migration Service (DMS). يوفر هذا الأسلوب ترحيلاً لوقت التعطل المخفض ويحافظ على مزامنة قاعدة البيانات الهدف مع المصدر ويمكنك اختيار وقت الإيقاف. ومع ذلك، هناك بعض المتطلبات الأساسية والقيود التي يجب معالجتها لاستخدام DMS. للحصول على التفاصيل، راجع وثائق DMS.
• أسلوب ترقية الإصدار الرئيسي الموضعي باستخدام قاعدة بيانات Azure ل PostgreSQL - خادم مرن. تؤدي ميزة ترقية الإصدار الرئيسي الموضعي إلى ترقية الإصدار الرئيسي للخادم بنقرة واحدة فقط. وهذا يبسط عملية الترقية لتقليل التعطيل للمستخدمين والتطبيقات التي تصل إلى الخادم. الترقيات الموضعية هي طريقة أبسط لترقية الإصدار الرئيسي من المثيل، لأنها تحتفظ باسم الخادم والإعدادات الأخرى للخادم الحالي بعد الترقية، ولا تتطلب ترحيل البيانات أو تغييرات على سلسلة الاتصال التطبيق. الترقيات الموضعية أسرع وتتضمن وقت تعطل أقصر من ترحيل البيانات.

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

قاعدة البيانات/السيناريو	تفريغ/استعادة (دون اتصال)	DMS (متصل)
لديك قاعدة بيانات صغيرة ويمكن أن تتحمل وقت التعطل للترقية	س
قواعد البيانات الصغيرة (< 10 غيغابايت)	X	X
DBs من صغير إلى متوسط (10 غيغابايت – 100 غيغابايت)	X	X
قواعد البيانات الكبيرة (> 100 غيغابايت)		س
يمكن أن تتحمل وقت التعطل للترقية (بغض النظر عن حجم قاعدة البيانات)	س
هل يمكن معالجة المتطلبات الأساسية لـ DMS، بما في ذلك إعادة التشغيل؟		س
هل يمكن تجنب DDLs والجداول غير المسجلة أثناء عملية الترقية؟		س

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

إشعار

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

المتطلبات الأساسية لاستخدام التفريغ والاستعادة مع Azure Database for PostgreSQL

للتنقل عبر هذا الدليل الإرشادي، تحتاج إلى ما يلي:

• خادم قاعدة بيانات PostgreSQL مصدر يشغل إصدارا أقل من المحرك الذي تريد ترقيته.
• خادم قاعدة بيانات PostgreSQL الهدف مع الإصدار الرئيسي المطلوب من خادم Azure Database for PostgreSQL - خادم أحادي أو Azure Database for PostgreSQL - خادم مرن.
• نظام عميل PostgreSQL لتشغيل أوامر التفريغ والاستعادة. يوصى باستخدام إصدار قاعدة البيانات الأعلى. على سبيل المثال، إذا كنت تقوم بالترقية من الإصدار 9.6 من PostgreSQL إلى 11، فالرجاء استخدام عميل PostgreSQL الإصدار 11.
  • يمكن أن يكون عميل Linux أو Windows مثبتًا عليه PostgreSQL ويحتوي على أدوات مساعدة سطر الأوامر pg_dump وpg_restore مثبتة.
  • بدلاً من ذلك، يمكنك استخدام Azure Cloud Shell أو بتحديد Azure Cloud Shell على شريط القوائم في أعلى اليمين في مدخل Azure. سيتعين عليك تسجيل الدخول إلى حسابك az login قبل تشغيل أوامر التفريغ والاستعادة.
• يفضل تشغيل عميل PostgreSQL في نفس المنطقة مثل الخوادم المصدر والهدف.

تفاصيل واعتبارات إضافية

• يمكنك العثور على سلسلة الاتصال بقواعد البيانات المصدر والهدف بتحديد "سلاسل الاتصال" من المدخل.
• قد تقوم بتشغيل أكثر من قاعدة بيانات واحدة في الخادم الخاص بك. يمكنك العثور على قائمة قواعد البيانات عن طريق الاتصال بالخادم المصدر وتشغيل \l.
• إنشاء قواعد بيانات مقابلة في خادم قاعدة البيانات الهدف أو إضافة خيار -C إلى الأمر pg_dump الذي ينشئ قواعد البيانات.
• يجب عدم ترقية azure_maintenance أو قواعد بيانات القالب. إذا قمت بإجراء أي تغييرات على قواعد بيانات القالب، يمكنك اختيار ترحيل التغييرات أو إجراء هذه التغييرات في قاعدة البيانات الهدف.
• راجع الجداول أعلاه لتحديد أن قاعدة البيانات مناسبة لوضع الترحيل هذا.
• إذا كنت ترغب في استخدام Azure Cloud Shell، يرجى ملاحظة أن جلسة العمل تنتهي بعد 20 دقيقة. إذا كان حجم قاعدة البيانات < 10 غيغابايت، فقد تتمكن من إكمال الترقية دون انتهاء مهلة الجلسة. وإلا، قد تضطر إلى إبقاء جلسة العمل مفتوحة بوسائل أخرى، مثل الضغط على أي مفتاح مرة واحدة في 10-15 دقيقة.

مثال على قاعدة البيانات المستخدمة في هذا الدليل

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

الوصف	القيمة
الخادم المصدر(إصدار 9.5)	pg-95.postgres.database.azure.com
قاعدة البيانات المصدر	bench5gb
حجم قاعدة البيانات المصدر	5 جيجابايت
اسم المستخدم المصدر	pg@pg-95
الخادم الهدف (إصدار 11)	pg-11.postgres.database.azure.com
قاعدة بيانات الهدف	bench5gb
اسم المستخدم الهدف	pg@pg-11

إشعار

يدعم الخادم المرن الإصدار 11 من PostgreSQL وما بعده. أيضا، لا يتطلب @dbservernameاسم مستخدم الخادم المرن .

ترقية قواعد البيانات باستخدام أساليب الترحيل دون اتصال

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

• إذا كنت تستخدم نفس كلمة المرور للمصدر وقاعدة البيانات الهدف، يمكنك تعيين PGPASSWORD=yourPassword متغير البيئة. ثم لا يتعين عليك توفير كلمة المرور في كل مرة تقوم فيها بتشغيل أوامر مثل pg_dump، وpg_restore. وبالمثل، يمكنك إعداد متغيرات إضافية مثل PGUSER، وPGSSLMODE وما إلى ذلك، راجع متغيرات بيئة PostgreSQL.

• إذا كان خادم PostgreSQL يتطلب اتصالات TLS/SSL (بشكل افتراضي في خوادم Azure Database for PostgreSQL)، فقم بتعيين متغير بيئة PGSSLMODE=require بحيث تتصل أداة pg_restore بـ TLS. بدون TLS، قد يقرأ الخطأ FATAL: SSL connection is required. Please specify SSL options and retry.

• في سطر الأوامر Windows، قم بتشغيل الأمر SET PGSSLMODE=require قبل تشغيل الأمر pg_restore. في Linux أو Bash، قم بتشغيل الأمر export PGSSLMODE=require قبل تشغيل الأمر pg_restore.

هام

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

ترحيل الأدوار

الأدوار (المستخدمون) هي كائنات عمومية ويجب ترحيلها بشكل منفصل إلى نظام المجموعة الجديد قبل استعادة قاعدة البيانات (قاعدة البيانات). يمكنك استخدام pg_dumpall ثنائي مع خيار -r (--roles-only) لتفريغها. لتفريغ جميع الأدوار باستخدام كلمات المرور من الخادم الفردي المصدر:

pg_dumpall -r --host=mySourceServer --port=5432 --username=myUser@mySourceServer --database=mySourceDB > roles.sql

لتفريغ جميع أسماء الأدوار، دون كلمات مرور من الخادم المرن المصدر:

pg_dumpall -r --no-role-passwords --host=mySourceServer --port=5432 --username=myUser --database=mySourceDB > roles.sql

هام

في قاعدة بيانات Azure ل PostgreSQL - لا يسمح لمستخدمي الخادم المرن بالوصول إلى جدول pg_authid الذي يحتوي على معلومات حول معرفات تخويل قاعدة البيانات مع كلمات مرور المستخدم. لذلك لا يمكن استرداد كلمات المرور للمستخدمين. يرجى التفكير في استخدام Azure Key Vault لتخزين أسرارك بأمان.

حرر roles.sql وأزل مراجع NOSUPERUSER وNOBYPASSRLS قبل استعادة المحتوى باستخدام psql في الخادم الهدف:

psql -f roles.sql --host=myTargetServer --port=5432 --username=myUser --dbname=postgres

لا ينبغي أن يتوقع تشغيل البرنامج النصي التفريغ تماما دون أخطاء. على وجه الخصوص، لأن البرنامج النصي سيصدر CREATE ROLE لكل دور موجود في نظام المجموعة المصدر، فمن المؤكد أن تحصل على خطأ "الدور موجود بالفعل" للمستخدم الفائق bootstrap مثل azure_pg_admin أو azure_superuser. هذا الخطأ غير مؤذي ويمكن تجاهله. من المحتمل أن ينتج عن استخدام الخيار --clean رسائل خطأ إضافية غير ضارة حول العناصر غير الموجودة، على الرغم من أنه يمكنك تقليلها عن طريق إضافة --if-exists.

الطريقة 1: استخدام pg_dump وpsql

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

الطريقة 2: استخدام pg_dump وpg_restore

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

الطريقة 3: استخدام دفق بيانات التفريغ إلى قاعدة البيانات الهدف

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

1. تأكد من وجود قاعدة البيانات في الخادم الهدف باستخدام الأمر \l. إذا لم تكن قاعدة البيانات موجودة، فبادر بإنشاء قاعدة البيانات.

    psql "host=myTargetServer port=5432 dbname=postgres user=myUser password=###### sslmode=mySSLmode"
   

   postgres> \l   
   postgres> create database myTargetDB;
   

2. شغّل أمر التفريغ والاستعادة كسطر أوامر واحد باستخدام ممر البيانات.

   pg_dump -Fc --host=mySourceServer --port=5432 --username=myUser --dbname=mySourceDB | pg_restore  --no-owner --host=myTargetServer --port=5432 --username=myUser --dbname=myTargetDB
   

   على سبيل المثال،

   pg_dump -Fc --host=pg-95.postgres.database.azure.com --port=5432 --username=pg@pg-95 --dbname=bench5gb | pg_restore --no-owner --host=pg-11.postgres.database.azure.com --port=5432 --username=pg@pg-11 --dbname=bench5gb
   

3. بمجرد اكتمال عملية الترقية (الترحيل)، يمكنك اختبار التطبيق الخاص بك مع الخادم الهدف.

4. كرر هذه العملية لجميع قواعد البيانات داخل الخادم.

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

حجم قاعدة البيانات	الوقت المستغرق تقريبيًا
1 جيجابايت	دقيقة-دقيقتين
5 جيجابايت	8-10 دقائق
10 غيغابايت	من 15 إلى 20 دقيقة
50 جيجا بايت	ساعة-ساعة ونصف
100 غيغابايت	ساعتان ونصف-ثلاث ساعات

الطريقة 4: استخدام التفريغ المتوازي والاستعادة

يمكنك مراعاة هذا الأسلوب إذا كان لديك عدد قليل من الجداول الأكبر في قاعدة البيانات الخاصة بك وتريد موازاة عملية التفريغ والاستعادة لقاعدة البيانات هذه. تحتاج أيضًا إلى تخزين كاف في نظام العميل الخاص بك لاستيعاب تفريغ النسخ الاحتياطي. تقلل عملية التفريغ والاستعادة المتوازية هذه من استهلاك الوقت لإكمال الترحيل بأكمله. على سبيل المثال، اكتملت قاعدة بيانات pgbench 50 غيغابايت التي استغرقت من ساعة إلى ساعة ونصف للترحيل باستخدام الأسلوب 1 و2 استغرقت أقل من 30 دقيقة باستخدام هذا الأسلوب.

1. لكل قاعدة بيانات في الخادم المصدر، قم بإنشاء قاعدة بيانات مقابلة على الخادم الهدف.

   psql "host=myTargetServer port=5432 dbname=postgres user=myuser password=###### sslmode=mySSLmode"
   

   postgres> create database myDB;
   

   على سبيل المثال،

   psql "host=pg-11.postgres.database.azure.com port=5432 dbname=postgres user=pg@pg-11 password=###### sslmode=require"
   psql (12.3 (Ubuntu 12.3-1.pgdg18.04+1), server 13.3)
   SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
   Type "help" for help.
   
   postgres> create database bench5gb;
   postgres> \q
   

2. شغّل الأمر pg_dump بتنسيق دليل مع عدد المهام = 4 (عدد الجداول في قاعدة البيانات). مع طبقة حساب أكبر ومع المزيد من الجداول، يمكنك زيادته إلى رقم أعلى. سيقوم pg_dump هذا بإنشاء دليل لتخزين الملفات المضغوطة لكل مهمة.

   pg_dump -Fd -v --host=sourceServer --port=5432 --username=myUser --dbname=mySourceDB -j 4 -f myDumpDirectory
   

   على سبيل المثال،

   pg_dump -Fd -v --host=pg-95.postgres.database.azure.com --port=5432 --username=pg@pg-95 --dbname=bench5gb -j 4 -f dump.dir
   

3. ثم قم باستعادة النسخة الاحتياطية في الخادم الهدف.

   $ pg_restore -v --no-owner --host=myTargetServer --port=5432 --username=myUser --dbname=myTargetDB -j 4 myDumpDir
   

   على سبيل المثال،

   $ pg_restore -v --no-owner --host=pg-11.postgres.database.azure.com --port=5432 --username=pg@pg-11 --dbname=bench5gb -j 4 dump.dir
   

تلميح

يمكن أيضًا استخدام العملية المذكورة في هذا المستند لترقية Azure Database for PostgreSQL - الخادم المرن. الفرق الرئيسي هو سلسلة الاتصال للخادم المرن الهدف بدون @dbName. على سبيل المثال، إذا كان اسم المستخدم هو pg، فسيكون اسم مستخدم الخادم الفردي في سلسلة الاتصال pg@pg-95، بينما مع الخادم المرن، يمكنك ببساطة استخدام pg.

ما بعد الترقية/الترحيل

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

postgres=> analyze;
ANALYZE

الخطوات التالية

• بعد أن تكون راضيًا عن وظيفة قاعدة البيانات الهدف، يمكنك قطع خادم قاعدة البيانات القديم.
• Azure Database for PostgreSQL - خادم فردي فقط. إذا كنت تريد استخدام نفس نقطة نهاية قاعدة البيانات مثل الخادم المصدر، بعد حذف خادم قاعدة البيانات المصدر القديم، يمكنك إنشاء نسخة متماثلة للقراءة باسم خادم قاعدة البيانات القديم. بمجرد إنشاء حالة النسخ المتماثل الثابتة، يمكنك إيقاف النسخة المتماثلة، والتي سترقي خادم النسخة المتماثلة ليكون خادمًا مستقلاً. راجع نسخ متماثل لمزيد من التفاصيل.

هام

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