ترحيل مخطط قاعدة البيانات مع توافق الإصدارات السابقة
· PoolByte Technology
غالبًا لا يكون إصدار التطبيق الجديد مجرد تغيير للملف. تؤثر إضافة أعمدة أو تخزين حقل بتنسيق آخر أو تحويل البيانات القديمة أيضًا على مخطط قاعدة البيانات. يخطط ترحيل المخطط الآمن بشكل واضح للبيانات التي ستقرأها إصدارات التطبيق القديمة والجديدة في أي مرحلة.
افتح نافذة التوافق بدلاً من تغييرها كلها مرة واحدة
على سبيل المثال، يمكنك تقسيم حقل عنوان واحد إلى عنوان المدينة وعنوان الشارع. قد يؤدي حذف الحقل القديم في الخطوة الأولى إلى تعطيل عمليات التطبيق التي لم يتم تحديثها بعد. قد تكون الطريقة الأكثر قابلية للإدارة هي إضافة حقول جديدة أولاً، وتقديم سلوك كتابة جديد، وإجراء تحويل متحكم فيه للسجلات القديمة. في هذه العملية، يجب تحديد أي من الحقلين هو المصدر المعتمد.
في أسلوب "الإضافة، النقل، الإزالة"، يمكن ترك الإزالة لمنشور منفصل. توثيق تعديل جدول PostgreSQL يصف سلوك عمليات المخطط المختلفة. لا تفترض أن نفس الأمر سيتم تشغيله بنفس القفل والمدة في كل قاعدة بيانات؛ يؤثر إصدار الخادم وبنية الجدول على النتيجة.
تشغيل تحويل البيانات بشكل صغير ويمكن تتبعه
يمكن أن يؤدي تحديث ملايين الصفوف مرة واحدة إلى عمليات تأمين طويلة وحجم كبير من سجلات المعاملات. المجموعات الصغيرة، وتسجيل التقدم، والقدرة على المتابعة من حيث توقفت، تجعل العملية أكثر سهولة في الإدارة. يجب أن يتم تصميم إعادة معالجة الصفوف الناجحة بحيث لا تفسد البيانات مرة ثانية.
ضع في الاعتبار أيضًا التغييرات التي أجراها المستخدمون الحقيقيون أثناء التحويل. لا ينبغي لعملية النقل التي تم إعدادها وفقًا لبيانات الأمس أن تؤدي إلى تدمير العنوان الذي تم تحديثه اليوم. قد يحدد الإصدار المصدر أو وقت التحديث أو استراتيجية كتابة البيانات في التطبيق هذا القرار. لا ينبغي ترك السجلات التي لا يمكن تحويلها فارغة بشكل صامت؛ ينبغي إدراجها في قائمة مراجعة منفصلة.
الاسترداد لا يعني فقط إعادة الملفات
إذا كتب الإصدار الجديد البيانات بتنسيق لم يتمكن الإصدار القديم من فهمه، فقد لا يكون التراجع عن الكود كافيًا. حدد الحد الاحتياطي للمخطط والبيانات قبل الإصدار. إذا كان عكس تحويل البيانات سيؤدي إلى فقدان معلومات، فلا تقدمها كزر "تراجع". في بعض الحالات، الحل الآمن هو التصحيح للأمام.
يختلف سلوك المعاملات لأوامر المخطط وفقًا لقاعدة البيانات. يشير وصف التزام MySQL الضمني إلى أن بعض الأوامر يمكنها تغيير حد المعاملة. لا تفترض أنه يمكن التراجع عن كل خطوة تلقائيًا لمجرد استخدام أداة الترحيل. تدرب وفقًا لإصدار التطبيق وقاعدة البيانات.
ما يجب تضمينه في ملف النشر
- معرف الترحيل وإصدار المخطط السابق.
- الوقت المتوقع وتأثير القفل والمساحة الحرة المطلوبة.
- المراحل التي يمكن أن يعمل فيها الإصدار القديم والجديد معًا.
- طريقة للتحقق من عدد السجلات المحولة والمرفوضة.
- خطوة المتابعة أو الاسترداد في حالة مقاطعة العملية.
- المنشور الذي سيزيل الحقول التي لم تعد مستخدمة.
يمكن استخدام بيئة التدريج لاختبار هذه الخطة ببيانات تمثيلية. ومع ذلك، فإن الحصول على نتيجة خلال ثوانٍ في جدول اختبار صغير جداً لا يثبت مدة التنفيذ في الإنتاج. يتطلب إكمال ترحيل المخطط أن يستخدم التطبيق السجلات القديمة والجديدة بشكل صحيح، بالإضافة إلى عدم إعطاء الأمر أي أخطاء.