قبلا در مورد replication توی دیتابیس mariadb پست گذاشتم و مفصل صحبت کردیم میدونیم که تئوری CAP باعث میشه همیشه یه جای کار بلنگه. اما mariadb اومده یه راه حلی ارائه داده که یکم تعادل بیشتری بینشون برقرار بشه. الان میخوام semi synchronous replication و توی دیتابیس mariadb بررسی کنم.
اول بریم به نگاهی به همه حالت های replication بندازیم
حالت اول Asynchronous Replication: این روش ساده‌ترین و سریع‌ترین حالت هست. وقتی داده‌ای روی سرور Master تغییر میکنه، این تغییر به سرورهای Replica ارسال میشه، اما سرور Master منتظر تأییدیه از سرورهای Replica نمی‌مونه و بلافاصله به کار خودش ادامه میده. این روش باعث میشه تا عملیات‌ها سریع‌تر انجام بشه، ولی یه مشکل جدی داره، اگه سرور Master قبل از اینکه سرورهای Replica داده‌ها رو دریافت کنن خراب بشه، اون داده‌ها از دست میرن.
حالت دوم Synchronous Replication: تو این حالت، سرور Master هر زمان که داده‌ای تغییر کرد، منتظر می‌مونه تا تمام سرورهای Replica تأیید کنن که داده‌ها رو دریافت کردن. تا زمانی که این تأییدیه‌ها نیاد، Master نمیره سراغ عملیات بعدی. این روش خیلی امنه، ولی باعث کاهش سرعت میشه، چون Master باید منتظر بمونه تا تمام Replica ها جواب بدن.
حالت سوم Semi-Synchronous Replication: این روش یه حالت بینابینیه. اینجا، Master منتظر می‌مونه تا حداقل یکی از سرورهای Replica تأیید کنه که داده‌ها رو دریافت کرده و بعد به کار خودش ادامه میده. اینطوری هم امنیت داده‌ها تضمین میشه و هم سرعت عملیات خیلی کاهش پیدا نمی‌کنه.
بریم ببینیم Semi-Synchronous Replication چطوری کار میکنه؟
وقتی یه تغییر تو node master اتفاق می‌افته، این تغییر تو فایلی به اسم Binlog (مخفف Binary Log) ثبت میشه. بعد این تغییرات به سرورهای Replica ارسال میشه. Master منتظر می‌مونه تا حداقل یکی از Replica ها اعلام کنه که این تغییرات رو گرفته و فقط بعد از این تأییدیه‌ست که عملیات بعدی رو انجام میده.
مزایای استفاده از Semi-Synchronous Replication چیه؟
این روش یه تعادل نسبی خوب بین سرعت و امنیت فراهم میکنه. در حالی که در روش Asynchronous ممکنه داده‌ها از دست برن و در روش Synchronous سرعت کاهش پیدا میکنه، این روش یه راه حل میانه است که هم سرعت خوبی داره و هم از، ازدست رفتن داده‌ها جلوگیری میکنه.
پشت پرده یا Under the Hood چه خبره؟
پشت پردش اینجوریه که این فرآیند با Binlog (که تغییرات رو ثبت میکنه) و یه تایمر انجام میشه. وقتی Master تغییرات رو به Replica ها می‌فرسته، منتظر می‌مونه تا تأییدیه بیاد. اگه بعد از یه مدت زمان مشخص تأییدیه‌ای نیاد، سرور Master ممکنه عملیات رو شکست‌خورده ثبت کنه یا دوباره تلاش کنه.
حالا چرا این روش مهمه؟
تو روش Asynchronous، اگه سرور Master بپره (یعنی به هر دلیلی از دسترس خارج بشه)، اون داده‌هایی که تازه ثبت شدن و به دست سرورهای Replica نرسیدن، ممکنه از دست برن. این یعنی درسته که سرعت ثبت داده‌ها بالاست، ولی خطر از دست دادن داده‌ها وجود داره. در مقابل، تو روش Synchronous، سرور Master برای ثبت هر تغییر صبر میکنه تا تمام سرورهای Replica تأیید کنن که داده‌ها رو دریافت کردن. این یعنی امنیت بالا ولی با هزینه کاهش سرعت.
اما تو Semi-Synchronous Replication، یه تعادل خوب بین این دو حالت داریم. اینجا سرور Master منتظر می‌مونه تا حداقل یکی از سرورهای Replica تأیید کنه که داده‌ها رو گرفته. اینطوری اگه یه مشکل برای Master پیش بیاد، حداقل یکی از سرورهای دیگه داده‌ها رو داره و می‌تونید با خیال راحت به کارتون ادامه بدید. البته هنوزم یه ذره سرعت نسبت به روش Asynchronous پایین‌تره، ولی عوضش امینت داریم.
برای محیط‌هایی که نیاز به سرعت و امنیت باهم داریم، این روش می‌تونه خیلی مفید باشه. مثلاً توی یه ecommerce project ، میتونیم نسبتا سریع به درخواست های کاربران پاسخ بدیم و هم مطمئن بشیم که اطلاعات هیچ وقت از دست نمی‌رن، این روش یه انتخاب خوبه.
