مهاجرت پایگاهداده یکی از حیاتیترین عملیاتها در چرخه عمر توسعهدهنده یا مدیر پایگاهداده (DBA) است. چه در حال انتقال از سرور محلی به یک سرویس ابری مدیریتشده مانند Amazon RDS یا Google Cloud SQL باشید، چه در حال ارتقا به یک نسخه اصلی جدیدتر، و یا صرفاً در حال بازسازی طرح پایگاهداده خود در چندین خوشه، ریسکها بسیار بالا هستند. یک مهاجرت ناموفق میتواند منجر به از دست رفتن دادهها، قطعی طولانیمدت و تأثیرات قابل توجه بر کسبوکار شود.
این راهنما فراتر از روشهای ساده بکگیری میرود تا راهبردهای مقاوم و مناسب برای محیطهای عملیاتی (Production) جهت مهاجرت پایگاهدادههای PostgreSQL را بررسی کند. ما راهحلهای تکدستوری برای مجموعهدادههای کوچکتر، همگامسازی مداوم دادهها برای مهاجرتهای بدون قطعی، و بهترین شیوهها برای اعتبارسنجی و بازگشت به عقب (Rollback) را پوشش خواهیم داد.
راهبرد ۱: رویکرد کلاسیک pg_dump
برای پایگاهدادههای کوچکتر (معمولاً کمتر از ۱۰۰ گیگابایت) یا در پنجرههای نگهداری برنامهریزیشده که قطعی قابل قبول است، pg_dump همچنان سادهترین و قابلاعتمادترین روش است. این ابزار یک اسکریپت SQL یا یک آرشیو با فرمت سفارشی تولید میکند که میتوان آن را در سرور مقصد بازیابی کرد.
کلید استفاده مؤثر از pg_dump در زمینه مهاجرت، استفاده از فرمت سفارشی (-Fc) است که امکان بازیابی موازی و انعطافپذیری بیشتر را فراهم میکند.
# از سرور مبدأ
pg_dump -Fc -h source_host -U source_user -d my_database -f backup.dump
# در سرور مقصد
pg_restore -h dest_host -U dest_user -d new_database backup.dumpاگرچه این روش ساده است، اما نیازمند یک دوره قطعی است که در آن برنامه نمیتواند به پایگاهداده بنویسد. اگر یک برنامه زنده دارید، باید اطمینان حاصل کنید که برنامه از حالت آفلاین خارج شده یا در حین فرآیند بکگیری به یک کپی خواندنی (Read-only Replica) هدایت شود تا از سازگاری دادهها اطمینان حاصل شود.
راهبرد ۲: مهاجرت بدون قطعی با استفاده از Replication منطقی
برای برنامههای حیاتی که نمیتوانند هزینه قطعی را بپردازند، Replication منطقی استاندارد طلایی است. این روش به شما اجازه میدهد پایگاهداده مبدأ و مقصد را به طور مداوم همگام نگه دارید و به شما امکان میدهد ترافیک را در یک لحظه دقیق تغییر مسیر دهید.
مرحله ۱: آمادهسازی مقصد
ابتدا یک پایگاهداده خالی در سرور هدف با همان طرح ایجاد کنید. اطمینان حاصل کنید که wal_level در هر دو سرور مبدأ و مقصد روی logical تنظیم شده است.
مرحله ۲: ایجاد Publication و Subscription
در سرور مبدأ، یک Publication برای جداولی که میخواهید مهاجرت دهید ایجاد کنید:
CREATE PUBLICATION my_migration_pub FOR TABLE users, orders, products;در سرور مقصد، یک Subscription ایجاد کنید که به مبدأ متصل شود:
CREATE SUBSCRIPTION my_migration_sub
CONNECTION 'host=source_ip dbname=my_database user=replicator password=secret'
PUBLICATION my_migration_pub;پستگرس اکنون شروع به همگامسازی دادهها از مبدأ به مقصد خواهد کرد. میتوانید پیشرفت را از طریق نمای سیستم pg_stat_subscription نظارت کنید. پس از تکمیل همگامسازی اولیه و رسیدن به تغییرات زنده، میتوانید عملیات تغییر مسیر (Cutover) را انجام دهید.
اعتبارسنجی و تغییر مسیر (Cutover)
قبل از تغییر ترافیک، یک اعتبارسنجی نهایی انجام دهید. تعداد سطرها و چکسامها را برای جداول حیاتی در هر دو نمونه بررسی کنید. زمانی که آماده تغییر مسیر هستید، نوشتن در پایگاهداده مبدأ را متوقف کنید (یا Subscription را در مقصد متوقف کنید تا از سازگاری اطمینان حاصل شود).
-- متوقف کردن Subscription برای اطمینان از همگامسازی نهایی
SELECT pg_subscription_rel.*, pg_stat_replication.*
FROM pg_subscription_rel
JOIN pg_stat_replication ON pg_subscription_rel.sql_localid = pg_stat_replication.pid;پس از اینکه تأخیر Replication به صفر رسید، Subscription را غیرفعال کنید، رشته اتصال برنامه خود را به سمت پایگاهداده جدید تغییر دهید و نوشتن را مجدداً فعال کنید. برنامه را در ساعات اولیه به دقت نظارت کنید تا از پایداری آن اطمینان حاصل شود.
نتیجهگیری
انتخاب استراتژی مهاجرت مناسب به اندازه دادهها، میزان قطعی قابل قبول و پیچیدگی زیرساخت شما بستگی دارد. برای تغییرات کوچک، pg_dump کافی است. برای الزامات در سطح سازمانی، Replication منطقی ایمنی و تداوم مورد نیاز برای انتقالهای بینقص را فراهم میکند. همیشه فرآیند مهاجرت خود را در یک محیط آزمایشی (Staging) قبل از انجام آن در محیط عملیاتی تست کنید تا ریسکها را کاهش داده و از اجرای روان اطمینان حاصل کنید.