🔵 عنوان مقاله
The Evolution of Logical Replication in Postgres: A Historical Overview
🟢 خلاصه مقاله:
این مرور تاریخی نشان می‌دهد Logical Replication در Postgres طی حدود ۲۰ سال از راهکارهای مبتنی بر trigger مانند Slony، Bucardo و Londiste به دوران logical decoding از WAL و سپس ابزارهای بالغ‌تری مثل pglogical و در نهایت قابلیت داخلی publication/subscription در Postgres 10 رسیده است. راهکارهای اولیه گرچه مسیر را هموار کردند، با سربار، پیچیدگی عملیاتی و چالش‌های DDL و تعارض‌ها درگیر بودند. افزوده‌شدن logical decoding و سپس پیاده‌سازی داخلی، کارایی، فیلترگذاری و سهولت راه‌اندازی را بهبود داد، هرچند مسائلی مانند تکرار DDL و multi‑master همچنان حساس و وابسته به ابزارهای جانبی و شیوه‌های عملیاتی دقیق‌اند. به دلیل حضور طولانی Petr در پروژه‌های مرتبط و ارائه او در PostgresOpen 2016، این روایت معتبر و مبتنی بر تجربه عملی است.
#Postgres #PostgreSQL #LogicalReplication #WAL #pglogical #DatabaseReplication #OpenSourceDatabases
🟣لینک مقاله:
https://postgresweekly.com/link/174458/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The Evolution of Logical Replication in Postgres: A Historical Overview
🟢 خلاصه مقاله:
این مرور تاریخی نشان می‌دهد Logical Replication در Postgres طی حدود ۲۰ سال از راهکارهای مبتنی بر trigger مانند Slony، Bucardo و Londiste به دوران logical decoding از WAL و سپس ابزارهای بالغ‌تری مثل pglogical و در نهایت قابلیت داخلی publication/subscription در Postgres 10 رسیده است. راهکارهای اولیه گرچه مسیر را هموار کردند، با سربار، پیچیدگی عملیاتی و چالش‌های DDL و تعارض‌ها درگیر بودند. افزوده‌شدن logical decoding و سپس پیاده‌سازی داخلی، کارایی، فیلترگذاری و سهولت راه‌اندازی را بهبود داد، هرچند مسائلی مانند تکرار DDL و multi‑master همچنان حساس و وابسته به ابزارهای جانبی و شیوه‌های عملیاتی دقیق‌اند. به دلیل حضور طولانی Petr در پروژه‌های مرتبط و ارائه او در PostgresOpen 2016، این روایت معتبر و مبتنی بر تجربه عملی است.
#Postgres #PostgreSQL #LogicalReplication #WAL #pglogical #DatabaseReplication #OpenSourceDatabases
🟣لینک مقاله:
https://postgresweekly.com/link/174458/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
EDB
The Evolution of Logical Replication in PostgreSQL: A Firsthand Account
PostgreSQL has come a long way from its early days as a single-node database. If you’ve worked with PostgreSQL for a while, you’ll know its journey to robust logical replication was anything but straightforward, shaped by community efforts, creative workarounds…
🔵 عنوان مقاله
Postgres Migrations Using Logical Replication (7 minute read)
🟢 خلاصه مقاله:
مهاجرت پایگاه‌داده‌های بزرگ Postgres بدون توقف طولانی دشوار است؛ به‌ویژه در RDS که دسترسی مستقیم به WAL وجود ندارد. روش‌های سنتی مانند pg_dump/pg_restore برای داده‌های کم مناسب‌اند اما در مقیاس ترابایتی باعث قطعی طولانی می‌شوند. پشتیبان‌گیری فیزیکی مبتنی بر WAL برای کلون‌گیری مفید است، اما در جابه‌جایی منطقی، تغییرات طرح، یا مهاجرت بین پلتفرم‌ها کارایی ندارد و معمولاً به دسترسی WAL نیاز دارد.
راه‌حل عملی، logical replication است: پس از همگام‌سازی اولیه، تغییرات ردیفی به‌صورت پیوسته به مقصد استریم می‌شود تا در زمان برش نهایی، فقط وقفه‌ای کوتاه نیاز باشد. با این حال، logical replication طرح، ایندکس‌ها و sequences را منتقل نمی‌کند؛ بنابراین باید طرح و ایندکس‌ها را از قبل در مقصد بسازید و sequences را پیش از برش با setval همگام کنید. وجود کلید اصلی یا تنظیم مناسب REPLICA IDENTITY، پایش تاخیر تکرار و مدیریت تراکنش‌های بلندمدت ضروری است.
طرح کلی مهاجرت شامل این مراحل است: آماده‌سازی مقصد و اعمال طرح؛ بارگذاری اولیه داده (مثلاً با pg_dump --data-only و اجرای موازی)؛ ایجاد PUBLICATION در مبدأ و SUBSCRIPTION در مقصد؛ پایش pg_stat_subscription و اعتبارسنجی داده؛ سپس توقف موقت نوشتن، صبر تا صفر شدن تاخیر، هم‌ترازی sequences، سوئیچ برنامه به مقصد و نگه‌داشتن مبدأ در حالت فقط‌خواندنی برای بازگشت احتمالی. همچنین باید سازگاری نسخه‌ها، پهنای‌باند شبکه، و محدودیت‌های RDS را در نظر بگیرید. برای Postgres-to-Postgres، logical replication معمولاً کم‌هزینه‌ترین مسیر به مهاجرت با توقف حداقلی است.
#Postgres #LogicalReplication #DatabaseMigration #ZeroDowntime #AWSRDS #WAL #pg_dump #DevOps
🟣لینک مقاله:
https://www.crunchydata.com/blog/postgres-migrations-using-logical-replication?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Postgres Migrations Using Logical Replication (7 minute read)
🟢 خلاصه مقاله:
مهاجرت پایگاه‌داده‌های بزرگ Postgres بدون توقف طولانی دشوار است؛ به‌ویژه در RDS که دسترسی مستقیم به WAL وجود ندارد. روش‌های سنتی مانند pg_dump/pg_restore برای داده‌های کم مناسب‌اند اما در مقیاس ترابایتی باعث قطعی طولانی می‌شوند. پشتیبان‌گیری فیزیکی مبتنی بر WAL برای کلون‌گیری مفید است، اما در جابه‌جایی منطقی، تغییرات طرح، یا مهاجرت بین پلتفرم‌ها کارایی ندارد و معمولاً به دسترسی WAL نیاز دارد.
راه‌حل عملی، logical replication است: پس از همگام‌سازی اولیه، تغییرات ردیفی به‌صورت پیوسته به مقصد استریم می‌شود تا در زمان برش نهایی، فقط وقفه‌ای کوتاه نیاز باشد. با این حال، logical replication طرح، ایندکس‌ها و sequences را منتقل نمی‌کند؛ بنابراین باید طرح و ایندکس‌ها را از قبل در مقصد بسازید و sequences را پیش از برش با setval همگام کنید. وجود کلید اصلی یا تنظیم مناسب REPLICA IDENTITY، پایش تاخیر تکرار و مدیریت تراکنش‌های بلندمدت ضروری است.
طرح کلی مهاجرت شامل این مراحل است: آماده‌سازی مقصد و اعمال طرح؛ بارگذاری اولیه داده (مثلاً با pg_dump --data-only و اجرای موازی)؛ ایجاد PUBLICATION در مبدأ و SUBSCRIPTION در مقصد؛ پایش pg_stat_subscription و اعتبارسنجی داده؛ سپس توقف موقت نوشتن، صبر تا صفر شدن تاخیر، هم‌ترازی sequences، سوئیچ برنامه به مقصد و نگه‌داشتن مبدأ در حالت فقط‌خواندنی برای بازگشت احتمالی. همچنین باید سازگاری نسخه‌ها، پهنای‌باند شبکه، و محدودیت‌های RDS را در نظر بگیرید. برای Postgres-to-Postgres، logical replication معمولاً کم‌هزینه‌ترین مسیر به مهاجرت با توقف حداقلی است.
#Postgres #LogicalReplication #DatabaseMigration #ZeroDowntime #AWSRDS #WAL #pg_dump #DevOps
🟣لینک مقاله:
https://www.crunchydata.com/blog/postgres-migrations-using-logical-replication?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
Postgres Migrations Using Logical Replication | Crunchy Data Blog
Instructions and tips for using logical replication to migrate Postgres to a new platform or host.
🔵 عنوان مقاله
Postgres Migrations Using Logical Replication
🟢 خلاصه مقاله:
** مهاجرت به Postgres با تکیه بر Logical Replication به الگوی رایج برای جابه‌جایی کم‌وقفه تبدیل شده است؛ داده‌ها به‌صورت جریان تغییرات منتقل می‌شوند، اسکیما از پیش هماهنگ می‌شود و کات‌اور کنترل‌شده انجام می‌گیرد. در خبرها، یادداشت Elizabeth Christensen به تیتر طنزآمیز The Register درباره IBM و CockroachDB اشاره می‌کند، اما اصل ماجرا این است که IBM به ارائه گزینه‌ای Postgres‑like روی مین‌فریم فکر می‌کند؛ نشانه‌ای از پذیرش گسترده اکوسیستم Postgres و امکان استقرارهای ناهمگون که با Logical Replication به مهاجرت‌های مرحله‌ای کمک می‌کند. در بُعد کارایی، Aksman و Hein از TigerData در TimescaleDB نشان می‌دهند چرا DISTINCT روی داده‌های سری‌زمانی کند می‌شود و چگونه SkipScan با «پرش» در محدوده‌های ایندکس، این کوئری‌ها را سریع‌تر و بهینه‌تر می‌کند. همچنین Sebastian Insausti به بهبودهای عملیاتی و گزینه‌های یکپارچه‌سازی در Postgres 16 می‌پردازد که مدیریت عملیات، مشاهده‌پذیری و معماری‌های هیبریدی مبتنی بر Logical Replication را ساده‌تر می‌کند. توصیه عملی: همسان‌سازی اسکیما، توجه به sequences/constraints/triggers، کوتاه نگه‌داشتن تراکنش‌ها برای کاهش lag، رصد دقیق تاخیر اعمال، تمرین کات‌اور و داشتن مسیر بازگشت تا اطمینان از صحت داده‌ها.
#Postgres
#LogicalReplication
#TimescaleDB
#SkipScan
#CockroachDB
#IBM
#PostgreSQL
#Postgres16
🟣لینک مقاله:
https://postgresweekly.com/link/175398/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Postgres Migrations Using Logical Replication
🟢 خلاصه مقاله:
** مهاجرت به Postgres با تکیه بر Logical Replication به الگوی رایج برای جابه‌جایی کم‌وقفه تبدیل شده است؛ داده‌ها به‌صورت جریان تغییرات منتقل می‌شوند، اسکیما از پیش هماهنگ می‌شود و کات‌اور کنترل‌شده انجام می‌گیرد. در خبرها، یادداشت Elizabeth Christensen به تیتر طنزآمیز The Register درباره IBM و CockroachDB اشاره می‌کند، اما اصل ماجرا این است که IBM به ارائه گزینه‌ای Postgres‑like روی مین‌فریم فکر می‌کند؛ نشانه‌ای از پذیرش گسترده اکوسیستم Postgres و امکان استقرارهای ناهمگون که با Logical Replication به مهاجرت‌های مرحله‌ای کمک می‌کند. در بُعد کارایی، Aksman و Hein از TigerData در TimescaleDB نشان می‌دهند چرا DISTINCT روی داده‌های سری‌زمانی کند می‌شود و چگونه SkipScan با «پرش» در محدوده‌های ایندکس، این کوئری‌ها را سریع‌تر و بهینه‌تر می‌کند. همچنین Sebastian Insausti به بهبودهای عملیاتی و گزینه‌های یکپارچه‌سازی در Postgres 16 می‌پردازد که مدیریت عملیات، مشاهده‌پذیری و معماری‌های هیبریدی مبتنی بر Logical Replication را ساده‌تر می‌کند. توصیه عملی: همسان‌سازی اسکیما، توجه به sequences/constraints/triggers، کوتاه نگه‌داشتن تراکنش‌ها برای کاهش lag، رصد دقیق تاخیر اعمال، تمرین کات‌اور و داشتن مسیر بازگشت تا اطمینان از صحت داده‌ها.
#Postgres
#LogicalReplication
#TimescaleDB
#SkipScan
#CockroachDB
#IBM
#PostgreSQL
#Postgres16
🟣لینک مقاله:
https://postgresweekly.com/link/175398/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
Postgres Migrations Using Logical Replication | Crunchy Data Blog
Instructions and tips for using logical replication to migrate Postgres to a new platform or host.
🔵 عنوان مقاله
pg_easy_replicate 0.4: Switch Databases with Minimal Downtime
🟢 خلاصه مقاله:
pg_easy_replicate 0.4 یک اورکستریتور مبتنی بر Ruby است که راه‌اندازی تکثیر منطقی بین دو پایگاه‌داده Postgres را ساده می‌کند و امکان سوییچ کنترل‌شده به دیتابیس جدید را با حداقل زمان توقف فراهم می‌سازد. به‌جای پیکربندی دستی publication و subscription و نظارت دستی بر snapshot اولیه و تأخیر، این ابزار مراحل حساس را هدایت و خودکار می‌کند.
با همگام نگه‌داشتن منبع و مقصد از طریق تکثیر منطقی، می‌توانید محیط جدید را آماده و اعتبارسنجی کنید در حالی‌که کاربران همچنان روی دیتابیس فعلی کار می‌کنند؛ سپس در زمان مناسب، فرآیند cutover را با توقف بسیار کوتاه اجرا کرده و اتصال‌ها را به دیتابیس جدید منتقل کنید.
این رویکرد برای ارتقا نسخه، جابه‌جایی به سخت‌افزار یا کلاود/منطقه جدید، یا بازآرایی داده‌ها بدون پنجره نگه‌داری طولانی ایده‌آل است. تکیه بر تکثیر منطقی امکان مهاجرت‌های بین‌نسخه‌ای و استقرار تدریجی تغییرات را فراهم می‌کند. همچنین به‌دلیل پیاده‌سازی با Ruby، ادغام آن در اسکریپت‌ها، runbookها و خطوط CI/CD آسان است و ریسک عملیات را کاهش می‌دهد.
#Postgres #LogicalReplication #Ruby #DatabaseMigration #ZeroDowntime #DevOps #SRE
🟣لینک مقاله:
https://postgresweekly.com/link/176373/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pg_easy_replicate 0.4: Switch Databases with Minimal Downtime
🟢 خلاصه مقاله:
pg_easy_replicate 0.4 یک اورکستریتور مبتنی بر Ruby است که راه‌اندازی تکثیر منطقی بین دو پایگاه‌داده Postgres را ساده می‌کند و امکان سوییچ کنترل‌شده به دیتابیس جدید را با حداقل زمان توقف فراهم می‌سازد. به‌جای پیکربندی دستی publication و subscription و نظارت دستی بر snapshot اولیه و تأخیر، این ابزار مراحل حساس را هدایت و خودکار می‌کند.
با همگام نگه‌داشتن منبع و مقصد از طریق تکثیر منطقی، می‌توانید محیط جدید را آماده و اعتبارسنجی کنید در حالی‌که کاربران همچنان روی دیتابیس فعلی کار می‌کنند؛ سپس در زمان مناسب، فرآیند cutover را با توقف بسیار کوتاه اجرا کرده و اتصال‌ها را به دیتابیس جدید منتقل کنید.
این رویکرد برای ارتقا نسخه، جابه‌جایی به سخت‌افزار یا کلاود/منطقه جدید، یا بازآرایی داده‌ها بدون پنجره نگه‌داری طولانی ایده‌آل است. تکیه بر تکثیر منطقی امکان مهاجرت‌های بین‌نسخه‌ای و استقرار تدریجی تغییرات را فراهم می‌کند. همچنین به‌دلیل پیاده‌سازی با Ruby، ادغام آن در اسکریپت‌ها، runbookها و خطوط CI/CD آسان است و ریسک عملیات را کاهش می‌دهد.
#Postgres #LogicalReplication #Ruby #DatabaseMigration #ZeroDowntime #DevOps #SRE
🟣لینک مقاله:
https://postgresweekly.com/link/176373/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - shayonj/pg_easy_replicate: Easily setup logical replication and switchover to new database with minimal downtime
Easily setup logical replication and switchover to new database with minimal downtime - shayonj/pg_easy_replicate
🔵 عنوان مقاله
Spock: Logical Multi-Master PostgreSQL Replication
🟢 خلاصه مقاله:
این مقاله Spock را معرفی می‌کند؛ لایه‌ای برای Logical Multi‑Master Replication روی PostgreSQL که اجازه می‌دهد چند نود هم‌زمان عملیات نوشتن را بپذیرند و داده‌ها را بین خود همگام نگه دارند. برخلاف Physical Replication که به یک لیدر متکی است، Spock با استفاده از logical decoding تغییرات سطری را دریافت و روی نودهای دیگر اعمال می‌کند و بدین ترتیب امکان active‑active و حتی انتشار بخشی از DDL را فراهم می‌سازد.
نویسنده چالش‌های اصلی Multi‑Master را توضیح می‌دهد: تشخیص و رفع تضادهای نوشتن، سیاست‌های قابل پیکربندی مثل last‑update‑wins یا روش‌های سفارشی، مدیریت شناسه‌های یکتا و sequenceها، و تغییر توپولوژی بدون توقف. از نظر عملیاتی نیز نظارت بر lag، ثبت و رصد تضادها، و طراحی الگوهای اپلیکیشنی مثل upsert و عملیات idempotent ضروری است؛ استفاده از UUID به جای sequenceهای متمرکز می‌تواند تعارض‌ها را کم کند. نتیجه‌گیری این است که Spock جایگزین ساده برای سازگاری قوی سراسری نیست، اما برای سناریوهای active‑active با پذیرش eventual consistency گزینه‌ای قوی است.
در مقایسه با گزینه‌های دیگر (Built‑in Logical Replication تک‑مستر، Physical Streaming، و راهکارهایی مانند BDR یا Bucardo)، Spock تمرکز را بر Multi‑Master منطقی می‌گذارد و در قبال پیچیدگی بیشتر، استقلال از یک primary واحد را می‌دهد. از آن‌جا که این مطلب در Golang Weekly آمده، نکات پیاده‌سازی برای سرویس‌های Go نیز مطرح می‌شود: اتصال از طریق database/sql یا pgx به نود محلی برای کاهش تاخیر، مدیریت retry و conflict، و استفاده از الگوهایی مثل transactional outbox و CDC برای ساخت سیستم‌های رویدادمحور قابل اتکا.
#PostgreSQL #Spock #LogicalReplication #MultiMaster #Golang #DistributedSystems #DatabaseReplication #HighAvailability
🟣لینک مقاله:
https://postgresweekly.com/link/177326/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Spock: Logical Multi-Master PostgreSQL Replication
🟢 خلاصه مقاله:
این مقاله Spock را معرفی می‌کند؛ لایه‌ای برای Logical Multi‑Master Replication روی PostgreSQL که اجازه می‌دهد چند نود هم‌زمان عملیات نوشتن را بپذیرند و داده‌ها را بین خود همگام نگه دارند. برخلاف Physical Replication که به یک لیدر متکی است، Spock با استفاده از logical decoding تغییرات سطری را دریافت و روی نودهای دیگر اعمال می‌کند و بدین ترتیب امکان active‑active و حتی انتشار بخشی از DDL را فراهم می‌سازد.
نویسنده چالش‌های اصلی Multi‑Master را توضیح می‌دهد: تشخیص و رفع تضادهای نوشتن، سیاست‌های قابل پیکربندی مثل last‑update‑wins یا روش‌های سفارشی، مدیریت شناسه‌های یکتا و sequenceها، و تغییر توپولوژی بدون توقف. از نظر عملیاتی نیز نظارت بر lag، ثبت و رصد تضادها، و طراحی الگوهای اپلیکیشنی مثل upsert و عملیات idempotent ضروری است؛ استفاده از UUID به جای sequenceهای متمرکز می‌تواند تعارض‌ها را کم کند. نتیجه‌گیری این است که Spock جایگزین ساده برای سازگاری قوی سراسری نیست، اما برای سناریوهای active‑active با پذیرش eventual consistency گزینه‌ای قوی است.
در مقایسه با گزینه‌های دیگر (Built‑in Logical Replication تک‑مستر، Physical Streaming، و راهکارهایی مانند BDR یا Bucardo)، Spock تمرکز را بر Multi‑Master منطقی می‌گذارد و در قبال پیچیدگی بیشتر، استقلال از یک primary واحد را می‌دهد. از آن‌جا که این مطلب در Golang Weekly آمده، نکات پیاده‌سازی برای سرویس‌های Go نیز مطرح می‌شود: اتصال از طریق database/sql یا pgx به نود محلی برای کاهش تاخیر، مدیریت retry و conflict، و استفاده از الگوهایی مثل transactional outbox و CDC برای ساخت سیستم‌های رویدادمحور قابل اتکا.
#PostgreSQL #Spock #LogicalReplication #MultiMaster #Golang #DistributedSystems #DatabaseReplication #HighAvailability
🟣لینک مقاله:
https://postgresweekly.com/link/177326/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - pgEdge/spock: Logical multi-master PostgreSQL replication
Logical multi-master PostgreSQL replication. Contribute to pgEdge/spock development by creating an account on GitHub.