لا يمكنك ترحيل قاعدة بيانات لم تُحصِها بعد

كل مشروع ترحيل يبدأ بشكل سيئ يبدأ بالوثيقة نفسها: جدول بيانات.

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

يمكنك أن تناقش أدوات الترحيل أسابيع. الخطر الأكبر هو الجرد الذي تُوجَّه إليه هذه الأدوات.

مرحلة تحديد النطاق هي التي تُحسم فيها المشاريع

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

هذا هو الافتراض الذي ينهار. ومن الصعب تقدير حجم مشروع بناءً على معلومات متداولة.

ما يجب أن يحتويه الجرد القابل للاستخدام

الجرد الناجح يجيب عن قائمة قصيرة من الأسئلة لكل نسخة قاعدة بيانات، ويجيب عنها من الجهاز نفسه لا من الذاكرة:

• موقع السيرفر وكيفية الوصول إليه

• إصدار قاعدة البيانات العامل، وما إذا كان محدّثًا بالتصحيحات

• نظام التشغيل

• البيئة التي تنتمي إليها: تطوير أو QA أو إنتاج

• دورها في العنقود: رئيسي أو نسخة

• هل استجابت لآخر فحص حالة

• من المسؤول عنها عند وقوع مشكلة

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

نقطة بداية مجانية: PG-Inventory

PG-Inventory هي منصة ورلبر مفتوحة المصدر لجرد ومراقبة بنية PostgreSQL التحتية. تُنشر تحت رخصة MIT والشفرة المصدرية متاحة على github.com/Worlber/PG-Inventory.

تُنشَر المنصة عبر Docker Compose، ويشترط ذلك Docker Engine 20.10 أو أحدث مع Compose v2 أو أحدث، وتعمل كستِّ خدمات. الواجهة الأمامية React 18 مع TypeScript، والخلفية Django 5.1 على Python 3.12، وقاعدة بيانات PostgreSQL 16 لتخزين بياناتها، وRedis 7 مع Celery وCelery Beat للمهام المجدولة.

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

• تسجيل قواعد البيانات مع الإضافة والتعديل والحذف، وتخزين بيانات الاعتماد مشفّرة بمعيار AES-256-GCM

• تصنيف القواعد إلى فئات: تطوير، QA، إنتاج

• فحص كل قاعدة كل دقيقتين وإظهار الحالة والإصدار ونظام التشغيل والمعالج والذاكرة

• وضع علامة DOWN على القاعدة بعد ثلاث محاولات فحص فاشلة متتالية

• استعلام Patroni REST API لعرض دور القاعدة رئيسي أو نسخة ومخطط مرئي للعنقود

• ضبط الصلاحيات بأدوار Admin وViewer مع مصادقة ثنائية TOTP

• التصدير إلى CSV وExcel مع بحث شامل في الجرد

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

ما ليست عليه PG-Inventory

من المفيد قول ذلك صراحة، لأن أدوات الجرد تُبالغ في تسويقها:

• هي تجرد PostgreSQL، ولا تُحصي بيئات Oracle أو SQL Server أو DB2.

• هي تتابع حالة عنقود Patroni، ولا توفّر التوافر العالي. التوافر العالي طبقة منفصلة وإدارته مهمة أخرى.

• الجرد ليس تقييمًا. يخبرك بما هو موجود، ولا يخبرك أي الإجراءات المخزّنة ستتعطل، أو أي الاستعلامات ستفقد خطة التنفيذ، أو أي تطبيق سيحتاج تعديلات برمجية.

• المنصة مفتوحة المصدر وتُستضاف داخليًا، فتبقى عليك مسؤولية النشر والتحديثات.

أين يدخل الجرد في مسار الترحيل

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

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

أنظمة المصدر نفسها نادرًا ما تكون الجزء الصعب. أعمال الترحيل في ورلبر تغطي Oracle وMicrosoft SQL Server وEDB EPAS وMariaDB وMySQL وMongoDB، مع مشاريع مخصّصة لـ IBM DB2 وInformix وSybase وCassandra. الجزء الصعب هو تحديد ما ينتقل، وبأي ترتيب، وما يبقى في مكانه.

ابدأ بالإحصاء

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

وإذا أردت رأيًا ثانيًا في بيئة PostgreSQL قبل الالتزام بخطة ترحيل، تحدّث إلى ورلبر بخصوص تقييم النطاق.

احصر بيئة PostgreSQL مع ورلبر

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

تواصل مع ورلبر