Replicate Postgres DB for Microservice Architecture (قسمت اول معرفی)

در معماری Microservice سعی میکنیم بهترین روش ها رو پیاده کنیم و توی معماری نرم افزار کاری وجود نداره که برای تمام پروژه ها درست باشه و باید سعی کرد با توجه به پروژه بهترین روش ها رو پیاده کردما میتونیم پروژه رو در دو حالت Scale کنیم1. Vertical Scaling2. Horizontal Scalingتو مورد اول ما به افزایش منابع سرور رو میارم و مشخصات سرور رو زیاد میکنمتو مورد دوم ما با استفاده از ماشین های بیشتر درخواست ها رو هندل میکنیمبرای مثال یه پروژه LMS دانشجویی رو تصور کنید که باید در ساعات خاص زیر بار پردازش زیادی برهتو وهله اول شاید بگید مشخص ما پهنای باند هست که خب عموما در بیشتر Web App ها شما میتونید با ایجاد چند Process از برنامه و اجرا در سرور های مختلف و اتصال به یک پایگاه داده واحد این مسئله رو بهبود بدیدتو وهله دوم مشکل پردازشی از سمت سرور پایگاه داده بروز میکنه که شما باید کوئری هزاران کاربر رو در یه ماشین پردازش کنید، برای حل این مسئله و خوشه بندی کردن پایگاه داده باید یک سرور به عنوان خوشه اصلی و چندین سرور به عنوان خوشه فرعی در نظر گرفته بشهحالا ما میخوایم برای بهبود سیستم و کاهش فشار به سرور و اجتناب از Vertical Scaling سرور اصلی، پایگاه داده، داده ها رو بر روی سرور های فرعی بالا بیاریم و سرویس ها برای خواندن از سرور های فرعی استفاده کنن و به اصطلاح به این عملیات CQRS یا تفکیک مسئولیت خواندن نوشتن هم گفته میشهعملیات Replication پایگاه داده به معنی اینه ما یه نمونه از پایگاه داده اصلی رو تهیه میکنیم که میتونه این پایگاه داده روی چند سرور مختلف باشهمدل های مختلف Replicationدو مدل مختلف برای همچین کاری ارائه شدهSingle-Master Replication (SMR)Multi-Master Replication (MMR)در مدل SMR چندین سرور فرعی و فقط یک سرور اصلی وجود دارد که سرور های فرعی فقط خواندنی یا read-only هستن و قابلیت نوشتن اطلاعات براشون وجود نداره در حالی که سرور اصلی خواندن و نوشتن ازاد هستدر مدل MMR تمام سرور ها قابلیت خواندن و نوشتن رو دارند ولی مشکلات و حساسیت خودشون رو در پیاده سازی و بهره برداری دارندبه صورت built-in شما میتونید از مدل SMR در Postgres استفاده کنید ولی برای MMR ابزار های دیگه ای وجود داره که میتونید پایگاه داده Postgres رو به صورت MMR پیاده کنید مانند BDRداخل Postgres روشی وجود داره برای اینکه تمام تغییرات رو در قالب فایل با عنوان WAL ذخیره سازی کنه، در واقع هر تغییری که در یک تراکنش انجام می شود (INSERT ، UPDATE ، DELETE ، COMMIT) در به عنوان یک رکورد WAL نوشته می شود و اینو با سرور های فرعی یا Standby یا Slave به اشتراک میزاریم و یه سری پایگاه داده replicate شده درست کنیم، رکوردهای WAL ابتدا در یک بافر در حافظه نوشته می شوند و زمان تکمیل تراکنش،رکوردهای در یک WAL Segment روی دیسک نوشته می شوند.یه سری فایل WAL تعریف شده که به صورت پیش فرض فعاله و در قالب فایل های 16 مگابایتی لاگ میکنه و یه نکته ای که در رابطه با این فایل ها هست اینه که بهتون قابلیت point-in-time recovery و on-line backup میده میتونید با این هدف هم ازشون استفاده کنیداستفاده از WAL باعث کاهش قابل توجه نوشتن دیسک میشه، چون توسط WAL Writer در پس زمینه به صورت مرتب WAL رکوردها داخل WAL Segment نوشته میشن و به ازای هر تغییری که transaction ها ایجاد میکنند فایل ها اپدیت نمیشن و ضمانت داده ها زمان flush شدن روی دیسک هست که با پارامتر wal_writer_delay قابل تنظیم هست و به صورت پیش فرض 200ms هستشما میتونید در Postgres نسخه 12 به قبل با استفاده از wal_keep_segments و در Postgres نسخه 13 wal_keep_size در فایل کانفیگ Postgres سایز ماکسیمم فایل های WAL رو تغییر بدید که به نسبت با افزایش سایز ریسک از دست دادن داده در مقابل crash و اشکالات احتمالی بیشتر میشهبا استفاده از WAL دو روش برای replicate کردن دیتا ها و وجود داره:File-Based Log ShippingStreaming WAL RecordsFile-Based Log Shippingدر این روش فایل های WAL از سرور اصلی به slave ارسال شده که میتوان با ایجاد یک share storage اشتراک فایل ها رو پیاده کردStreaming WAL Recordsسرور اصلی فایل های WAL را stream می کنند و سرورهای فرعی با ایجاد ارتباط تحت replication protocol با سرور اصلی قطعات WAL را دریافت می کنند و مزیت stream فایل های WAL این است که منتظر پر شدن ظرفیت نیست و بلافاصله stream می شودحالت های Replicationاستریم کردن داده ها در دو نوع asynchronous و synchronous هست که در تصویر زیر حالت Asynchronous رو میبینید که با commit شدن تراکنش در پایگاه داده اصلی با سرعت بیشتری انجام میشود و به همین ترتیب تغییر در پایگاه داده های فرعی اعمال میشود و این باعث ایجاد یه اختلاف در یه مدت کوتاه بین داده های پایگاه داده اصلی و فرعی میشودAsynchronousدر تصویر زیر حالت Synchronous رو میبینید که تا زمانی که تراکنش در تمام پایگاه های داده commit نشود کار به پایان نرسیده، در این حالت زمان اجرای دستورات نوشتنی بیشتر بوده ولی اطلاعات بین پایگاه های داده ثابت هستند و نیازمند در دسترس بودن تمام سرور های فرعی هستSynchronousدر قسمت بعد این مطلب میتونید درباره روش پیاده سازی و تنظیمات Postgres مطالعه کنید (در حال کتابت)References:PostgreSQL: Documentation: 13: 19.6. ReplicationPostgreSQL: Documentation: 12: 19.6. ReplicationPostgreSQL: Documentation: 13: 29.2. Write-Ahead Logging (WAL)Staging Environment – Definition, Benefits, And Limitations | FeedoughPostgres WAL Replication: Easy Step-By-Step Guide - Learn | HevoSynchronous and asynchronous replication in PostgreSQL | CYBERTECManaging PostgreSQL Replication and PostgreSQL Automatic Failover for High Availability