عندما يؤدي حذف عمود في قاعدة البيانات إلى تعطيل الإنتاج: إدارة تغييرات المخطط التدميرية
لديك ترحيل قاعدة بيانات يزيل عمودًا غير مستخدم. تبدو جملة SQL نظيفة. يتم تنفيذ الترحيل دون أخطاء. لكن بعد خمس دقائق، تبدأ التنبيهات في الانطلاق. تطبيق الإنتاج يرمي أخطاء لأن جزءًا من الكود لا يزال يشير إلى ذلك العمود. ما بدا وكأنه تنظيف بسيط تسبب في انقطاع الخدمة.
هذا السيناريو أكثر شيوعًا مما يعترف به معظم الفرق. المشكلة ليست في الترحيل نفسه. المشكلة هي افتراض أن إزالة شيء من قاعدة البيانات آمن لمجرد أنك تعتقد أن لا أحد يستخدمه بعد الآن.
ما الذي يجعل التغيير تدميريًا
تندرج تغييرات قاعدة البيانات إلى فئتين. التغييرات الإضافية تضيف شيئًا جديدًا: عمود جديد، جدول جديد، فهرس جديد. هذه التغييرات آمنة بشكل عام لأن الكود الموجود ببساطة يتجاهل ما لا يعرفه.
التغييرات التدميرية تزيل أو تعيد تسمية أو تعدل الهياكل الموجودة. حذف عمود، إعادة تسمية جدول، تغيير نوع عمود، أو إزالة قيد كلها تغييرات تدميرية. الخطر واضح: إذا كان أي تطبيق قيد التشغيل لا يزال يعتمد على ذلك الهيكل، فسوف يتعطل بمجرد تطبيق التغيير.
يتضاعف الخطر بسبب استراتيجيات النشر الحديثة. التحديثات المتدرجة ونشر الأزرق-الأخضر يعني أن الإصدارات القديمة والجديدة من التطبيق تعمل جنبًا إلى جنب لدقائق أو ساعات. الترحيل التدميري الذي يتم تشغيله أثناء النشر سيكسر على الفور الحالات القديمة التي لا تزال تخدم حركة المرور.
نمط الترحيل متعدد المراحل
النهج الأكثر أمانًا هو عدم حذف أي شيء في خطوة واحدة. بدلاً من ذلك، قم بتقسيم التغييرات التدميرية إلى مراحل متعددة. يجب أن تكون كل مرحلة متوافقة مع إصدار التطبيق الذي يعمل في ذلك الوقت.
يوضح المخطط الانسيابي التالي المراحل الثلاث لإعادة تسمية عمود آمنة، مع إظهار إصدارات التطبيق المتوافقة في كل خطوة.
ضع في اعتبارك إعادة تسمية عمود من status إلى status_code. الترحيل الفردي الذي يعيد تسمية العمود سيكسر أي كود لا يزال يقرأ status. يبدو النهج متعدد المراحل كما يلي:
المرحلة 1: أضف العمود الجديد دون إزالة القديم. انسخ البيانات من العمود القديم إلى الجديد. قم بتحديث كود التطبيق للقراءة من العمود الجديد مع الاستمرار في الكتابة على كليهما. انشر هذا التغيير.
المرحلة 2: بعد التأكد من أن جميع حالات التطبيق تستخدم العمود الجديد، توقف عن الكتابة على العمود القديم. قم بتحديث الكود للإشارة فقط إلى status_code. انشر مرة أخرى.
المرحلة 3: بمجرد التأكد من أن أي كود قيد التشغيل لا يلمس العمود القديم، قم بحذفه في ترحيل منفصل. حدد موعدًا لذلك خلال ساعات حركة المرور المنخفضة.
ينطبق نفس النمط على إزالة الجداول. قم بإنشاء عرض أو جدول جديد يحل محل الوظيفة القديمة. أعد توجيه كود التطبيق إلى الهيكل الجديد. انتظر حتى لا يشير أي كود إلى الجدول القديم. ثم قم بحذفه.
الحذف الناعم كشبكة أمان
في بعض الأحيان تريد إزالة البيانات من عرض التطبيق دون حذفها فعليًا من قاعدة البيانات. هذا هو المكان الذي يساعد فيه الحذف الناعم.
بدلاً من تشغيل جملة DELETE، أضف عمودًا مثل deleted_at أو is_active. يقوم التطبيق بتصفية الصفوف المحذوفة باستخدام جملة WHERE. تبقى البيانات في الجدول للتدقيق أو الاسترداد أو التبعيات غير المتوقعة من الميزات الأخرى.
الحذف الناعم مفيد بشكل خاص عندما لا تكون متأكدًا تمامًا مما إذا كانت البيانات لا تزال مطلوبة. يمنحك مخزنًا مؤقتًا للسلامة. إذا حدث خطأ ما، يمكنك استعادة الرؤية دون استعادة قاعدة البيانات. المقايضة هي أن جداولك تنمو بشكل أكبر وتحتاج الاستعلامات إلى مراعاة عامل التصفية. لكن بالنسبة للعديد من الفرق، هذه المقايضة تستحق السلامة.
التعامل مع القيود بحذر
إزالة قيد مثل مفتاح خارجي أو قيد فريد أقل خطورة من إزالة البيانات، لكن لا يزال له عواقب. القيود تفرض تكامل البيانات. إذا كان كود التطبيق الخاص بك يعتمد على قاعدة البيانات لمنع الإدخالات المكررة أو السجلات اليتيمة، فإن إزالة القيد يمكن أن تؤدي إلى تلف البيانات.
قبل إزالة القيد، قم بتدقيق قاعدة الكود للتأكد من عدم وجود منطق يعتمد عليه. إذا كانت قاعدة بياناتك تدعم ذلك، فكر في تعطيل القيد أولاً بدلاً من حذفه. يتيح لك ذلك اختبار التأثير دون فقدان القدرة على إعادة تمكينه بشكل دائم.
قائمة مراجعة عملية للتغييرات التدميرية
- تحقق من عدم وجود كود تطبيق قيد التشغيل يشير إلى الهيكل الذي تخطط لإزالته. تحقق من الإصدار الحالي وأي عمليات نشر قيد التنفيذ.
- قسّم التغيير إلى ترحيلين على الأقل: واحد لإضافة الهيكل الجديد وإعادة توجيه الكود، وآخر لإزالة الهيكل القديم بعد فترة انتظار.
- قم بتشغيل الترحيلات التدميرية بشكل منفصل عن نشر الميزات. لا تجمع حذف عمود مع إصدار نقطة نهاية جديدة.
- حدد موعدًا للتغييرات التدميرية خلال نوافذ حركة المرور المنخفضة. حتى مع التخطيط متعدد المراحل، من الأسهل التعامل مع المشكلات غير المتوقعة عندما يتأثر عدد أقل من المستخدمين.
- بعد إزالة الهياكل القديمة، قم بتنظيف المخلفات مثل الأعمدة المعاد تسميتها أو القيود المعطلة في ترحيل متابعة. لكن تذكر: التنظيف هو أيضًا تدميري، لذا طبق نفس النهج متعدد المراحل.
المبدأ الأساسي
لا تحذف أبدًا شيئًا قد يتم الوصول إليه بواسطة تطبيق قيد التشغيل. هذا يبدو واضحًا، لكنه الخطأ الأكثر شيوعًا الذي ترتكبه الفرق مع ترحيلات قاعدة البيانات. الضغط للحفاظ على المخطط نظيفًا، والافتراض بأن "لا أحد يستخدم ذلك بعد الآن"، والرغبة في شحن ترحيل نظيف واحد بدلاً من عدة ترحيلات صغيرة، كلها تدفع الفرق نحو عمليات حذف أحادية الخطوة محفوفة بالمخاطر.
تستغرق الترحيلات متعددة المراحل وقتًا أطول ونشرًا أكثر. لكنها تمنع النوع من انقطاع الإنتاج الذي يحول تنظيف المخطط البسيط إلى استرجاع طارئ. المخطط النظيف لا يستحق تطبيقًا معطلاً.