مهاجرت MySQL به MariaDB در دایرکت ادمین؛ چرا جایگزینی مستقیم مناسب نیست؟

دیتابیس محل نگهداری نوشته‌ها، کاربران و سفارش‌های سایت است. انتقال از MySQL به MariaDB را مثل جابه‌جا کردن همین دفتر اطلاعات در نظر بگیرید؛ مقصد باید بتواند همهٔ صفحه‌های دفتر را درست بخواند. صرف اینکه هر دو اسم آشنا دارند، کافی نیست.

برای یک سایت نمونه، در phpMyAdmin دیتابیس درست را انتخاب کنید و از Export یک خروجی SQL بگیرید. در سرور آزمایشی مقصد یک دیتابیس و کاربر جدا بسازید و فایل را از Import وارد کنید. بعد یک کپی از برنامهٔ سایت را به دیتابیس تازه متصل کنید. در این مرحله سایت اصلی باید همچنان از دیتابیس اصلی استفاده کند.

یک نوشته را بخوانید، یک نوشتهٔ آزمایشی ذخیره کنید و در صورت داشتن فروشگاه، جست‌وجو و سبد خرید را در محیط آزمایشی امتحان کنید. اگر هنگام Import خطای نام یک مجموعهٔ حروف یا collation دیدید، آن نام را با پشتیبانی نسخهٔ مقصد مقایسه کنید؛ حذف اتفاقی جدول یا تغییر همهٔ حروف، راه‌حل مطمئنی نیست. فقط وقتی انتقال نمونه درست شد، برای جابه‌جایی دادهٔ تازهٔ سایت اصلی زمان مشخص کنید. خروجی مربوط به صبح، سفارش‌های ثبت‌شده در عصر را ندارد؛ به همین دلیل مرحلهٔ انتقال نهایی لازم است.

سازگاری فقط به باز شدن یک فایل SQL محدود نمی‌شود. collation، نوع داده، افزونه‌های موتور، روش احراز کاربر و قابلیت‌های مورد استفادهٔ برنامه ممکن است فرق داشته باشند. برای نمونه، موفق بودن ورود مدیر وردپرس اثبات نمی‌کند گزارش فروشگاه، جست‌وجوی فارسی یا پردازش سفارش هم بدون مشکل کار می‌کند.

ابتدا نسخهٔ فعلی، نسخهٔ مقصد و نیاز نرم‌افزارهای نصب‌شده را ثبت کنید. اگر برنامه‌ای افزونه یا ماژول اختصاصی دارد، سازگاری آن را از توسعه‌دهنده بگیرید. انتخاب نسخه صرفاً بر اساس بزرگ‌تر بودن شماره یا وعدهٔ افزایش سرعت، دلیل کافی برای جابه‌جایی نیست.

از دیتابیس‌ها خروجی منطقی قابل بازیابی تهیه کنید و تنظیمات، کاربران و مجوزهای لازم را نیز ثبت کنید. یک فایل dump که هنوز در مقصد وارد نشده است، اثبات نمی‌کند امکان بازگردانی دارید. مقصد آزمایشی را با همان نسخه‌ای که قرار است استفاده شود آماده کنید و خروجی را در آن وارد کنید.

برنامه را به دیتابیس آزمایشی متصل کنید و عملیات واقعی موردنیاز را انجام دهید: خواندن صفحه، ذخیرهٔ نوشته، ثبت کاربر، جست‌وجو و گزارش‌گیری. پیام‌های خطا و مدت اجرای عملیات را با مبدأ مقایسه کنید. برای تست فروشگاه از داده و محیط آزمایشی استفاده کنید تا پرداخت یا سفارش واقعی فقط برای آزمایش ایجاد نشود.

اگر سایت هنگام مهاجرت فعال می‌ماند، سفارش، پیام و تغییرات جدید بعد از زمان بکاپ ایجاد می‌شوند. باید زمان توقف نوشتن یا روش همگام‌سازی نهایی مشخص باشد. در غیر این صورت ممکن است نسخهٔ مقصد درست اجرا شود ولی آخرین اطلاعات کاربران را نداشته باشد.

فایل‌های داخلی دیتابیس را میان موتور یا نسخهٔ متفاوت بدون روش پشتیبانی‌شده کپی نکنید. انتخاب گزینهٔ جدید در CustomBuild نیز جای مطالعهٔ مسیر رسمی مهاجرت را نمی‌گیرد. قبل از تغییر سرور اصلی، زمان نگهداری، دسترسی کنسول، نسخهٔ تنظیمات و مسیر برگشت را آماده کنید.

بعد از انتقال، تعداد رکوردهای مهم و چند نمونهٔ داده را با گزارش مبدأ تطبیق دهید. آخرین سفارش‌ها یا نوشته‌ها را جدا بررسی کنید و آزمون‌های برنامه را دوباره انجام دهید. کارکرد بکاپ جدید، اتصال کاربران و لاگ خطا نیز باید کنترل شود.

اگر مقصد مشکل دارد، برگشت به موتور قبلی ممکن است به بازیابی نسخهٔ قبل از مهاجرت نیاز داشته باشد؛ تغییر دوبارهٔ یک گزینه لزوماً دادهٔ تبدیل‌شده را برنمی‌گرداند. مبدأ و بکاپ سالم را تا پایان بررسی نگه دارید و بعد از چند چرخهٔ کاری واقعی دربارهٔ حذف نسخهٔ قدیمی تصمیم بگیرید.