دليل ترقية قواعد البيانات المستضافة ذاتيًا: التفريغ، وإنشاء اللقطات، والترحيل، والتراجع

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

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

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

حدّد التوافق والتراجع قبل النسخ الاحتياطي

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

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

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

أنشئ نقطتي استعادة مستقلتين

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

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

استخدم قائمة التحقق من ZimaSpace للتحقق من اكتمال النسخة الاحتياطية لقاعدة البيانات. لا تنجح بوابة النسخ الاحتياطي إلا عندما يكون التفريغ قابلًا للقراءة، وتكون نقطة استعادة التخزين محددة، وتُخزَّن كلتاهما خارج وحدة التخزين التي ستتم ترقيتها.

تدرّب على الترحيل في هدف معزول

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

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

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

حوّل الكتابة واحتفظ بتراجع نظيف

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

راقب معدلات الأخطاء والأقفال وتنفيذ المهام والنسخ الاحتياطية والمعاملات الفعلية للتطبيق. أبقِ قاعدة البيانات القديمة متوقفة للقراءة فقط مع وحدة التخزين الأصلية وبصمة الصورة الأصلية. لا تسمح أبدًا لقاعدتي البيانات بقبول عمليات كتابة مستقلة بهوية التطبيق نفسها.

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

الدعم والنصائح

المزيد للقراءة

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.