سلام

سؤالتون درباره پیاده‌سازی معماری multi master group replication یا چیزی شبیه به اون برای پایگاه‌داده PostgreSQL در یک شبکه داخلی (بدون اینترنت)، مخصوصاً با کاربرد مانیتورینگ آلارم‌های دزدگیر، بسیار مهم و تخصصی هست. نکاتی که گفتید (UDP بودن، نیاز به HA، سینک شدن دیتا فقط روی یک تیبل خاص به صورت هات، بقیه تیبل‌ها کلد) کاملاً حرفه‌ای مطرح شده و نشون می‌ده معماری رو به خوبی درک کردید.

اجازه بدید قدم به قدم راهنمایی کنم:

چرا Multi-Master در PostgreSQL چالش‌برانگیز است؟

PostgreSQL به صورت پیش‌فرض فقط replication master-slave (primary-standby) رو ساپورت می‌کنه.
راه‌حل‌های multi-master یا group replication به صورت native در PostgreSQL وجود نداره، ولی چند راه‌حل معروف شخص ثالث هست که می‌تونن تا حد زیادی نیاز شما رو پوشش بدن. همچنین، باید حواستون باشه که sync کردن فقط یک تیبل به صورت هات و بقیه به صورت کلد، کمی معماری رو پیچیده‌تر می‌کنه.

راه‌حل‌ها و تکنولوژی‌های پیشنهادی

استفاده از ابزارهای Multi-Master برای PostgreSQL

1. Bucardo

• یک ابزار open source برای asynchronous multi-master replication در PostgreSQL.
• می‌تونید تعیین کنید فقط یک یا چند جدول (مثلاً همان جدول آلارم) به صورت دوطرفه (bi-directional) sync بشه.
• مناسب برای سناریوهایی که latency کم بسیار مهم نیست (در حد چند ثانیه تأخیر قابل قبول باشه).
• مستندات Bucardo

2. Pglogical

• یک extension برای PostgreSQL که logical replication رو به صورت پیشرفته‌تر ممکن می‌کنه.
• می‌تونید replication فقط برای یک یا چند جدول خاص راه بندازید.
• برای multi-master باید با دقت تنظیم بشه و به خوبی تست بشه (conflict resolution نیاز داره).

Postgres-BDR (Bi-Directional Replication)

• یک راه‌حل حرفه‌ای برای replication دوطرفه.
• کاملاً مناسب سناریوهای multi-master ولی نسخه enterprise آن تجاری است (بعضی ورژن‌های opensource قدیمی‌تر هم موجود است).
• Postgres-BDR

معماری پیشنهادی برای نیاز شما

با توجه به توضیحات:

• جدول آلارم‌ها (alarms): باید real-time و دوطرفه بین دو سرور sync بشه (هات).
• سایر جداول: فقط هر از گاهی، به صورت سرد (کلد) سینک بشه (مثلاً با بکاپ و ریستور یا replication یکطرفه).

یک راه‌حل عملیاتی:

1. استفاده از Bucardo یا Pglogical فقط برای جدول alarms
   • هر دو سرور به عنوان master تعریف می‌شن.
   • فقط جدول alarms در replication قرار می‌گیره.
   • conflict resolution باید به درستی انجام بشه (کلید یکتا، timestamp و…)
2. سایر جداول را با یک برنامه زمان‌بندی شده (اسکریپت بکاپ/ریستور یا logical dump) سینک کنید.
   • مثلاً هر شب یا هفته‌ای یکبار.
3. در سمت اپلیکیشن حتماً هر آلارم، یک شناسه یکتا داشته باشه (که اگر از دو ورودی مختلف وارد شد، تکراری نشه).
4. مانیتورینگ health replication رو حتماً پیاده کنید تا از sync بودن دیتا مطمئن بشید.

• اگر latency خیلی کم و ریسک از دست رفتن حتی یک آلارم هم قابل قبول نیست، بهتره اپلیکیشن طوری طراحی بشه که اگر آلارم به یک سرور رسید و در سرور دیگر نبود، خودش با یک مکانیسم retry یا pull، داده رو بفرسته.
• هر دو سرور باید همزمان write و read داشته باشن، پس باید دقت کنید که replication conflict (مثلاً دو آلارم با یک id) پیش نیاد.
• چون شبکه داخلی هستید، محدودیت latency و bandwidth کمتره، پس replication منطقی‌تر و قابل اطمینان‌تر خواهد بود.