Galera replication: مقایسه عملکرد با MySQL replication

 

 

Galera replication نسبت به MySQL replication تکنولوژی جدیدتری می‌باشد. که بطور  پیش‌فرض از نسخه MySQL v3.23 پشتیبانی می شود. اگرچه MySQL replication برای replication تک جهته master-slave طراحی شده است. و می توان آن را به عنوان تنظیمات فعال master-master با replication دو طرفه پیکربندی کرد. باید توجه داشت که راه اندازی آن آسان است و برخی ممکن است از این قابلیت استفاده نمایند. اما تعدادی معایب نیز در طرف دیگر این مزیت وجود دارد. Galera cluster یک تکنولوژی متفاوت از لحاظ یادگیری و مدیریت است.

در این مطلب قصد داریم master-master replication را با Galera cluster مقایسه نماییم.

مفاهیم replication

قبلاز اینکه به سراغ مقایسه برویم بهتر است کمی مطالب پایه ای تر را مرور نماییم. به طور کلی ، هر گونه تغییر در پایگاه داده MySQL یک رویداد در قالب باینری ایجاد می‌کند. بسته به روش replication انتخاب شده، این رویداد به نودهای دیگر منتقل می شود. MySQL replication (پیشفرض) یا Galera replication ( با wsrep APIمتصل گردیده).

 

MySQL Replication

دیاگرام زیر جریان داده های یک تراکنش موفق را از یک نود به نود دیگر هنگام استفاده از MySQL replication نشان می دهد:

galera cluster

رویداد باینری در Master binary نوشته می شود. Slave (ها) از طریق slave_IO_thread رویدادهای باینری را از log باینری master بیرون می کشند و آنها را در log خود تکرار می کند. سپس slave_SQL_thread رویداد را از log تکرار خود به صورت غیرهمزمان اعمال می کند. به دلیل ماهیت ناهمزمان replication، هنگامی که master تغییرات را در داده های خود انجام می دهد ، تغییر در داده‌های slave ممکن است انجام نپذیرد.

در حالت ایده‌آل ، MySQL replication با تنظیم read_only = ON یا super_read_only = ON می‌تواند slave را به عنوان یک سرور فقط خواندنی پیکربندی کند. این کار یک اقدام احتیاطی برای محافظت از slaveها در برابر نوشتن تصادفی است که می تواند منجر به ناسازگاری داده‌ها گردد. با این حال ، در تنظیمات active-active replication، تنظیم read-only باید در master دیگر غیرفعال شود تا پردازش به طور همزمان انجام شود.

 

Galera Replication

دیاگرام زیر جریان replication داده های یک تراکنش موفق از یک نود به نودهای دیگر را در Galera Cluster نشان می دهد:

Galera Cluster

 

این رویداد در یک مجموعه محصور شده و با استفاده از Galera replication از نود مبدأ به نودهای دیگر خوشه پخش می شود. این عمل با هر گذشت از هر نود یک گواهی دریافت می‌نماید. رشته‌های اعمال کننده هر ترد به صورت همزمان تغییرات را در داده ها اعمال می‌نمایند. این بدان معنی است که سرور slave بعد از اتمام مراحل با دیگر سرورها سازگار خواهند شد، این عمل به صورت تئوری همزمان است اما عمل نوشتن و گرفتن تاییدیه به صورت مستقل برای هرکدام اتفاق می‌افتد.  بنابراین به طور همزمان در هر نود با تایید تغییر برای انتشار در همه گره ها این عمل صورت می‌پذیرد.

اجتناب از Key Collision در Galera replication

برای استقرار MySQL replication در تنظیمات master-master، در اولین قدم یکی باید مقدار افزایش خودکار را تنظیم کند تا از key collision اصلی برای INSERT بین دو یا چند replicating master تکرار جلوگیری شود. این موضوغ کمک می‌کند تا مقدار کلید اصلی با دیگران هم ردیف شود و از افزایش دوبرابری اتوماتیک تعداد در هر یک از نودها جلوگیری شود. این تنظیمات باید به صورت دستی پیکربندی شوند.

Master1:

log-slave-updates
auto_increment_increment=2
auto_increment_offset=1
Master2:
log-slave-updates
auto_increment_increment=2
auto_increment_offset=2
به همین ترتیب ، Galera Cluster از همین ترفند برای جلوگیری از key collision با کنترل مقدار افزایش خودکار استفاده کرده و به طور خودکار با متغیر wsrep_auto_increment_control آن را جبران می‌کند. اگر روی 1 تنظیم شود (پیش فرض) ، متغیرهای auto_increment_increment و auto_increment_offset به طور خودکار با توجه به اندازه خوشه تنظیم می شوند، و هنگامی که اندازه خوشه تغییر می کند. با این کار از collision به دلیل خودکارسازی جلوگیری می شود.
نتیجه این پیکربندی این است که مقدار افزایش خودکار دیگر به ترتیب نیست، همانطور که در جدول زیر نشان داده شده است:
Node auto_increment_increment auto_increment_offset Auto increment value
Node 1 3 1 1, 4, 7, 10, 13, 16…
Node 2 3 2 2, 5, 8, 11, 14, 17…
Node 3 3 3 3, 6, 9, 12, 15, 18…

 

اگر برنامه ای به ترتیب زیر کار انجام دهد:
Node1, Node3, Node2, Node3, Node3, Node1, Node3
مقدار گره های اصلی به صورت زیر می‌شوند:
1, 6, 8, 9, 12, 13, 15
به زبان ساده، هنگام استفاده از master-master replication (MySQL replication یا Galera)، برنامه شما باید بتواند مقادیر افزایش خودکار غیر پی در پی را در مجموعه داده های خود ایجاد کند.

سازگاری داده ها در Galera replication و MySQL replication

در Galera Cluster همه نود ها باید با یک سرعت داده های خود را همانند سازی نمایند در غیر این صورت نود ها سرعت خود را کاهش می‌دهند تا نود کند تر نیز بتواند به سرعت آنها برسد. این عمل باعث جلوگیری از لگ زدن slave می‌گردد. هرچند که این اتفاق بازهم ممکن است روی دهد اما به اندازه MySQL replication نمی‌باشد. از طرف دیگر ، Galera Cluster از عدم تطابق داده‌ها جلوگیری می کند ، در نتیجه اگر نودی به هر دلیلی نتواند هرگونه عمل نوشتن را انجام دهد، از خوشه خارج می شود.

150305 16:13:14 [ERROR] WSREP: Failed to apply trx 1 4 times
150305 16:13:14 [ERROR] WSREP: Node consistency compromized, aborting..
برای رفع سازگاری داده‌ها ، نودهای دارای اشتباه باید قبل از ورود به خوشه مجدداً همگام سازی شود.این کار می تواند به صورت دستی یا با پاک کردن فهرست داده ها انجام شود.
اما در روش master-master MySQL replication حفاظت از سازگاری داده ها  اعمال نمی‌شود و به هر نود اجازه داده می‌شود با سرعت خود کار کند که این شیوه باعث می‌شود داده های master با slave ها متفاوت باشد.

حل مشکل تفاوت در داده ها

در MySQL هر نود با رسیدن به یک تداخل در داده شروع به جستجوی داده جدیدتر می‌نماید و عملیات های خود را لغو می‌کند تا این مشکل را حل نماید. اما در Galera Cluster  به علت هماهنگ بودن خوشه ها این عمل سریعتر و بهتر انجام می‌پذیرد.

 

Node Consensus

 

Galera از سیستم ارتباطات گروهی (GCS) برای بررسی اجماع نودها و در دسترس بودن بین اعضای خوشه استفاده می کند. اگر نودی ناسالم باشد ، پس از مقدار gmcast.peer_timeout ، به طور خودکار از خوشه خارج می شود ، به طور پیش فرض این مقدار تایم اوت به 3 ثانیه می رسد.

یک نود سالم Galera در حالت “Synced” به عنوان یک نود قابل اعتماد برای خواندن و نوشتن در نظر گرفته می شود ، در حالی که دیگر نودها چنین نیستند. در MySQL replication اینگونه نیست و MASTER با Slave ها ارتباطی ندارد و فقط slave با پردازش slave_IO_thread با master خود ارتباط دارد. اگر master از دسترس خارج گردد این عمل replication را کنسل می‌نماید. در این حالت slave باید مقادیر زیر را بررسی نماید:

  • Seconds_Behind_Master
  • Slave_IO_Running
  • Slave_SQL_Running
  • read_only variable
  • super_read_only variable (MySQL 5.7.8)

 

 

MySQL replication در اتصالات کند و یا اتصالات غیر مداوم بسیار خوب کار می کند. همچنین می تواند در سخت افزارها، محیط و سیستم عامل های مختلف مورد استفاده قرار گیرد. بیشتر موتورهای ذخیره سازی از آن پشتیبانی می کنند ، از جمله MyISAM ، Aria ، MEMORY و ARCHIVE.

نودهای Galera کاملاً بهم پیوسته اند. و از لحاظ سرعت با یکدیگر هماهنگ می‌گردند. Galera از مکانیزم کنترل جریان برای کنترل جریان تکرار در بین اعضا و از بین بردن هرگونه تاخیر و لگ استفاده می کند. البته توصیه می شود از مشخصات سخت افزاری یکسان برای همه نودهای Galera استفاده شود.