مهاجرت دیتابیس WordPress به سرور جدید را چطور انجام دهیم؟

حساس‌ترین بخش هر انتقال سایت وردپرسی، دیتابیس است. فایل‌ها را می‌توان دوباره آپلود کرد، قالب و افزونه‌ها را از نو نصب کرد، اما دیتابیس جای اشتباه ندارد؛ اگر یک بایت از Serialized Data خراب شود، گزینه‌های پیکربندی از دست می‌رود و اگر کاراکترست اشتباه وارد شود، همه متن‌های فارسی به علامت سؤال تبدیل می‌شوند. در طول سال‌ها کار روی انتقال سایت‌ها، بخش عمده پروژه‌هایی که به مشکل خورده‌اند، در همین لایه دیتابیس شکسته‌اند. این مقاله، همان مسیری است که در همه پروژه‌های جدی روی آن تمرکز می‌کنم؛ نه فهرست کلی انتقال، بلکه تمرکز دقیق روی خود دیتابیس و رفتار آن در سرور جدید.

چرا دیتابیس، حساس‌ترین بخش مهاجرت است؟

تفاوت اساسی بین فایل‌ها و دیتابیس در ماهیت محتوای آن‌هاست. فایل‌ها مستقل هستند؛ اگر یک فایل تصویر از دست برود، فقط یک تصویر را از دست می‌دهید. اما دیتابیس، مجموعه‌ای از روابط به‌هم‌پیوسته است؛ رکورد یک نوشته با رکورد متادیتا، دسته‌بندی، کاربر و رسانه در ارتباط است. اگر این روابط در انتقال حفظ نشود، سایت به‌ظاهر سالم بالا می‌آید اما در عمل معیوب است. اگر با ساختار کلی وردپرس آشنا نیستید، وردپرس چیست و چگونه شروع کنیم تصویر کلی لایه‌ها را روشن می‌کند. اما در همین جا بگویم که در سال‌ها کار با انتقال سایت، بخش عمده‌ای از خرابی‌ها نه از فایل‌ها، بلکه از دیتابیس آمده و ریشه‌شان معمولاً یکی از این سه بوده: کاراکترست اشتباه، Serialized Data خراب‌شده، یا جایگزینی ناقص URL.

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

در مهاجرت، فایل‌ها را می‌توان از نو ساخت؛ اما دیتابیس، حافظه تجمعی سال‌های سایت است که بازسازی نمی‌شود.

سناریوهای رایج انتقال دیتابیس

سه سناریوی اصلی برای انتقال دیتابیس وجود دارد که هرکدام تصمیم‌های متفاوتی می‌خواهد. تشخیص سناریو، اولین گام در انتخاب روش درست است.

سناریو اول: انتقال همزمان با تغییر هاست (بدون تغییر دامنه)

در این سناریو، دامنه سایت ثابت می‌ماند و فقط سرور تغییر می‌کند. ساده‌ترین حالت از نظر جایگزینی URL است، چون نیازی به تغییر آدرس در دیتابیس نیست. اما مسئله اصلی، هماهنگی دقیق بین DNS، دیتابیس و فایل‌هاست. اگر دیتابیس را زودتر منتقل کنید و DNS هنوز به سرور قدیم اشاره کند، کاربران همچنان به دیتابیس قدیم نوشته می‌فرستند و داده‌های جدیدی که در آن فاصله ایجاد شود، از دست می‌رود.

سناریو دوم: انتقال همراه با تغییر دامنه

در این سناریو، هم سرور و هم دامنه تغییر می‌کند. این حالت، پیچیده‌تر است چون جایگزینی URL در دیتابیس اجباری می‌شود. همچنین ریدایرکت‌های سئویی از دامنه قدیم به جدید، بخش جدایی‌ناپذیر پروژه است. اگر این سناریو را انتخاب کرده‌اید، پیش از شروع، تغییر دامنه بدون افت سئو را بخوانید تا لایه‌های سئویی هم‌زمان پوشش داده شوند.

سناریو سوم: انتقال بخشی از دیتابیس یا یک سایت از Multisite

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

گام صفر: آماده‌سازی پیش از هر Export

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

بکاپ کامل و تست‌شده از دیتابیس

بکاپ دیتابیس، دو نسخه می‌خواهد: یکی SQL خام که قابلیت Import مستقیم دارد و یکی نسخه فشرده که فضای کمتری می‌گیرد. اگر با روش‌های بکاپ آشنا نیستید، پشتیبان‌گیری از سایت چیست و چرا ضروری است مفاهیم پایه را روشن می‌کند و برای مسیر عملی، چگونه از وردپرس بکاپ بگیریم گام‌به‌گام پیش می‌رود. اگر پنل هاست شما cPanel است، روش اختصاصی بکاپ در چگونه از cPanel بکاپ بگیریم آمده است. نکته کلیدی: پیش از شروع مهاجرت، یک بار بازیابی این بکاپ را روی یک محیط تست انجام دهید تا مطمئن شوید سالم است.

شناسایی مشخصات دیتابیس مبدأ و مقصد

قبل از هر کاری، این هفت پارامتر را از مبدأ و مقصد یادداشت کنید: نام دیتابیس، نام کاربر، رمز عبور، هاست دیتابیس، پورت، نسخه MySQL یا MariaDB، و کاراکترست پیش‌فرض. اگر بین مبدأ و مقصد تفاوت نسخه وجود دارد، احتمال بروز ناسازگاری بیشتر می‌شود. تجربه‌ام این است که مهاجرت از MySQL 5.7 به MariaDB 10.6 یا برعکس، تقریباً بدون مشکل است اما مهاجرت از نسخه‌های خیلی قدیمی به نسخه‌های جدید، گاهی نیاز به سازگاری دستی دارد.

اطمینان از نسخه PHP در دو سرور

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

ساختار دیتابیس وردپرس: نقشه راه

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

جدول‌های اصلی و نقش‌شان

پنج جدول پایه هر نصب وردپرس را باید بشناسید: جدول wp_posts که نوشته‌ها، برگه‌ها و رسانه‌ها را نگه می‌دارد. جدول wp_postmeta که متادیتای نوشته‌ها را ذخیره می‌کند. جدول wp_users که حساب‌های کاربری را نگه می‌دارد و جدول wp_usermeta که متادیتای کاربران. در نهایت، جدول wp_options که تنظیمات سایت را ذخیره می‌کند. سایر جدول‌ها به تاکسونومی، نظرات، و روابط اختصاص دارند. اگر با ساختار عمیق وردپرس آشنا نیستید، در توسعه وردپرس چیست و از کجا شروع کنیم تصویر کامل این لایه‌ها آمده است.

جدول‌های اضافه‌شده توسط افزونه‌ها

در سایت‌های با افزونه‌های سنگین، جدول‌های اختصاصی ووکامرس، فرم‌سازها و افزونه‌های تحلیلی هم به دیتابیس اضافه می‌شوند. اگر فروشگاه ووکامرس دارید، این جدول‌ها حجم قابل توجهی دارند و انتظار داشته باشید که دیتابیس شما در مقایسه با یک سایت محتوایی، دو یا سه برابر بزرگ‌تر باشد. ساختار کلی این جدول‌ها را در ووکامرس چیست و چگونه فروشگاه اینترنتی بسازیم بررسی کرده‌ام و برای بهینه‌سازی این جدول‌ها، بهینه‌سازی دیتابیس ووکامرس راهنمای کاملی است.

هر جدول اضافه‌شده در دیتابیس، یک مسیر احتمالی برای خرابی در مهاجرت است؛ شناخت این جدول‌ها پیش از Export، ضروری است.

روش‌های Export دیتابیس

سه روش اصلی برای Export دیتابیس وجود دارد که هرکدام برای شرایط خاص مناسب است.

روش اول: phpMyAdmin

phpMyAdmin در همه پنل‌های هاست وجود دارد و روش ساده‌ای برای Export دیتابیس فراهم می‌کند. از بخش Export، می‌توانید فرمت SQL را انتخاب کنید و تنظیمات Export را دقیق تنظیم کنید. نکته مهم: در تنظیمات Export، حالت Custom را انتخاب کنید و مطمئن شوید که گزینه Add DROP TABLE فعال است؛ اگر فعال باشد، جدول‌های موجود در سرور مقصد پیش از Import حذف می‌شوند که برای جلوگیری از خطاهای تداخل مفید است. محدودیت اصلی phpMyAdmin، دیتابیس‌های بزرگ است؛ اگر دیتابیس شما بیش از ۱۰۰ مگابایت باشد، معمولاً سرور مبدأ به‌دلیل محدودیت timeout، Export را نیمه‌کاره رها می‌کند.

روش دوم: WP-CLI

برای توسعه‌دهندگان و پروژه‌های جدی، WP-CLI انتخاب اول است. دستور wp db export backup.sql دیتابیس را در یک فایل SQL ذخیره می‌کند و این کار معمولاً بسیار سریع‌تر از phpMyAdmin انجام می‌شود. مزیت اصلی، امکان اضافه کردن پارامترهای اختصاصی است؛ مثلاً می‌توانید جداول خاصی را از Export مستثنا کنید یا فشرده‌سازی مستقیم روی خروجی اعمال کنید. اگر با محیط خط فرمان و SSH آشنایی ندارید، این روش ممکن است در ابتدا پیچیده به نظر برسد اما در پروژه‌های بزرگ، اثر آن روی زمان و صحت انتقال چشمگیر است.

روش سوم: mysqldump مستقیم

mysqldump یک ابزار خط فرمان MySQL است که مستقل از وردپرس کار می‌کند و بالاترین سطح کنترل را می‌دهد. مکانیزم دقیق این ابزار در وب به‌عنوان mysqldump مستند شده است. مزیت این روش، امکان فشرده‌سازی مستقیم با gzip و انتقال سریع بین دو سرور با pipe است. دستور رایج برای دیتابیس بزرگ، فشرده‌سازی مستقیم خروجی و انتقال تکه‌تکه است. محدودیت اصلی، نیاز به دسترسی SSH دارد که در همه هاست‌های اشتراکی فراهم نیست.

در انتخاب روش، دو عامل را در نظر بگیرید: حجم دیتابیس و سطح دسترسی شما به سرور. برای دیتابیس‌های کوچک (زیر ۵۰ مگابایت) phpMyAdmin کافی است؛ برای دیتابیس‌های متوسط و بزرگ (بیش از ۱۰۰ مگابایت) حتماً سراغ WP-CLI یا mysqldump بروید. اگر هاست شما دسترسی SSH ندارد و دیتابیس بزرگ است، می‌توانید از افزونه‌های تخصصی بکاپ استفاده کنید که در بهترین افزونه‌های پشتیبان‌گیری وردپرس معرفی شده‌اند.

روش‌های Import در سرور جدید

Import در سرور مقصد، سه روش اصلی دارد که مکمل روش‌های Export است.

روش اول: phpMyAdmin در سرور مقصد

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

روش دوم: WP-CLI در سرور مقصد

با دستور wp db import backup.sql، فایل SQL در دیتابیس مقصد Import می‌شود. این روش، سریع‌ترین و مطمئن‌ترین راه برای دیتابیس‌های بزرگ است چون PHP به‌عنوان واسطه حذف می‌شود و محدودیت‌های PHP روی Import اعمال نمی‌شود. اگر با ساختار فنی وردپرس آشنا هستید، این روش انتخاب اول من است.

روش سوم: دستور مستقیم MySQL در خط فرمان

با دستور mysql -u user -p dbname < backup.sql می‌توانید فایل SQL را مستقیماً در دیتابیس مقصد Import کنید. برای دیتابیس‌های بزرگ، این روش سریع‌ترین است چون هیچ لایه PHP در میان نیست. نکته مهم: قبل از Import، باید دیتابیس خالی ساخته شده و کاربر دیتابیس دسترسی درست داشته باشد.

یک نکته عملی که در پروژه‌های واقعی مرتب به کارم آمده: پس از Import، حتماً از phpMyAdmin یا WP-CLI تعداد رکوردهای جدول‌های اصلی را با مبدأ مقایسه کنید. این مقایسه، سریع‌ترین راه برای کشف Import نیمه‌کاره است.

کاراکترست و کالیشن: دام پنهان متن فارسی

کاراکترست و کالیشن، یکی از پرتکرارترین علل خرابی متن فارسی در مهاجرت است. اگر دیتابیس مبدأ با utf8mb4 ذخیره شده باشد و دیتابیس مقصد با latin1 یا utf8 (که در واقع utf8mb3 است) Import شود، همه حروف فارسی به علامت سؤال یا کاراکترهای نامفهوم تبدیل می‌شوند. اگر با مفهوم کاراکترست و کالیشن آشنا نیستید، به‌طور خلاصه: کاراکترست تعیین می‌کند هر کاراکتر چند بایت است و کالیشن تعیین می‌کند مرتب‌سازی چطور انجام شود. برای زبان فارسی، utf8mb4 با کالیشن utf8mb4_unicode_ci انتخاب استاندارد است.

تنظیم کاراکترست در Export و Import

در phpMyAdmin، هنگام Export، گزینه کاراکترست معمولاً از پیش تنظیم شده اما بهتر است دستی روی utf8mb4 تنظیم کنید. در WP-CLI و mysqldump، پارامتر --default-character-set=utf8mb4 را اضافه کنید. نکته مهم: در فایل SQL خروجی، باید خط SET NAMES utf8mb4 وجود داشته باشد. اگر ندارد، می‌توانید دستی اضافه کنید. اگر با ساختار فایل‌های قالب و پیکربندی وردپرس آشنا نیستید، چگونه فایل wp-config را امن کنیم مکانیزم پیکربندی اتصال دیتابیس را روشن می‌کند.

اصلاح کاراکترست اشتباه پس از Import

اگر پس از Import متوجه شدید که متن فارسی خراب شده، دو گزینه دارید. اول، دیتابیس را حذف کرده و با کاراکترست درست دوباره Import کنید. این روش ساده‌تر است و پیشنهاد من. دوم، با دستور ALTER TABLE کاراکترست را اصلاح کنید اما این کار همیشه به‌درستی جواب نمی‌دهد چون داده‌های خراب‌شده به‌صورت بایت اشتباه ذخیره شده‌اند و اصلاح کاراکترست لزوماً آن‌ها را بازنمی‌گرداند. توصیه قطعی: همیشه کاراکترست را از ابتدا درست تنظیم کنید.

پیشوند جدول‌ها و ملاحظات آن

پیشوند جدول‌ها، بخشی از نام هر جدول است که پیش از نام اصلی می‌آید. در نصب پیش‌فرض وردپرس، این پیشوند wp_ است. در سایت‌هایی که برای امنیت، پیشوند تغییر داده شده، ممکن است site_، wps_ یا چیز دیگری باشد.

هماهنگی پیشوند بین دیتابیس و wp-config

اگر پیشوند دیتابیس مبدأ با مقصد متفاوت است، دو گزینه دارید. اول، پیشوند فایل SQL را با ابزار جستجو و جایگزینی تغییر دهید. دوم، پیشوند سایت را از ابتدا یکسان نگه دارید. توصیه من، گزینه دوم است چون جایگزینی دستی پیشوند در فایل SQL، در دیتابیس‌های بزرگ خطاپذیر است. اگر مجبورید پیشوند را تغییر دهید، پیش از Import، در فایل wp-config.php سایت مقصد، متغیر $table_prefix را با پیشوند جدید هماهنگ کنید. عدم هماهنگی این دو، باعث می‌شود وردپرس نتواند به دیتابیس متصل شود و خطای اتصال نمایش داده شود.

تغییر پیشوند در دیتابیس‌های بزرگ

در دیتابیس‌های بزرگ، تغییر پیشوند با ابزارهای ساده سخت است. بعضی افزونه‌ها این کار را با فرآیند مرحله‌ای انجام می‌دهند اما خود این فرآیند هم ریسک دارد. در پروژه‌هایی که می‌خواهم پیشوند را تغییر دهم، از WP-CLI با دستور wp db query و اجرای مجموعه‌ای از دستورهای RENAME TABLE استفاده می‌کنم. هرچند حقیقت این است که در اکثر پروژه‌ها، تغییر پیشوند اولویت پایینی دارد و اگر از ابتدا پیشوند را یکسان نگه داریم، از این دردسر کاملاً پرهیز می‌کنیم.

جایگزینی URL و Serialized Data

اگر دامنه سایت مقصد با مبدأ متفاوت است، باید URLها در دیتابیس جایگزین شوند. این مرحله، فنی‌ترین بخش انتقال است و اگر اشتباه انجام شود، سایت با لینک‌های شکسته یا حتی خطای PHP مواجه می‌شود.

چالش Serialized Data

وردپرس در بعضی از ستون‌های دیتابیس، داده‌ها را به‌صورت Serialized ذخیره می‌کند. در این فرمت، طول هر رشته در ابتدای آن ذخیره می‌شود. مثلاً اگر URL با ۲۰ کاراکتر ذخیره شده باشد، در داده Serialized عدد ۲۰ در ابتدای آن ثبت شده است. حال اگر با یک کوئری SQL ساده، URL را به یک رشته با طول متفاوت تغییر دهید، عدد طول به‌روزرسانی نمی‌شود و داده Serialized خراب می‌شود. این خرابی، در PHP خودش را به شکل خطای Deserialization نشان می‌دهد که معمولاً کل صفحه را از کار می‌اندازد.

روش درست جایگزینی

روش درست، استفاده از ابزارهایی است که Serialized Data را می‌فهمند. سه گزینه اصلی وجود دارد. اول، WP-CLI با دستور wp search-replace 'old.com' 'new.com' که به‌صورت خودکار Serialized Data را مدیریت می‌کند و امکان اجرای خشک (Dry Run) هم دارد. دوم، افزونه Better Search Replace که رابط کاربری ساده‌ای روی همان منطق دارد. سوم، ابزارهای خط فرمان مثل interconnect/it Search-Replace-DB. توصیه من، WP-CLI است چون سریع‌تر و دقیق‌تر عمل می‌کند.

یک نکته مهم که در پروژه‌های واقعی به کارم آمده: پیش از جایگزینی، فهرست URLهای مبدأ را از دیتابیس با کوئری SELECT DISTINCT استخراج کنید تا مطمئن شوید همه تغییرات را پوشش داده‌اید. بعضی از URLها به‌صورت نسبی ذخیره شده‌اند و نیازی به جایگزینی ندارند اما بعضی به‌صورت مطلق ذخیره شده‌اند و باید تغییر کنند. پیش از هر جایگزینی، بکاپ دیتابیس بگیرید. اگر دیتابیس شما ووکامرس است، برخی URLها در جدول‌های اختصاصی هم وجود دارند که باید پوشش داده شوند. مکانیزم دقیق بهینه‌سازی دیتابیس را در چگونه دیتابیس وردپرس را پاک‌سازی کنیم بررسی کرده‌ام که در کنار جایگزینی، مفید است.

در جایگزینی URL، کوئری SQL خام، دشمن شماره یک شماست؛ ابزارهایی که Serialized Data را می‌فهمند، بهترین دوست شما هستند.

کاربران، نقش‌ها و Saltها

یکی از تفاوت‌های ظریفی که در انتقال دیتابیس نادیده گرفته می‌شود، رفتار رمزهای عبور و Saltها است.

رفتار رمز عبور در انتقال

رمزهای عبور کاربران وردپرس، به‌صورت Hash شده در جدول wp_users ذخیره می‌شوند. وقتی دیتابیس منتقل می‌شود، این Hashها هم منتقل می‌شوند و کاربران می‌توانند با رمز قبلی وارد شوند؛ به شرطی که Saltهای وردپرس تغییر نکرده باشند. Saltها در فایل wp-config.php نگه‌داری می‌شوند و اگر بین مبدأ و مقصد یکسان باشند، همه نشست‌ها و رمزها معتبر می‌مانند.

تصمیم‌گیری درباره Saltها

سه رویکرد برای Saltها وجود دارد. اول، انتقال همان Saltها از مبدأ به مقصد؛ در این حالت، کاربران بدون هیچ تغییری می‌توانند وارد شوند. دوم، تولید Saltهای تازه در مقصد؛ در این حالت، همه کاربران باید مجدداً وارد شوند اما امنیت بیشتر می‌شود. سوم، انتقال Saltها و سپس تغییر آن‌ها پس از انتقال. این رویکرد سومی که ترکیبی است، در پروژه‌های حساس منطقی است. اگر با تنظیمات wp-config و Saltها آشنا نیستید، چگونه فایل wp-config را امن کنیم جزئیات را توضیح می‌دهد.

نقش‌ها و متادیتای کاربر

در جدول wp_usermeta، نقش‌های کاربری و متادیتای دیگر ذخیره می‌شود. اگر دیتابیس به‌صورت کامل منتقل شود، نقش‌ها هم منتقل می‌شوند اما بهتر است پس از مهاجرت، این جدول را بازبینی کنید. اگر با نقش‌های کاربری وردپرس آشنا نیستید، تنظیمات کاربران و نقش‌ها در وردپرس تفاوت نقش‌ها را روشن می‌کند. در سایت‌هایی که چند ادمین داشتند، تجربه‌ام این است که گاهی متادیتای نقش یکی از ادمین‌ها در انتقال ناقص می‌شود و نیاز به اصلاح دستی دارد.

کرون، ترنزینت و کش در دیتابیس

سه بخش جانبی دیتابیس که در مهاجرت کمتر دیده می‌شوند اما در رفتار سایت پس از مهاجرت اثر جدی دارند: کرون، ترنزینت و کش دیتابیس.

کرون وردپرس

کرون وردپرس شامل رویدادهای زمان‌بندی‌شده است که در جدول wp_options با کلید cron نگه‌داری می‌شوند. با انتقال دیتابیس، این رویدادها هم منتقل می‌شوند اما ممکن است با زمان‌بندی سرور مقصد هماهنگ نباشند. اگر کرون وردپرس در زمان اشتباهی اجرا شود، پست‌های زمان‌بندی‌شده در ساعت غیرمنتظره منتشر می‌شوند یا تسک‌های پس‌زمینه ناهماهنگ اجرا می‌شوند. مفاهیم پایه کرون را در کرون وردپرس و زمان‌بندی خودکار کارها توضیح داده‌ام و برای حل مشکلات پس از مهاجرت، رفع مشکلات کرون در وردپرس راهنمای عملی است.

ترنزینت‌ها و کش دیتابیس

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

کش آبجکت در دیتابیس

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

پاک‌سازی و بهینه‌سازی پس از مهاجرت

پس از انتقال موفق، دیتابیس شما همچنان حاوی داده‌های اضافی است. سه دسته پاک‌سازی اصلی وجود دارد.

پاک‌سازی نسخه‌های قدیمی نوشته‌ها

در جدول wp_posts، برای هر نوشته، نسخه‌های Revision ذخیره می‌شوند. در سایت‌های چندساله، این نسخه‌ها حجم قابل توجهی از دیتابیس را اشغال می‌کنند بدون آنکه ارزش عملی داشته باشند. پاک‌سازی نسخه‌های قدیمی، معمولاً بین ۲۰ تا ۴۰ درصد حجم جدول را کم می‌کند. اگر با ساختار پست و رِویژن آشنا نیستید، بخش صادرات و نگهداری وردپرس توضیحات لازم را دارد. برخی افزونه‌ها این کار را با یک کلیک انجام می‌دهند اما توصیه من، انجام آن با کوئری SQL کنترل‌شده است تا خودتان بدانید چه چیزی پاک می‌شود. بهینه‌سازی کوئری‌ها هم بخشی از این پاک‌سازی است که در بهینه‌سازی کوئری‌های وردپرس با کدنویسی آمده است.

پاک‌سازی spam و نظرات بی‌استفاده

در سایت‌هایی که کامنت دارند، جدول wp_comments می‌تواند حاوی هزاران کامنت اسپم یا در انتظار تأیید باشد. پاک‌سازی این کامنت‌ها، هم دیتابیس را سبک‌تر می‌کند و هم پنل مدیریت را سریع‌تر می‌کند. روش دقیق این پاک‌سازی در پاک‌سازی اسپم و ترنزینت‌های دیتابیس وردپرس آمده است.

بهینه‌سازی جدول‌ها با OPTIMIZE TABLE

پس از پاک‌سازی، جدول‌ها ممکن است حاوی فضای خالی باشند. دستور OPTIMIZE TABLE در MySQL، این فضای خالی را آزاد می‌کند و جدول را جمع و جور می‌کند. این عملیات، در دیتابیس‌های بزرگ زمان‌بر است و ممکن است جدول را در دوره کوتاهی قفل کند؛ پس در ساعات کم‌ترافیک اجرا شود. تجربه‌ام این است که در دیتابیس‌های بالای ۵۰۰ مگابایت، این عملیات می‌تواند بین ۳۰ دقیقه تا چند ساعت طول بکشد و بهتر است با اجرای تکه‌تکه روی جدول‌های مختلف انجام شود.

تست و تأیید صحت انتقال

پس از Import و پاک‌سازی، مرحله تست شروع می‌شود. این مرحله، تفاوت بین مهاجرت آرام و مهاجرت پرحادثه است.

تست ساختاری

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

تست تعداد رکوردها

در phpMyAdmin یا با WP-CLI، تعداد رکوردهای جدول‌های اصلی را در مبدأ و مقصد مقایسه کنید. جدول‌های مهم: wp_posts، wp_postmeta، wp_users، wp_usermeta، wp_options، wp_comments. اگر تفاوت معناداری وجود دارد، احتمالاً Import نیمه‌کاره انجام شده و باید بررسی شود.

تست عملکرد

اگر سایت فروشگاهی است، سه سفارش آزمایشی با سناریوهای مختلف انجام دهید: سفارش ساده، سفارش با کوپن، سفارش با محصول متغیر. این تست‌ها بیشترین شکاف‌های دیتابیس را آشکار می‌کنند. سرعت سایت را هم اندازه بگیرید و با قبل از مهاجرت مقایسه کنید؛ اگر افت محسوسی دیده شد، احتمالاً لایه کش یا Object Cache در دیتابیس جدید به‌درستی پیکربندی نشده است. برای بازبینی جدی‌تر، بهینه‌سازی کوئری‌های وردپرس با کدنویسی دید عمیقی می‌دهد.

دیتابیس سالم، با تست چند رکورد و چند صفحه سنجیده نمی‌شود؛ با تست عملیاتی که در سایت روزمره رخ می‌دهد، سنجیده می‌شود.

خطاهای پرهزینه در انتقال دیتابیس

در بازبینی پروژه‌های انتقال دیتابیس، شش خطا بیشترین تکرار را داشته‌اند.

یک نکته اضافی از تجربه: اگر دیتابیس شما بیش از ۱ گیگابایت است، پیش از مهاجرت برنامه زمان‌بندی دقیق داشته باشید. مهاجرت روی سرور زنده و در ساعت پرباری، در دیتابیس بزرگ به‌احتمال زیاد نیمه‌کاره می‌ماند و بازگشت آن چند برابر زمان برنامه‌ریزی‌شده طول می‌کشد. اگر می‌خواهید اطمینان بیشتری در این لایه داشته باشید، بهترین افزونه‌های پشتیبان‌گیری وردپرس برای بکاپ‌های مرحله‌ای گزینه‌های خوبی ارائه می‌دهند.

پرسش‌های پرتکرار درباره انتقال دیتابیس

این پرسش‌ها در جلسات مشاوره و پشتیبانی مرتب تکرار می‌شوند و پاسخ‌های کوتاه و دقیق، ابهامات رایج را رفع می‌کند.

آیا می‌توانم فقط دیتابیس را منتقل کنم بدون فایل‌ها؟

فنی، بله. اما در عمل، دیتابیس شامل ارجاع‌هایی به فایل‌هاست که در پوشه uploads قرار دارند. اگر فقط دیتابیس را منتقل کنید و فایل‌ها را نه، سایت بالا می‌آید اما تصاویر نمایش داده نمی‌شوند. بنابراین، حتی اگر تمرکز این مقاله روی دیتابیس است، در پروژه واقعی، انتقال دیتابیس معمولاً هم‌زمان با فایل‌ها انجام می‌شود. اگر می‌خواهید فقط دیتابیس را منتقل کنید (مثلاً به‌دلیل انتقال داده از یک سایت به سایت دیگر)، مطمئن شوید که مسیر فایل‌ها در سایت جدید وجود دارد یا مسیرها بازنویسی شده‌اند.

اگر تعداد رکوردها بعد از Import کمتر شد، چه باید کرد؟

احتمالاً Import نیمه‌کاره انجام شده است. رایج‌ترین علت، محدودیت timeout یا محدودیت اندازه فایل در phpMyAdmin است. راه‌حل: از WP-CLI یا mysqldump برای Import استفاده کنید که محدودیت‌های PHP روی آن‌ها اعمال نمی‌شود. اگر مجبورید در phpMyAdmin بمانید، فایل SQL را به قطعات کوچک‌تر تقسیم کنید و هر قطعه را جداگانه Import کنید.

چرا پس از انتقال، متن‌های فارسی خراب شده‌اند؟

چون کاراکترست دیتابیس در Import اشتباه تنظیم شده است. رایج‌ترین حالت، Import یک دیتابیس utf8mb4 به‌عنوان latin1 یا utf8 است. راه‌حل درست: دیتابیس را حذف و مجدداً با کاراکترست درست Import کنید. اگر نمی‌خواهید این کار را انجام دهید، می‌توانید با ALTER TABLE کاراکترست را تغییر دهید اما این روش همیشه جواب نمی‌دهد. برای رفع ریشه‌ای، همیشه SET NAMES utf8mb4 را در ابتدای فایل SQL قرار دهید.

آیا می‌توانم دیتابیس را به‌صورت فشرده منتقل کنم؟

بله، و توصیه می‌شود. فایل‌های SQL معمولاً حجم زیادی دارند چون هر رکورد در یک خط چند صد بایتی نوشته می‌شود. با gzip، حجم معمولاً بین ۵۰ تا ۸۰ درصد کاهش می‌یابد. در phpMyAdmin، می‌توانید فایل gzip را مستقیماً Import کنید. در WP-CLI، با wp db export - | gzip > backup.sql.gz می‌توانید Export فشرده بگیرید.

آیا باید Saltها را بعد از مهاجرت تغییر دهم؟

اگر می‌خواهید همه کاربران مجدداً وارد شوند، بله. این کار در انتقال‌هایی که به‌دلیل مسائل امنیتی انجام می‌شود توصیه می‌شود. اگر می‌خواهید تجربه کاربری بدون مزاحمت باشد، Saltها را از مبدأ به مقصد منتقل کنید تا کاربران با رمز قبلی وارد شوند. برای سایت‌هایی که به‌دلیل مشکل هاست منتقل می‌شوند، تصمیم انتقال Saltها معمولاً انتخاب اول است.

آیا می‌توانم دیتابیس را روی سرور جداگانه نگه دارم؟

بله، در معماری‌های پیشرفته، دیتابیس روی سرور جداگانه اجرا می‌شود. این کار، هم بار را توزیع می‌کند و هم امنیت را بالا می‌برد. اما برای سایت‌های کوچک و متوسط، پیچیدگی و هزینه اضافه ایجاد می‌کند. برای فروشگاه‌های بزرگ با ترافیک بالا، جدا کردن دیتابیس انتخاب حرفه‌ای است. اگر با ساختار VPS آشنا نیستید، در راهنماهای پیشرفته وردپرس مباحث مربوط به معماری توضیح داده شده است.

چرا بعد از انتقال، پنل مدیریت کند شده است؟

سه علت اصلی: اول، ترنزینت‌ها و کش‌های قدیمی که در دیتابیس جدید بی‌استفاده مانده‌اند. دوم، عدم بهینه‌سازی جدول‌ها با OPTIMIZE TABLE. سوم، کوئری‌های قدیمی که روی سرور قبلی سریع بوده‌اند اما روی سرور جدید با ایندکس‌های متفاوت کند عمل می‌کنند. بازبینی با Query Monitor، سریع‌ترین راه برای کشف این مشکل است و بهینه‌سازی مکمل در بهینه‌سازی کوئری‌های وردپرس با کدنویسی آمده است.

آیا با انتقال دیتابیس، لینک‌های داخلی سایت هم حفظ می‌شوند؟

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

آیا می‌توانم از ابزارهای ابری برای انتقال دیتابیس استفاده کنم؟

بله، برخی سرویس‌ها این کار را انجام می‌دهند اما برای دیتابیس‌های حساس، توصیه من انجام دستی است. ابزارهای ابری، کنترل کمتری روی کاراکترست، پیشوند و Serialized Data می‌دهند و در صورت بروز مشکل، رفع آن سخت‌تر است. اگر با فضای ابری آشنا هستید و امنیت آن‌ها را می‌پذیرید، می‌توانید استفاده کنید اما توصیه من در پروژه‌های جدی، رویکرد دستی است.

دیتابیس سالم، پایه سایت پایدار

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

سه اصل عملی که در همه پروژه‌های انتقال دیتابیس رعایت می‌کنم: ابتدا بکاپ کامل و تست‌شده بگیرید و در هیچ مرحله‌ای آن را حذف نکنید. دوم، کاراکترست و Serialized Data را جدی بگیرید و از ابزارهای تخصصی برای جایگزینی استفاده کنید. سوم، پس از انتقال، حتماً دیتابیس را پاک‌سازی و بهینه‌سازی کنید. ترکیب این سه اصل، انتقال دیتابیس را از یک پروژه پرریسک به یک فرآیند قابل کنترل تبدیل می‌کند که با خیال راحت روی هر سایت وردپرسی قابل اجرا است.

اگر در انتقال دیتابیس سایت خود با موقعیت خاصی مواجه شده‌اید - مثلاً دیتابیس بسیار بزرگ، کاراکترست پیچیده یا مشکل جایگزینی URL - تجربه‌تان را بنویسید. این گزارش‌های واقعی، برای خواننده بعدی که در همان مرحله گیر کرده، از هر مستند رسمی مفیدتر است. ️