بلاگ بیپیدا / انتقال وردپرس
انتقال وردپرس بدون Downtime؛ معماری، هماهنگی داده و Cutover امن
انتقال بدون قطعی وردپرس به هماهنگی دیتابیس، Upload، Session، Cache و Cron نیاز دارد؛ معماری، Cutover، Verification و Rollback را عملی بررسی کنید.
انتقال بدون Downtime در وردپرس یعنی کاربران در تمام مدت جابه‌جایی درخواست معتبر دریافت کنند و هیچ داده commitشده‌ای گم یا تکراری نشود. این هدف فقط با کپی سریع فایل یا TTL پایین محقق نمی‌شود؛ دیتابیس، Upload، Session، Cache، Jobهای زمان‌بندی‌شده، ایمیل و Callbackهای بیرونی باید روی مالک هر write توافق داشته باشند.
پاسخ سریع: تا آماده‌شدن مقصد یک مسیر نوشتن authoritative نگه دارید. فایل‌ها را از قبل کپی، داده متغیر را پیوسته یا مرحله‌ای همگام و مقصد را با ترافیک شبیه Production تست کنید. در مرز Cutover، Workerهای تکراری را متوقف، replication را به نقطه همگام برسانید یا write freeze بسیار کوتاه اجرا کنید، ترافیک را تغییر دهید و تراکنش و Jobها را تطبیق دهید. اگر سازگاری داده تضمین نمی‌شود، maintenance کوتاه انتخاب درست‌تری است و نباید Zero Downtime نامیده شود.
Zero Downtime را برای همین سایت تعریف کنید
سایت شرکتی و فروشگاه ووکامرس قرارداد دسترس‌پذیری یکسان ندارند. مشخص کنید کدام عملیات باید همیشه فعال بماند: مشاهده صفحه، ورود، Checkout، Upload، Comment، API Write، انتشار زمان‌بندی‌شده یا تغییر مدیریتی. نرخ خطای قابل‌قبول و امکان read-only کوتاه را نیز تعریف کنید.
بدون این تعریف ممکن است صفحه اصلی از Cache باز شود، اما فرم، پرداخت یا Webhook شکست بخورد و انتقال همچنان «بدون قطعی» گزارش شود.
با مدل Single Writer شروع کنید
در هر لحظه یک دیتابیس باید مالک authoritative نوشتن باشد. دو وب‌سرور می‌توانند read سازگار ارائه دهند، اما write مستقل روی دو دیتابیس conflictهایی می‌سازد که WordPress خودکار merge نمی‌کند. ID، وضعیت سفارش، موجودی، user meta، option و scheduled action ممکن است واگرا شوند.
Active/Active write به semantics تعارض نیاز دارد که برای برنامه طراحی و تست شده باشد. replication معمول MySQL سیستم merge چندنویسنده نیست.
تمام Stateهای قابل‌تغییر را فهرست کنید
- جدول‌های MySQL یا MariaDB
wp-content/uploadsو رسانه تولیدشده- Session یا فایل موقت
- Object Cache و Transient
- Page Cache و CDN Cache
- WP-Cron، Action Scheduler و Worker سفارشی
- صف ایمیل، پرداخت، Search، Storage و Webhook
- Config و Secret خارج از WordPress
طرحی که فقط فایل و SQL را ببیند، ممکن است ایمیل را دوبار بفرستد، Upload را گم کند یا Callback پرداخت را تکرار کند.
روش همگام‌سازی داده را انتخاب کنید
برای سایت متوسط، کپی اولیه به‌علاوه write freeze بسیار کوتاه و sync نهایی معمولاً کم‌ریسک‌ترین انتخاب است. برای الزام سخت‌تر، replication می‌تواند بازه Cutover را کم کند، اما نیازمند سازگاری نسخه، شبکه، privilege، binary log، پایش lag و Promotion کنترل‌شده است.
مستندات Replication در MySQL مدل معمول source-to-replica را به‌صورت پیش‌فرض asynchronous توصیف می‌کند؛ source مستقل commit می‌کند و replica بعداً transaction را اعمال می‌کند. بنابراین فعال‌بودن replication اثبات نمی‌کند آخرین transaction روی مقصد apply شده است.
Replication بکاپ یا Cutover خودکار نیست
حذف اشتباه و write خراب نیز سریع replicate می‌شود؛ Backup مستقل و Restore Test همچنان لازم است. Promotion به توالی روشن نیاز دارد: توقف یا هدایت write، تأیید position، جلوگیری از write تازه روی source قدیمی، promotion مقصد و تغییر endpoint برنامه.
فرمان replication را هنگام حادثه بداهه اجرا نکنید. نسخه MySQL یا MariaDB، GTID، محدودیت Provider و topology روش صحیح را تغییر می‌دهد.
Upload را بدون حذف فایل معتبر همگام کنید
Media Library را پیش‌کپی و نزدیک Cutover دوباره incremental sync کنید. اگر Upload باید در تمام مدت فعال باشد، دو محیط به Object Storage مشترک، filesystem replicated با consistency مشخص یا routing نیاز دارند که همه Uploadها را به origin authoritative ببرد.
Sync دوطرفه ذاتاً امن نیست؛ edit و delete هم‌زمان نیازمند قانون conflict هستند. در مهاجرت تأییدنشده از delete گسترده اجتناب و count، size و نمونه رسانه را مقایسه کنید.
Session و Authentication را قابل‌حمل کنید
Cookie ورود WordPress به secret مشترک و URL سازگار وابسته است. افزونه‌ها ممکن است Session را در فایل، دیتابیس یا Redis نگه دارند. اگر ترافیک به هر دو محیط می‌رسد، هر Node باید state لازم، salt، cookie setting، headerهای HTTPS و namespace سازگار داشته باشد.
Logout شدن شاید برای بعضی سایت‌ها قابل‌قبول باشد، اما گم‌شدن Cart یا Checkout خطای تجاری است. رفتار مورد انتظار را پیش از انتقال ثبت کنید.
از اجرای تکراری Cron و Worker جلوگیری کنید
طبق مستند رسمی Loopback وردپرس، WordPress از درخواست بازگشتی برای شروع WP-Cron استفاده می‌کند. اگر هر دو محیط event سررسیدشده را spawn کنند، انتشار، ایمیل، Import یا Job افزونه ممکن است دوبار اجرا شود.
در مهاجرت یک owner برای scheduler انتخاب کنید. Worker محیط passive را غیرفعال یا ایزوله و مالکیت را آگاهانه جابه‌جا کنید. برای Queue و Callback پرداخت، idempotency و reconciliation لازم است.
Cache را بدون انتشار State خصوصی گرم کنید
صفحات عمومی و مسیرهای حیاتی مقصد را warm کنید، اما Cache directory مبهم را کورکورانه کپی نکنید. Cache key می‌تواند hostname، path، salt، version یا object serialized داشته باشد. Namespace پیش‌نمایش نباید Cache تولید را آلوده کند.
Checkout، Account، Admin و مسیر write API باید از Full-page Cache خارج باشند. Exclusionها را پس از تغییر ترافیک هم تست کنید.
با hostname نهایی و Dependency واقعی تست کنید
از hosts mapping کنترل‌شده، Backend test در Load Balancer یا Preview محدود با hostname نهایی استفاده کنید. TLS، Proxy Header، Cookie، Redirect، CORS، REST API، Loopback، ایمیل، Storage و API بیرونی را بسنجید. آزمون IP خام بسیاری از این رفتارها را نشان نمی‌دهد.
فقط ترافیک synthetic یا داده پاک‌سازی‌شده را replay کنید؛ تست نباید سفارش واقعی، اعلان مشتری یا capture پرداخت بسازد.
لایه ترافیک با Switching کنترل‌شده داشته باشید
Reverse Proxy، تغییر Origin در CDN یا Load Balancer معمولاً Cutover کنترل‌شده‌تری از اتکا به DNS Cache می‌دهد. Healthcheck باید پاسخ معنادار برنامه را بسنجد و connection draining اجازه دهد درخواست in-flight پیش از حذف Backend قدیمی تمام شود.
برای معماری مستقیم، DNS همچنان مهم است. چک‌لیست انتقال وردپرس TTL، IPv6، CDN و مشاهده دو مبدأ را توضیح می‌دهد.
Runbook با Gateهای صریح بنویسید
- Backup، Restore، سلامت مقصد و Monitoring را تأیید کنید.
- File Sync و سلامت Replication یا آمادگی Final Copy را بسنجید.
- تغییر مدیریتی را متوقف و Scheduler تکراری را ایزوله کنید.
- مرز نهایی Write را ثبت کنید.
- Catch-up دیتابیس و Upload نهایی را تأیید کنید.
- Endpoint دیتابیس و لایه ترافیک را تغییر دهید.
- آزمون Synthetic و Business Acceptance اجرا کنید.
- Error، Lag، Queue، سفارش و دو مبدأ را مانیتور کنید.
هر Gate به مسئول، مدرک، Timeout و شرط Rollback نیاز دارد؛ «به‌نظر خوب است» معیار پذیرش نیست.
Consistency تجاری را پس از Cutover تأیید کنید
فقط HTTP status را نبینید. تعداد سفارش و پرداخت اطراف مرز Cutover را تطبیق دهید، Queueهای failed و pending، آخرین Upload و تغییر حساب را بررسی و آخرین transaction مبدأ را با مقصد مقایسه کنید. برای سایت محتوایی، scheduled post و form submission مهم‌اند.
راهنمای مانیتورینگ سرور سیگنال زیرساخت و کاربر را توضیح می‌دهد، اما شمارنده‌های تجاری مخصوص برنامه‌اند.
Rollback را پیش از پذیرش Write جدید طراحی کنید
پیش از Cutover، بازگشت ممکن است تغییر ترافیک به محیط قبلی باشد. پس از پذیرش write روی مقصد، این کار داده تازه را حذف یا تکراری می‌کند. نقطه‌ای تعیین کنید که بعد از آن fix-forward امن‌تر است، یا اگر بازگشت بدون زیان الزام واقعی است مسیر معکوس داده را از قبل تست کنید.
پس از واگرایی دو Source، مبدأ قدیمی را خودسرانه promote نکنید؛ بازیابی split-brain عملیات داده است، نه DNS.
چه زمانی Maintenance کوتاه انتخاب بهتر است؟
اگر replication امن نیست، Upload قابل‌اشتراک نیست، Callback بیرونی ایزوله نمی‌شود یا تیم امکان مشاهده و reconciliation ندارد، maintenance کنترل‌شده را انتخاب کنید. توقف پنج‌دقیقه‌ای write می‌تواند بسیار مطمئن‌تر از topology آزمون‌نشده باشد.
برای مهاجرت مرحله‌ای به سرور مجازی، راهنمای انتقال وردپرس به VPS را ببینید.
خطاهای رایج مهاجرت بدون قطعی
- برابر دانستن صفحه Cacheشده با Availability برنامه
- نوشتن مستقل روی دو دیتابیس
- Promotion بدون اثبات Catch-up
- اجرای Cron و Worker در هر دو محیط
- فراموش‌کردن Upload، Session یا Queue بیرونی
- استفاده از TTL به‌عنوان کل برنامه Cutover
- Rollback سرور بدون Data Reconciliation
- حذف آزمون Business-level
چه زمانی طراحی تخصصی لازم است؟
فروشگاه پرتراکنش، سایت عضویتی، Media Library بزرگ، Multisite یا SLO سخت به عملیات هماهنگ برنامه و داده نیاز دارد. سرویس انتقال سایت وردپرس می‌تواند بازبینی topology، Sync مرحله‌ای، Cutover و Verification را پوشش دهد.
پرسش‌های متداول
آیا TTL پایین Zero Downtime را تضمین می‌کند؟
خیر. TTL فقط cache پاسخ DNS را کوتاه می‌کند و دیتابیس، Upload، Session یا Worker را همگام نمی‌کند.
آیا دو WordPress می‌توانند روی یک دیتابیس بنویسند؟
فقط وقتی امنیت شبکه، latency، سازگاری و failure behavior عمداً طراحی و تست شده باشد؛ راه میان‌بر عمومی نیست.
آیا Replication در MySQL هم‌زمان است؟
Replication معمول source-to-replica به‌صورت پیش‌فرض asynchronous است و مقصد می‌تواند lag داشته باشد؛ Catch-up باید اندازه‌گیری شود.
آیا ووکامرس بدون Maintenance منتقل می‌شود؟
با معماری حافظ سفارش، موجودی، Session، Upload و Callback بله؛ اگر این تضمین‌ها فراهم نیست، write pause کوتاه امن‌تر است.
قدم بعدی شما
برای حل این مسئله به کمک نیاز دارید؟
شرح مشکل و نتیجهٔ بررسی‌هایتان را در یک درخواست پشتیبانی بنویسید.
ثبت درخواست پشتیبانی