Skip to content
VDS · قواعد البيانات

نقل قاعدة بيانات من خادم آخر

إجراء ترحيل قاعدة بيانات إلى Millida VDS: التحضير، ونقل النسخة عبر الشبكة، والتحقق من السلامة، وتحويل التطبيق بأقل توقف.

آخر تحديث 23 أغسطس 2026

لا تتعطّل ترحيل قاعدة البيانات عند الأوامر، بل عند ترتيب الخطوات: يبدّل الناس النطاق أولًا ثم يكتشفون أن نصف البيانات لم يصل أصلًا. فيما يلي تسلسل يمنع حدوث ذلك.

التحضير

على الجهاز الجديد، ثبّت الإصدار نفسه أو إصدارًا أحدث من خادم قاعدة البيانات — PostgreSQL أو MySQL. التخفيض إلى إصدار أقدم غير مدعوم.

psql --version
mysql --version
df -h /

تحتاج إلى مساحة حرة تعادل نحو 2.5 ضعف حجم قاعدة البيانات: ملف التفريغ، والبيانات بعد فك الضغط، وبعض الهامش الإضافي. على VDS-1 يبلغ الإجمالي 40 GB، لذا خطّط مسبقًا.

أنشئ مستخدمًا وقاعدة بيانات فارغة بالترميز نفسه الموجود على الخادم القديم.

نقل البيانات

أبسط طريق هو التفريغ عبر SSH، دون ملفات وسيطة:

ssh root@OLD 'pg_dump -Fc -U shop shop' > /srv/shop.dump
pg_restore -U postgres -d shop --no-owner --role=shop /srv/shop.dump

بالنسبة إلى MySQL:

ssh root@OLD 'mysqldump --single-transaction --routines --events -u root shop' \
  | mysql -u root shop

لا تتضمن عملية تفريغ قاعدة البيانات الأدوار والمستخدمين — تصدّرها بشكل منفصل: pg_dumpall --roles-only، أو أنشئها يدويًا — راجع المستخدمون والصلاحيات.

تبلغ سرعة النطاق حتى 500 Mbps، لذا تنتقل قاعدة بيانات بحجم 20 GB في غضون دقائق؛ وعادةً ما يكون عنق الزجاجة في كتابة القرص، وهي محدودة حسب المستوى.

التحقق قبل التبديل

تحقّق من الأرقام، لا من مجرد «تحميل الموقع»:

SELECT relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 20;
SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='shop';

قارن عدد الصفوف في الجداول الرئيسية مع الخادم القديم، وتأكد من أن التسلسلات لم تُعَد ضبطها (SELECT last_value FROM users_id_seq;)، وشغّل التطبيق على قاعدة البيانات الجديدة في وضع الاختبار.

التبديل

  1. فعّل وضع الصيانة أو أوقف التطبيق على الخادم القديم.
  2. خذ تفريغًا نهائيًا للتغييرات التي أُجريت أثناء التحضير.
  3. استعده على الجهاز الجديد.
  4. بدّل سلسلة اتصال التطبيق وأعد تشغيل الخدمة.
  5. أبقِ الخادم القديم يعمل أسبوعًا آخر دون حذف البيانات.

لا تتخطَّ الخطوة الخامسة: فاكتشاف جدول مفقود بعد ثلاثة أيام أمر متوقع.

الأخطاء الشائعة

العَرَضالسبب
role does not exist أثناء الاستعادةلم تُرحَّل الأدوار — استخدم --no-owner مع إنشاء الأدوار يدويًا
أحرف مشوّشةترميزات غير متطابقة: استعد إلى قاعدة بيانات بترميز utf8mb4 أو UTF8
التسلسلات تبدأ من 1احتوى التفريغ على البيانات فقط، دون setval
تستغرق الاستعادة ساعاتتُبنى الفهارس أثناء العملية؛ لقواعد البيانات الكبيرة استخدم pg_restore -j 4
نفدت المساحة في المنتصفلم تُحتسب مساحة التفريغ إلى جانب البيانات

قبل الترحيل، تحقّق من أن قاعدة البيانات الجديدة تستمع على 127.0.0.1 فقط. لا حاجة لكشفها علنًا «طوال مدة الترحيل» — فالنقل يجري عبر SSH، راجع الوصول عن بُعد.