داشتم یه مقاله فوق‌العاده از یه تجربه عملیاتی سنگین می‌خوندم با عنوان: «چطور یک میلیارد رکورد رو از DB1 به DB2 جابجا کردیم؛ بدون Downtime» 🚀

نویسنده مقاله (و تیمش) با یه چالش بزرگ روبرو بودن: دیتابیس قدیمیشون که دیتای حساس مالی (پرداخت، سفارش و...) رو نگه می‌داشت، از ۱ میلیارد رکورد رد شده بود و به شدت کند شده بود, Queryهایی که ثانیه‌ای طول می‌کشید، `Batch Job`ها (کارهایی که دسته‌ای مثل تسویه حساب‌ها) ساعتی طول می‌کشید. Scale کردن (افزایش مقیاس) دیگه جواب نمی‌داد و باید مهاجرت می‌کردن، اونم بدون حتی یک ثانیه Downtime (قطعی).

این خلاصه‌ی قدم‌به‌قدم کاریه که انجام دادن:

1️⃣ جابجایی دیتای قدیمی (Bulk Migration)

برای انتقال Cold data (دیتای قدیمی که دیگه تغییر نمی‌کنه)، نیومدن یه Dump (فایل خروجی) گنده بگیرن. به جاش:

✔️ جدول رو بر اساس رنج Primary Key (کلید اصلی جدول) به Chunk (تکه‌های کوچیک دیتا) تقسیم کردن.

✔️ موقع بارگذاری، ایندکس‌های ثانویه و `Constraint`ها (قیدها) رو غیرفعال کردن (تا سرعت Insert (ثبت دیتا) بالا بره).

✔️ چندتا ورکر رو Parallel (موازی) برای انتقال این تیکه‌ها ران کردن.

✔️ بعد از انتقال هر تیکه، یه Checksum (یه جور کد محاسباتی برای چک کردن یکی بودن دیتا) می‌گرفتن تا مطمئن بشن دیتا دقیقاً کپی شده.

2️⃣ مدیریت ترافیک زنده (Dual Writes)

چالش اصلی، دیتای جدیدی بود که همزمان با مهاجرت داشت وارد می‌شد.

✔️ اپلیکیشن رو طوری تغییر دادن که Dual Writes (نوشتن همزمان در دو دیتابیس) انجام بده (یعنی هر دیتای جدید رو همزمان هم تو دیتابیس قدیمی و هم تو دیتابیس جدید بنویسه).

✔️ برای اینکه مطمئن بشن دیتایی گم نمی‌شه، اگه نوشتن تو دیتابیس جدیده خراب می‌شد، اون رویداد (event) رو می‌نداختن توی یه `Retry Queue` کافکا (صفی برای کارهای شکست‌خورده که باید دوباره امتحان بشن).

✔️ یه Consumer (سرویسی که از صف کافکا دیتا می‌خونه) جدا اون صف رو می‌خوند و اونقدر تلاش می‌کرد تا بالاخره تو دیتابیس جدیده هم ثبت بشه.

✔️ برای جلوگیری از تکراری ثبت شدن دیتا (موقع تلاش مجدد)، همه‌ی نوشتن‌ها رو با آیدی یکتا Idempotent (یعنی اگه یه کاری رو چند بار هم اجرا کنی، نتیجه نهایی یکی باشه) کرده بودن.

3️⃣ تست پنهانی در پروداکشن (Shadow Reads)

خب، دیتاها سینک بودن. ولی آیا دیتابیس جدیده زیر بار واقعی جواب می‌داد؟

✔️ اینجا از Shadow Reads (خوندن پنهانی از دیتابیس جدید برای تست) استفاده کردن.

✔️ مشتری‌ها هنوز داشتن از دیتابیس قدیمی می‌خوندن اما در پشت صحنه، اپلیکیشن همون `Query` رو روی دیتابیس جدیده هم می‌زد و نتایج رو با هم مقایسه می‌کرد.

✔️ این کار باعث شد کلی باگ ریز ولی حیاتی رو پیدا کنن که تو تست‌ها معلوم نمی‌شد: مثلاً تفاوت رفتار Timezone ها (منطقه‌های زمانی)، تبدیل `NULL`ها (مقادیر پوچ) به مقادیر پیش‌فرض، و تفاوت در Collation (قواعد مرتب‌سازی و مقایسه متن‌ها) (که باعث می‌شد مرتب‌سازی نتایج فرق کنه).

4️⃣ لحظه جابجایی نهایی (The Cutover)

روز Cutover (لحظه جابجایی کامل و سوییچ کردن)، ریسک اصلی این بود که Cache (حافظه موقت) دیتابیس جدیده «سرد» (Cold) بود و اولین کوئری‌ها ممکن بود خیلی کند باشن.

✔️ قبل از سوییچ، با اجرای کوئری‌های مصنوعی، کش دیتابیس جدید رو Pre-warm (گرم کردن کش با دیتای الکی) کردن.

✔️ ساعت ۴:۳۰ صبح (کمترین ترافیک) با زدن یه Feature Flag (یه جور کلید نرم‌افزاری برای روشن/خاموش کردن قابلیت‌ها)، همه‌ی Read ها (خوندن‌ها) رو به سمت دیتابیس جدید فرستادن. (برای اطمینان، Dual Writes رو هنوز روشن نگه داشتن تا راه برگشت امن داشته باشن).

5️⃣ رصد کردن (Observability) 📊

نویسنده میگه چیزی که واقعاً نجاتشون داد، SQL خفن نبود، بلکه Observability (قابلیت رصد کامل سیستم) بود. اونا وسواسی همه‌چیز رو مانیتور می‌کردن:

✔️ با Replication Lag (میزان عقب بودن دیتابیس‌های کپی از دیتابیس اصلی)

✔️ با `Deadlock`ها (وقتی دوتا پروسه قفل منتظر هم می‌مونن)

✔️ با Cache Hit Ratio (درصدی از دیتا که از کش خونده می‌شه نه از دیسک)

✔️ با شمارنده‌ی عدم تطابق نتایج در Shadow Reads

✔️ و از همه مهم‌تر: `KPI`های بیزینسی (شاخص‌های کلیدی عملکرد مثل سفارش در دقیقه).

ما چی می تونیم یاد بگیریم؟ 💡

مهاجرت‌های بزرگ، یه «مسئله دیتابیسی» نیستن، بلکه یه «مسئله System Design (طراحی سیستم)» هستن.

شما یه میلیارد ردیف رو یهو جابجا نمی‌کنید، بلکه batch امن به batch امن»، «ورودی WAL (فایلی که دیتابیس قبل از هر کاری، تغییرات رو اول اونجا می‌نویسه) به WAL» و «Checksum به Checksum» این کار رو می‌کنید.

در نهایت: Zero Downtime (قطعی صفر) شانسی نیست؛ طراحیه.

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily