تصویر کلی
PostgreSQL logical replication بر مدل publish/subscribe بنا شده و تغییرهای داده را در سطح منطقی از publisher به subscriber می‌فرستد.
برای فهم این موضوع بهتر است اجزا را به‌عنوان یک مسیر ببینیم، نه مجموعه‌ای از گزینه‌های مستقل. در Production معمولاً مشکل زمانی شکل می‌گیرد که تنظیم روی دیسک، وضعیت Runtime و فرض تیم درباره رفتار سیستم با هم یکی نیستند. به همین دلیل مشاهده وضعیت مؤثر، Log و Metric باید کنار Configuration بررسی شود.
اجزای اصلی و مرز مسئولیت
Schema و DDL lifecycle نیاز به طراحی جدا دارند و replication slot می‌تواند در صورت توقف subscriber باعث نگهداری WAL شود.
در طراحی عملی، برای هر جزء یک سؤال روشن بنویسید: چه ورودی می‌گیرد، چه خروجی تولید می‌کند، چه Stateای نگه می‌دارد و در خرابی چه کسی مسئول Recovery است. این مدل ساده کمک می‌کند خطاهای شبکه، هویت، ذخیره‌سازی یا Replication به‌اشتباه به جزء دیگری نسبت داده نشوند.
خطاهای رایج
این قابلیت برای migration و selective replication مفید است اما جای backup، HA و failover design را به‌تنهایی نمی‌گیرد.
خطای دیگر، فعال‌کردن قابلیت پیشرفته بدون تعریف معیار موفقیت است. قبل از تغییر، Baseline بگیرید؛ بعد از تغییر همان Signalها را مقایسه کنید. اگر سیستم توزیع‌شده است، Failure Modeهای قطع شبکه، Restart، Lag، Timeout و از دست‌رفتن Dependency را نیز آزمایش کنید.
چک‌لیست عملی
- نسخه و Configuration مؤثر را ثبت کنید، نه فقط فایل مورد انتظار را.
- مسیر داده و کنترل را جدا رسم کنید.
- Health، Latency، Error Rate و ظرفیت را قبل و بعد از تغییر مقایسه کنید.
- برای تغییرات Stateful، Backup/Restore یا Rollback واقعی را آزمایش کنید.
- دسترسی مدیریتی را حداقل کنید و Log تصمیم‌ها را نگه دارید.
- مستندات همان نسخه محصول را مرجع نهایی قرار دهید.
تمرین IROSG
یک محیط کوچک آزمایشی بسازید و فقط یک Failure را تزریق کنید؛ مثلاً قطع Upstream، حذف یک Replica، خطای DNS یا تغییر Route. قبل از آزمایش بنویسید انتظار دارید کدام Metric و Log تغییر کند. بعد نتیجه واقعی را با انتظار مقایسه کنید. این تمرین معمولاً سریع‌تر از حفظ‌کردن Optionها، مدل ذهنی سیستم را اصلاح می‌کند.
مرجع
این راهنما بر پایه مستندات رسمی PostgreSQL نوشته شده و مثال‌های عملی تحریریه برای آموزش دفاعی و عملیاتی هستند.
جریان داده از ناشر تا مشترک
در یک سناریوی ساده، پایگاه داده اصلی جدول سفارش‌ها را منتشر می‌کند و پایگاه داده دیگری آن را برای گزارش‌گیری دریافت می‌کند. انتشار مشخص می‌کند کدام تغییرها در دامنه قرار دارند و اشتراک اتصال و دریافت آن‌ها را مدیریت می‌کند. معمولاً مرحله‌ای برای همگام کردن داده موجود و سپس ادامه تغییرهای جاری وجود دارد. باید بدانید مشترک در کدام مرحله است؛ دیدن بخشی از رکوردها ممکن است نتیجه انتقال اولیه ناتمام باشد، نه از دست رفتن داده. پایش باید وضعیت همگام‌سازی اولیه و جریان بعدی را جدا نشان دهد.
تکثیر منطقی، بیان تغییرهای داده در سطح جدول را هدف می‌گیرد و با کپی بایتی کل خوشه یکسان نیست. همین تفاوت انعطاف‌هایی ایجاد می‌کند، اما مسئولیت‌های بیشتری هم دارد. برای نمونه، ساختار مقصد باید با داده دریافتی سازگار باشد و تغییرهای طرح باید جدا هماهنگ شوند. قبل از انتخاب این روش برای مهاجرت یا گزارش‌گیری، فهرست دقیق چیزهایی را که انتظار انتقالشان را دارید بنویسید. جدول، دنباله، تعریف تابع، نقش و مجوز همگی یک نوع شیء نیستند و نباید انتقال خودکار همه آن‌ها فرض شود.
هویت ردیف هنگام تغییر و حذف
برای اعمال به‌روزرسانی یا حذف، مقصد باید بداند کدام ردیف هدف است. هویت تکثیر این نیاز را برطرف می‌کند و معمولاً کلید مناسب جدول نقش مهمی دارد. جدولی بدون شناسه پایدار می‌تواند هزینه و محدودیت بیشتری ایجاد کند. پیش از انتشار، کلیدهای جدول و نوع عملیات برنامه را بررسی کنید. اگر فقط درج را آزمایش کنید، ممکن است مشکل اصلی هنگام نخستین به‌روزرسانی یا حذف در تولید آشکار شود. آزمون پذیرش باید هر عملیاتی را که واقعاً در برنامه رخ می‌دهد پوشش دهد.
یک جدول آزمایشی با شناسه و مقدار بسازید. چند ردیف درج کنید، یکی را تغییر دهید و یکی را حذف کنید. پس از رسیدن مشترک، محتوای دقیق را مقایسه کنید. سپس یک عملیات چندردیفی در تراکنش انجام دهید و رفتار قابل مشاهده مقصد را بررسی کنید. برای نتیجه‌گیری درباره سازگاری، از خواندن تصادفی در میانه انتقال استفاده نکنید. زمان ثبت تغییر و زمان دیده شدن آن را کنار وضعیت تکثیر نگه دارید تا تأخیر با ناسازگاری اشتباه گرفته نشود.
تغییر طرح باید برنامه جدا داشته باشد
افزودن یک ستون در ناشر، مقصد را لزوماً به صورت خودکار آماده نمی‌کند. اگر داده تازه با ساختار مقصد سازگار نباشد، اعمال تغییر می‌تواند متوقف شود. برای تغییر طرح، ترتیب سازگار با هر دو سمت طراحی کنید. در بسیاری از سناریوها آماده کردن مقصد پیش از تولید داده جدید می‌تواند بخشی از راه‌حل باشد، ولی جزئیات به نوع تغییر و نسخه وابسته است. حذف یا تغییر نوع ستون را با دقت بیشتری آزمایش کنید، زیرا بازگشت ممکن است به بازیابی داده نیاز داشته باشد.
تغییر طرح را در همان آزمایشگاهی انجام دهید که بار نوشتن شبیه‌سازی می‌شود. فقط اجرای موفق دستور ساخت جدول کافی نیست. بررسی کنید تکثیر پس از تغییر ادامه دارد، برنامه مقصد پرس‌وجوی درست اجرا می‌کند و هیچ تبدیل ناخواسته‌ای رخ نداده است. نسخه طرح را در گزارش مهاجرت ثبت کنید. اگر دو تیم ناشر و مشترک را اداره می‌کنند، قرارداد تغییر باید زمان اطلاع‌رسانی، ترتیب اجرا و روش بازگشت را مشخص کند تا توقف جریان به اختلاف مسئولیت تبدیل نشود.
جایگاه اسلات و خطر رشد گزارش تراکنش
برای ادامه جریان از نقطه درست، ناشر وضعیت لازم را نگه می‌دارد. اگر مشترک برای مدت طولانی عقب بماند یا قطع شود، نگهداری داده لازم می‌تواند مصرف دیسک ناشر را افزایش دهد. بنابراین تکثیر یک مصرف‌کننده بی‌اثر نیست؛ خرابی مقصد ممکن است به ظرفیت مبدأ آسیب بزند. تأخیر، وضعیت اسلات و فضای دیسک باید همراه هم پایش شوند. هشدار صرف قطع اتصال کافی نیست، چون مشترک ممکن است متصل باشد ولی کندتر از نرخ تولید تغییر پیش برود.
در آزمایش، مشترک را برای بازه کوتاه و کنترل‌شده متوقف کنید و رشد داده نگهداری‌شده را ببینید. سپس آن را برگردانید و زمان رسیدن به وضعیت جاری را اندازه بگیرید. نرخ جبران باید از نرخ تولید تغییر بیشتر باشد تا عقب‌ماندگی کاهش یابد. اگر مشترک همیشه در مرز ظرفیت کار کند، یک قطعی کوتاه می‌تواند عقب‌ماندگی طولانی ایجاد کند. محدودیت‌های نگهداری و رفتار پس از عبور از آن‌ها را از مستندات نسخه نصب‌شده بررسی کنید؛ حذف عجولانه اسلات می‌تواند نیاز به همگام‌سازی دوباره ایجاد کند.
تعارض در مقصد را پیش از وقوع تعریف کنید
اگر برنامه دیگری همان جدول مقصد را تغییر دهد، ممکن است با داده ورودی تعارض بسازد. وجود ردیف با کلید تکراری یا نبود ردیف مورد انتظار نمونه‌هایی از مشکلات احتمالی‌اند. برای مشترکی که صرفاً گزارش‌گیری می‌کند، محدود کردن نوشتن مستقیم می‌تواند مدل را ساده‌تر کند. اگر نوشتن دوطرفه نیاز واقعی است، تکثیر ساده یک‌طرفه را بدون طراحی تعارض به معماری چندنویسنده تبدیل نکنید. مالک هر نوع داده و سیاست حل تعارض باید روشن باشد.
وقتی اعمال متوقف می‌شود، ابتدا خطای دقیق، جدول و تراکنش مربوط را پیدا کنید. تغییر داده مقصد برای عبور از خطا ممکن است لازم شود، اما باید اثر تجاری آن بررسی و ثبت شود. رد کردن یک تغییر بدون فهم آن می‌تواند اختلاف دائمی بسازد. پس از اصلاح، فقط ادامه جریان را تأیید نکنید؛ داده محدوده آسیب‌دیده را نیز تطبیق دهید. گزارش باید بگوید چه چیزی اصلاح شد و چگونه صحت آن سنجیده شد، نه فقط اینکه وضعیت سبز شده است.
استفاده برای مهاجرت و لحظه جابه‌جایی
در مهاجرت، مشترک ابتدا باید داده موجود را بگیرد و سپس به تغییرهای جاری نزدیک شود. پیش از انتقال کاربران، تأخیر را با معیار روشن بسنجید و نوشتن در مبدأ را طبق برنامه کنترل کنید. اگر در لحظه جابه‌جایی هر دو سمت نوشتن مستقل بپذیرند، احتمال اختلاف وجود دارد. قطع کوتاه نوشتن، رسیدن کامل تغییرها و سپس تغییر مسیر می‌تواند بخشی از طرح باشد، اما زمان‌بندی باید با نیاز خدمت و حجم واقعی آزمایش شود.
دنباله‌های تولید شناسه و تنظیمات خارج از جدول را نیز بررسی کنید. وجود آخرین ردیف در مقصد به معنی آماده بودن تولید شناسه بعدی نیست. پس از جابه‌جایی، یک تراکنش واقعی آزمایشی اجرا کنید که درج و روابط لازم را پوشش دهد. همچنین تکلیف بازگشت را روشن کنید: اگر مقصد شروع به دریافت نوشتن کرده، برگشت ساده نشانی اتصال ممکن است داده‌های جدید را در سمت قبلی نداشته باشد. برنامه بازگشت باید با نقطه بدون بازگشت و روش انتقال داده تازه سازگار باشد.
کنترل صحت بدون بار اضافی شدید
مقایسه شمار ردیف‌ها نقطه شروع است، اما برابر بودن تعداد، برابر بودن محتوا را ثابت نمی‌کند. برای داده مهم، مقایسه نمونه‌های هدفمند، جمع‌های کنترلی و بررسی محدوده‌های زمانی می‌تواند مفید باشد. این کار را با آگاهی از بار پرس‌وجو انجام دهید تا بررسی صحت به علت اختلال تبدیل نشود. جدول‌های بزرگ را به بخش‌های قابل مدیریت تقسیم کنید و زمان مقایسه را طوری انتخاب کنید که تغییر همزمان نتیجه را مبهم نکند.
در تحویل نهایی، وضعیت انتشار، اشتراک، هویت جدول‌ها، تأخیر مجاز و روش رفع توقف را مستند کنید. نسخه دقیق دو طرف نیز لازم است، زیرا قابلیت‌ها و محدودیت‌ها در طول زمان تغییر می‌کنند. تکثیر منطقی برای جابه‌جایی و توزیع انتخابی داده ارزشمند است، اما نسخه پشتیبان مستقل را حذف نمی‌کند. حذف اشتباه یا تغییر نامطلوب می‌تواند به مقصد هم برسد. آزمایش بازیابی تاریخی باید جدا از آزمایش ادامه تکثیر انجام شود تا هر دو نیاز واقعاً پوشش داده شوند.
مجوز اتصال و دامنه انتشار
حساب مورد استفاده مشترک را به نیاز واقعی محدود کنید و محل نگهداری اطلاعات اتصال را بررسی کنید. دسترسی شبکه به ناشر باید فقط از مبدأهای لازم برقرار باشد. رمزنگاری مسیر و اعتبار گواهی را نیز جدا آزمایش کنید؛ موفقیت اتصال با تنظیم سهل‌گیرانه دلیل کافی برای آماده بودن تولید نیست. در زمان تعویض رمز، ترتیب تغییر دو طرف را طوری بچینید که توقف کنترل‌شده و قابل تشخیص باشد. همچنین انتشار را پس از افزودن جدول‌های تازه بازبینی کنید. یک قاعده گسترده ممکن است داده حساس جدیدی را ناخواسته به مقصد گزارش‌گیری منتقل کند. مالک داده باید بداند چه جدول و چه دامنه‌ای منتشر می‌شود و مقصد چه سیاست نگهداری و دسترسی دارد. تکثیر داده، تکثیر مسئولیت حفاظت از آن نیز هست.
