🔵 عنوان مقاله
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.
🔵 عنوان مقاله
Switching Me Softly (7 minute read)
🟢 خلاصه مقاله:
فریشا با ساخت یک چارچوب ارکستریشن خودکار و قابلپیکربندی، بیش از ۲۰ پایگاهداده حیاتی PostgreSQL را از PG12 به PG17 با صفر downtime و بدون از دستدادن داده ارتقا داد. این راهکار با اسکریپتهای مبتنیبر YAML، مهاجرتهای تکرارپذیر و قابل بازگشت را ممکن کرد و چالشهای حساس نظیر مدیریت Debezium CDC، حفظ ترتیب رویدادهای outbox، کنترل replication slotها و اجرای cutoverهای روان با PgBouncer را پوشش داد. در نتیجه، محدودیتهای RDS Blue/Green و ارتقای درجا برطرف شد و یک الگوی پایدار برای ارتقاهای آینده در محیط تولید شکل گرفت.
#PostgreSQL #ZeroDowntime #DatabaseMigration #Debezium #CDC #PgBouncer #YAML #RDSBlueGreen
🟣لینک مقاله:
https://medium.com/fresha-data-engineering/switching-me-softly-cb404d02c28b?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Switching Me Softly (7 minute read)
🟢 خلاصه مقاله:
فریشا با ساخت یک چارچوب ارکستریشن خودکار و قابلپیکربندی، بیش از ۲۰ پایگاهداده حیاتی PostgreSQL را از PG12 به PG17 با صفر downtime و بدون از دستدادن داده ارتقا داد. این راهکار با اسکریپتهای مبتنیبر YAML، مهاجرتهای تکرارپذیر و قابل بازگشت را ممکن کرد و چالشهای حساس نظیر مدیریت Debezium CDC، حفظ ترتیب رویدادهای outbox، کنترل replication slotها و اجرای cutoverهای روان با PgBouncer را پوشش داد. در نتیجه، محدودیتهای RDS Blue/Green و ارتقای درجا برطرف شد و یک الگوی پایدار برای ارتقاهای آینده در محیط تولید شکل گرفت.
#PostgreSQL #ZeroDowntime #DatabaseMigration #Debezium #CDC #PgBouncer #YAML #RDSBlueGreen
🟣لینک مقاله:
https://medium.com/fresha-data-engineering/switching-me-softly-cb404d02c28b?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Medium
Switching me Softly
Zero-downtime PostgreSQL 12→17 upgrade at Fresha: RDS snapshots, logical replication, PgBouncer tricks & Debezium orchestration.
❤1
🔵 عنوان مقاله
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
🔵 عنوان مقاله
14x Faster with 12x Less Compute: Sometimes Postgres Really is All You Need
🟢 خلاصه مقاله:
تیم جیمز یک کلاستر ۱۲ سروره مبتنی بر HBase/OpenTSDB را که برای دادههای سریزمانی استفاده میشد، با سامانهای بسیار سادهتر بر پایه Postgres/Timescale جایگزین کرد. نتیجه: پرسوجوها تا ۱۴ برابر سریعتر، با ۱۲ برابر محاسبات کمتر، و ۱۰۰٪ دسترسپذیری پس از مهاجرت.
آنها با تکیه بر SQL و قابلیتهای Timescale مانند hypertable، فشردهسازی، continuous aggregates و خطمشیهای نگهداشت داده، هم کارایی پرسوجوها و هم پایداری ingestion را بهبود دادند. طرح مهاجرت شامل dual-write، backfill موازی و اعتبارسنجی دقیق بود و در نهایت کل سامانه روی دو سرور با replication و failover خودکار پایدار شد.
پیام اصلی: برای بسیاری از بارهای کاری سریزمانی، Postgres/Timescale با طراحی درستِ شِما، ایندکسهای هدفمند و ابزارهای استاندارد، هزینه و پیچیدگی عملیاتی را بهطور چشمگیری کاهش میدهد و کارایی را بالا میبرد—گرچه برای نرخنوشتن یا کاردینالیتهی بسیار شدید، پایگاههای تخصصی هنوز مزیت دارند.
#Postgres #TimescaleDB #TimeSeries #OpenTSDB #HBase #DatabaseMigration #PerformanceEngineering #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/176022/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
14x Faster with 12x Less Compute: Sometimes Postgres Really is All You Need
🟢 خلاصه مقاله:
تیم جیمز یک کلاستر ۱۲ سروره مبتنی بر HBase/OpenTSDB را که برای دادههای سریزمانی استفاده میشد، با سامانهای بسیار سادهتر بر پایه Postgres/Timescale جایگزین کرد. نتیجه: پرسوجوها تا ۱۴ برابر سریعتر، با ۱۲ برابر محاسبات کمتر، و ۱۰۰٪ دسترسپذیری پس از مهاجرت.
آنها با تکیه بر SQL و قابلیتهای Timescale مانند hypertable، فشردهسازی، continuous aggregates و خطمشیهای نگهداشت داده، هم کارایی پرسوجوها و هم پایداری ingestion را بهبود دادند. طرح مهاجرت شامل dual-write، backfill موازی و اعتبارسنجی دقیق بود و در نهایت کل سامانه روی دو سرور با replication و failover خودکار پایدار شد.
پیام اصلی: برای بسیاری از بارهای کاری سریزمانی، Postgres/Timescale با طراحی درستِ شِما، ایندکسهای هدفمند و ابزارهای استاندارد، هزینه و پیچیدگی عملیاتی را بهطور چشمگیری کاهش میدهد و کارایی را بالا میبرد—گرچه برای نرخنوشتن یا کاردینالیتهی بسیار شدید، پایگاههای تخصصی هنوز مزیت دارند.
#Postgres #TimescaleDB #TimeSeries #OpenTSDB #HBase #DatabaseMigration #PerformanceEngineering #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/176022/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
YouTube
James Udiljak - 14x Faster with 12x Less Compute: Sometimes Postgres Really Is All You Need
How big is ""Big Data"" really? The definition has changed drastically over time.
In this talk, James recounts building his own database on top of Postgres to replace a legacy HBase/OpenTSDB cluster. While once considered ""Big Data"", the real-time monitoring…
In this talk, James recounts building his own database on top of Postgres to replace a legacy HBase/OpenTSDB cluster. While once considered ""Big Data"", the real-time monitoring…