أفضل الممارسات للترحيل السلس إلى قاعدة بيانات Azure ل PostgreSQL

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

تشرح هذه المقالة المزالق الشائعة التي تمت مواجهتها وأفضل الممارسات لضمان ترحيل سلس وناجح إلى قاعدة بيانات Azure ل PostgreSQL.

التحقق من الصحة قبل الترحيل

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

تكوين الخادم المرن المستهدف

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

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

SELECT pg_size_pretty( pg_database_size('dbname') );

نوصي بتخصيص مساحة تخزين كافية على الخادم المرن، بما يعادل 1.25 مرة أو 25٪ مساحة تخزين أكبر مما يتم استخدامه لكل إخراج للأمر السابق. يمكنك أيضا استخدام Storage Autogrow.

هام

لا يمكن تقليل حجم التخزين في التكوين اليدوي أو Storage Autogrow. تتضاعف كل خطوة في طيف تكوين التخزين في الحجم، لذا فإن تقدير التخزين المطلوب مسبقا أمر حكيم.

يعد التشغيل السريع إنشاء قاعدة بيانات Azure لخادم PostgreSQL المرن مكانا ممتازا للبدء. لمزيد من المعلومات حول كل تكوين خادم، راجع خيارات الحوسبة والتخزين في قاعدة بيانات Azure لخادم PostgreSQL المرن.

هام

بمجرد إنشاء خادم مرن، تأكد من تغيير معلمة خادم password_encryption على الخادم المرن من SCRAM-SHA-256 إلى MD5 قبل بدء الترحيل. هذا ضروري لبيانات الاعتماد الموجودة على خادم واحد للعمل على الخادم المرن

مخطط زمني للترحيل

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

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

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

تعتبر المراحل التالية لحساب إجمالي وقت التعطل لتنفيذ ترحيل خادم الإنتاج:

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

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

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

  • يتطابق عدد الصفوف مع جميع الجداول المتضمنة في الترحيل.

  • عدد المطابقة لجميع كائنات قاعدة البيانات (الجداول والتسلسلات والملحقات والإجراءات والفهارس).

  • مقارنة معرفات الحد الأقصى أو الأدنى للأعمدة الرئيسية المتعلقة بالتطبيق.

    إشعار

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

• ترحيل إعدادات الخادم: يجب نسخ أي معلمات خادم مخصصة وقواعد جدار الحماية (إن أمكن) والعلامات والتنبيهات يدويا من مثيل المصدر إلى الهدف.

• تغيير سلسلة الاتصال: يجب على التطبيق تغيير سلسلة الاتصال الخاصة به إلى خادم مرن بعد التحقق من الصحة بنجاح. يتم تنسيق هذا النشاط مع فريق التطبيق لتغيير جميع مراجع سلسلة الاتصال التي تشير إلى مثيل المصدر. في الخادم المرن، يمكن استخدام معلمة المستخدم بتنسيق user=username في سلسلة الاتصال.

على سبيل المثال: psql -h myflexserver.postgres.database.azure.com -u user1 -d db1

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

قياس سرعة الترحيل

يوضح الجدول التالي الوقت المستغرق لإجراء عمليات الترحيل لقواعد البيانات بأحجام مختلفة باستخدام خدمة الترحيل. تم تنفيذ الترحيل باستخدام خادم مرن مع Standard_D4ds_v4 SKU (4 ذاكرات أساسية، ذاكرة 16 غيغابايت).

حجم قاعدة البيانات	الوقت التقريبي المستغرق (ساعة:دقيقة)
1 جيجابايت	00:01
5 جيجابايت	00:03
10 غيغابايت	00:08
50 جيجا بايت	00:35
100 غيغابايت	01:00
500 جيجابايت	04:00
1,000 GB	07:00

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

هام

على الرغم من أن وحدة SKU القابلة للاندفاع ليست قيدا، فمن المستحسن اختيار SKU أعلى للخادم المرن لإجراء عمليات ترحيل أسرع. يدعم خادم Azure Database for PostgreSQL المرن حساب وقت التوقف عن العمل تقريبا وتحجيم IOPS، بحيث يمكن تحديث SKU بأقل وقت تعطل. يمكنك دائما تغيير SKU لمطابقة احتياجات التطبيق بعد الترحيل.

تحسين سرعة الترحيل: الترحيل المتوازي للجداول

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

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

• يجب أن يحتوي الجدول على عمود مع مفتاح أساسي بسيط (غير مركب) أو فهرس فريد من النوع smallint، integer أو big int.

  إشعار

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

• إذا لم يتضمن الجدول مفتاحا أساسيا بسيطا أو فهرسا فريدا من النوع smallint، integer أو big int كان يحتوي على عمود يفي بمعايير نوع البيانات، يمكن تحويل العمود إلى فهرس فريد باستخدام الأمر التالي. لا يتطلب هذا الأمر تأمينا على الجدول.

      create unique index concurrently partkey_idx on <table name> (column name);
  

• إذا لم يكن الجدول يحتوي smallintعلى مفتاح integer أساسي أو big int فهرس فريد أو أي عمود يفي بمعايير نوع البيانات، يمكنك إضافة مثل هذا العمود باستخدام ALTER وإفلاته بعد الترحيل. ALTER يتطلب تشغيل الأمر تأمينا على الجدول.

      alter table <table name> add column <column name> big serial unique;
  

إذا تم استيفاء أي من الشروط السابقة، يتم ترحيل الجدول في أقسام متعددة بالتوازي، والتي يجب أن توفر زيادة في سرعة الترحيل.

طريقة العمل

• تبحث خدمة الترحيل عن حجم جدول للتحقق مما إذا كان أكبر من 20 غيغابايت.
• إذا كان الحجم أكبر من 20 غيغابايت، وكان هناك smallintinteger مفتاح أساسي أو big int فهرس فريد، يتم تقسيم الجدول إلى أجزاء متعددة ويتم ترحيل كل جزء بالتوازي.

باختصار، تقوم خدمة ترحيل PostgreSQL بترحيل جدول في مؤشرات ترابط متوازية وتقليل وقت الترحيل إذا:

• يحتوي الجدول على عمود بمفتاح أساسي بسيط أو فهرس فريد من النوع smallint، integer أو big int.
• حجم الجدول أكبر من 20 غيغابايت.
• يحتوي SKU المستخدم على ذاكرات أساسية الخامة، والتي يمكن استخدامها لترحيل الجدول بالتوازي.

انتفاج فراغ في قاعدة بيانات PostgreSQL

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

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

• فراغ قياسي

  VACUUM your_table;
  

• فراغ مع تحليل

  VACUUM ANALYZE your_table;
  

• فراغ عدواني لجداول الكتابة الثقيلة

  VACUUM FULL your_table;
  

في هذا المثال، استبدل your_table باسم الجدول الفعلي. يقوم VACUUM الأمر بدون FULL استعادة المساحة بكفاءة، بينما VACUUM ANALYZE يحسن تخطيط الاستعلام. VACUUM FULL يجب استخدام الخيار بحكمة بسبب تأثيره الأثقل على الأداء.

تخزن بعض قواعد البيانات كائنات كبيرة، مثل الصور أو المستندات، التي يمكن أن تساهم في انتفاج قاعدة البيانات بمرور الوقت. VACUUMLO تم تصميم الأمر للكائنات الكبيرة في PostgreSQL.

• تفريغ الكائنات الكبيرة

  VACUUMLO;
  

يضمن دمج إستراتيجيات التفريغ هذه بانتظام وجود قاعدة بيانات PostgreSQL جيدة الصيانة.

اعتبارات خاصة

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

الترحيل عبر الإنترنت

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

إشعار

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

البديل هو استخدام ALTER TABLE الأمر حيث يكون الإجراء REPLICA IDENTIY مع FULL الخيار . يسجل FULL الخيار القيم القديمة لجميع الأعمدة في الصف بحيث حتى في حالة عدم وجود مفتاح أساسي، تنعكس جميع عمليات CRUD على الهدف أثناء الترحيل عبر الإنترنت. إذا لم يعمل أي من هذه الخيارات، فنفذ الترحيل دون اتصال كبديل.

قاعدة بيانات ذات ملحق postgres_fdw

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

1. قم بإزالة (إلغاء ربط) برنامج تضمين البيانات الخارجية مؤقتا على مثيل المصدر.
2. تنفيذ ترحيل البيانات للباقي باستخدام خدمة الترحيل.
3. استعادة أدوار تضمين البيانات الخارجية والمستخدم والارتباطات إلى الهدف بعد الترحيل.

قاعدة بيانات ذات ملحق postGIS

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

تنظيف اتصال قاعدة البيانات

في بعض الأحيان، قد تواجه هذا الخطأ عند بدء الترحيل:

CL003:Target database cleanup failed in the pre-migration step. Reason: Unable to kill active connections on the target database created by other users. Please add the pg_signal_backend role to the migration user using the command 'GRANT pg_signal_backend to <migrationuser>' and try a new migration.

في هذا السيناريو، يمكنك منح migration user الإذن لإغلاق كافة الاتصالات النشطة بقاعدة البيانات أو إغلاق الاتصالات يدويا قبل إعادة محاولة الترحيل.

المحتوى ذو الصلة

• خدمة الترحيل
• المشاكل والقيود المعروفة