هندسة البرمجيات

8 min read · Oct 2026

ترحيل قواعد البيانات بأقل مخاطرة: خطّة للتغيير والتعافي

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

ترحيل قواعد البيانات بأقل مخاطرة: خطّة للتغيير والتعافي

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

اعرف ما سيعمل أثناء الانتقال

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

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

وسّع البنية مع إبقاء القديم صالحًا

يقسم نمط Parallel Change التغيير غير المتوافق إلى التوسعة ثم نقل الاستخدام ثم إزالة القديم. في مثال افتراضي لنظام موافقات، نريد الانتقال من حقل approved إلى حقل approvalState.

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

انقل البيانات بقواعد يمكن التحقق منها

يوضح دليل Prisma فكرة نقل قيمة الحقل القديم إلى الجديد قبل إزالة القديم. وفي مثال الموافقات، وثّق تحويل القيمة الصحيحة إلى approved، والخاطئة إلى pending، وافصل أي حالات استثنائية لمراجعتها.

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

حوّل القراءات قبل حذف الاعتمادات

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

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

أزل القديم بعد إثبات الاستغناء عنه

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

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

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

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