يُعد نقل قواعد البيانات أحد أكثر العمليات حرجاً في دورة حياة المطور أو مدير قاعدة البيانات. سواء كنت تنتقل من خادم محلي إلى خدمة سحابية مُدارة مثل Amazon RDS أو Google Cloud SQL، أو تترقى إلى إصدار رئيسي أحدث، أو تعيد تنظيم مخططك عبر عدة عناقيد، فإن المخاطر عالية. يمكن أن يؤدي فشل النقل إلى فقدان البيانات، وتوقف طويل الأمد، وتأثير كبير على الأعمال.
يتجاوز هذا الدليل النسخ الاحتياطي الأساسي لاستكشاف استراتيجيات قوية وجاهزة للإنتاج لنقل قواعد بيانات PostgreSQL. سنغطي الحلول ذات الأمر الواحد لمجموعات البيانات الأصغر، والمزامنة المستمرة للبيانات لنقل انعدام التوقف، وأفضل الممارسات للتحقق وإلغاء التغيير.
الاستراتيجية 1: النهج الكلاسيكي باستخدام pg_dump
بالنسبة لقواعد البيانات الصغيرة (عادة أقل من 100 جيجابايت) أو أثناء نوافذ الصيانة المجدولة حيث يكون التوقف مقبولاً، يظل pg_dump الطريقة الأكثر بساطة وموثوقية. فهو ينشئ نص SQL أو أرشيفاً بتنسيق مخصص يمكن استعادته على الخادم الوجهة.
السر في استخدام pg_dump بفعالية في سياق النقل هو استخدام التنسيق المخصص (-Fc)، والذي يسمح بالاستعادة المتوازية ومرونة أكبر.
# من الخادم المصدر
pg_dump -Fc -h source_host -U source_user -d my_database -f backup.dump
# على الخادم الوجهة
pg_restore -h dest_host -U dest_user -d new_database backup.dumpعلى الرغم من بساطتها، تتطلب هذه الطريقة فترة توقف حيث لا يمكن للتطبيق الكتابة إلى قاعدة البيانات. إذا كان لديك تطبيق يعمل مباشرة، فيجب عليك التأكد من إيقاف التطبيق عن العمل أو توجيهه إلى نسخة قراءة فقط أثناء عملية النقل لضمان اتساق البيانات.
الاستراتيجية 2: نقل انعدام التوقف باستخدام التكرار المنطقي
بالنسبة للتطبيقات الحرجة التي لا يمكنها تحمل التوقف، يُعد التكرار المنطقي المعيار الذهبي. تتيح لك هذه الطريقة الحفاظ على مزامنة قواعد البيانات المصدر والوجهة باستمرار، مما يسمح لك بتحويل حركة المرور في لحظة دقيقة.
الخطوة 1: إعداد الوجهة
أولاً، أنشئ قاعدة بيانات فارغة على الخادم المستهدف بنفس المخطط. تأكد من ضبط wal_level على logical على كل من الخادم المصدر والخادم الوجهة.
الخطوة 2: إنشاء النشر والاشتراك
على الخادم المصدر، أنشئ نشراً للجداول التي ترغب في نقلها:
CREATE PUBLICATION my_migration_pub FOR TABLE users, orders, products;على الخادم الوجهة، أنشئ اشتراكاً يتصل بالمصدر:
CREATE SUBSCRIPTION my_migration_sub
CONNECTION 'host=source_ip dbname=my_database user=replicator password=secret'
PUBLICATION my_migration_pub;سيبدأ PostgreSQL الآن في مزامنة البيانات من المصدر إلى الوجهة. يمكنك مراقبة التقدم عبر عرض النظام pg_stat_subscription. بمجرد اكتمال المزامنة الأولية ومواكبة التغييرات المباشرة، يمكنك الانتقال إلى عملية التحويل.
التحقق والتحويل
قبل تحويل حركة المرور، قم بإجراء تحقق نهائي. تحقق من عدد الصفوف والتحقق من الصحة (checksums) للجداول الحرجة على كل من المثيلين. عندما تكون مستعداً للتحويل، أوقف الكتابة على قاعدة البيانات المصدر (أو أوقف الاشتراك على الوجهة لضمان الاتساق).
-- إيقاف الاشتراك لضمان المزامنة النهائية
SELECT pg_subscription_rel.*, pg_stat_replication.*
FROM pg_subscription_rel
JOIN pg_stat_replication ON pg_subscription_rel.sql_localid = pg_stat_replication.pid;بمجرد أن يكون تأخر التكرار صفراً، قم بإلغاء تفعيل الاشتراك، وقم بتغيير سلسلة اتصال تطبيقك لتشير إلى قاعدة البيانات الجديدة، وفعّل الكتابة. راقب التطبيق عن كثب خلال الساعات القليلة الأولى لضمان الاستقرار.
الخاتمة
يعتمد اختيار استراتيجية النقل المناسبة على حجم بياناتك، والتوقف المقبول، وتعقيد البنية التحتية. بالنسبة للتغييرات الصغيرة، يكفي pg_dump. وبالنسبة للمتطلبات على مستوى المؤسسات، يوفر التكرار المنطقي الأمان والاستمرارية اللازمة للانتقالات السلسة. اختبر دائماً عملية النقل في بيئة تجريبية قبل محاولة تنفيذها في بيئة الإنتاج لتخفيف المخاطر وضمان عملية سلسة.