Database Labdon
884 subscribers
37 photos
3 videos
1 file
903 links
🕸 Database Academy

حمایت مالی:
https://www.coffeete.ir/mrbardia72

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
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
🔵 عنوان مقاله
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
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
🔵 عنوان مقاله
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