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-updatesauto_increment_increment=2auto_increment_offset=1log-slave-updatesauto_increment_increment=2auto_increment_offset=2| 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…
|
سازگاری داده ها در Galera replication و MySQL replication
در Galera Cluster همه نود ها باید با یک سرعت داده‌های خود را همانند سازی نمایند در غیر این صورت نود ها سرعت خود را کاهش می‌دهند تا نود کند تر نیز بتواند به سرعت آنها برسد. این عمل باعث جلوگیری از لگ زدن slave می‌گردد. هرچند که این اتفاق بازهم ممکن است روی دهد اما به اندازه MySQL replication نمی‌باشد.
از طرف دیگر ، Galera Cluster از عدم تطابق داده‌ها جلوگیری می‌کند، در نتیجه اگر نودی به هر دلیلی نتواند هرگونه عمل نوشتن را انجام دهد، از خوشه خارج می‌شود.
150305 16:13:14 [ERROR] WSREP: Failed to apply trx 1 4 times150305 16:13:14 [ERROR] WSREP: Node consistency compromized, aborting..حل مشکل تفاوت در داده ها
در 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 استفاده شود.
بدون دیدگاه