مهاجرت بدون‌وقفه PostgreSQL با logical replication

ارتقای نسخه پایگاه‌داده‌ای که ثانیه‌ای ۴۰۰ تراکنش می‌پذیرد، یک تصمیم ترسناک است. با logical replication این پنجره خاموشی — به شرط آمادگی — به صفر می‌رسد. نقشه دقیق همین مهاجرت را در این مقاله می‌بینید.

پیش‌نیازها قبل از شروع

• نسخه سازگار: مبدا و مقصد باید نسخه‌هایی باشند که هر دو پروتکل logical replication را پشتیبانی می‌کنند.
• ایندکس‌های همراه: همه ایندکس‌های اصلی باید از قبل روی مقصد ساخته شده باشند تا cutover کند نشود.
• سناریوی بازگشت: اگر cutover شکست خورد، مقصد رها و مبدا همچنان master می‌ماند.

گام‌های مهاجرت

1. ساخت publication روی مبدا

-- مبدا: انتشار همه جدول‌های سامانه تراکنشی
CREATE PUBLICATION tx_cluster FOR TABLE
  accounts, transactions, ledger_entries, audit_log;

2. ایجاد subscription روی مقصد و همگام‌سازی اولیه (طولانی‌ترین مرحله — برای ۲۴۰GB حدود ۶ ساعت).
3. دنبال کردن lag و رسیدن به ثانیه‌ای زیر ۱ ثانیه.
4. پنجره کوتاه read-only: تراکنش‌های در جریان flush، سوییچ اتصال اپلیکیشن، لغو subscription.

# مانیتورینگ lag در طول همگام‌سازی اولیه
def lag_seconds(cur):
    cur.execute("""
        SELECT EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp()))
    """)
    return float(cur.fetchone()[0])

هشدارهای cutover

مرحله	سیگنال سبز	سیگنال قرمز
همگام‌سازی	lag < ۱s پایدار ۱۵ دقیقه	lag بالا و صعودی
read-only	صف درخواست‌ها < ۵۰	صف > ۲۰۰ یا timeout
سوییچ	نرخ خطای اتصال ۰٪	هر ۵xx پیوسته ۳۰ ثانیه

مهاجرت بدون‌وقفه یعنی «تصمیم بازگشت» از قبل نوشته شده باشد؛ نه اینکه در لحظه بحران، تیم روی چت بحث کند.

نتیجه‌گیری

مهاجرت اصلی ما ۲۳ دقیقه طول کشید و هیچ خطای سمت کاربر ثبت نشد — نه به این خاطر که شانس آوردیم، بلکه چون هر گام قبل از اجرا روی یک کپی کامل تمرین شده بود. تمرین، تنها داروی ترس مهاجرت است.