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

577

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 نشان می‌دهد:

رویداد باینری در 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 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…

Node

auto_increment_increment

auto_increment_offset

Auto increment value

Node 1

1, 4, 7, 10, 13, 16…

Node 2

2, 5, 8, 11, 14, 17…

Node 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 استفاده شود.

آموزش