پایگاه داده (Database) قلب بسیاری از سامانههای نرمافزاری امروزی است. از فروشگاههای اینترنتی و سامانههای بانکی گرفته تا نرمافزارهای ERP، CRM و سرویسهای SaaS، تقریباً تمام اطلاعات حیاتی سازمان در دیتابیس نگهداری میشود. به همین دلیل، از دسترس خارج شدن Database حتی برای چند دقیقه میتواند باعث از دست رفتن درآمد، نارضایتی کاربران و در برخی موارد از بین رفتن اطلاعات شود.
در بسیاری از پروژهها، توسعه با یک سرور MySQL یا MariaDB آغاز میشود. این معماری برای شروع مناسب است، اما با افزایش تعداد کاربران و اهمیت سرویس، یک مشکل اساسی خود را نشان میدهد: تمام بار کاری و تمام دادهها روی یک سرور قرار دارند. در چنین شرایطی، خرابی سختافزار، مشکلات سیستمعامل، خطاهای نرمافزاری یا حتی عملیات نگهداری ساده میتواند کل سرویس را متوقف کند.
راهکارهای مختلفی برای افزایش دسترسپذیری (High Availability) دیتابیس وجود دارد؛ از Replication سنتی MySQL گرفته تا Group Replication، PostgreSQL Cluster و فناوریهای توزیعشده دیگر. اما یکی از شناختهشدهترین و بالغترین راهکارها برای MySQL و MariaDB، Galera Cluster است.
Galera این امکان را فراهم میکند که چندین سرور دیتابیس بهصورت همزمان یک کلاستر واحد را تشکیل دهند و همه آنها نسخهای یکسان از دادهها را نگهداری کنند. در نتیجه، اگر یکی از سرورها از دسترس خارج شود، سایر Nodeها بدون نیاز به مداخله دستی به ارائه سرویس ادامه میدهند. این ویژگی Galera را به گزینهای محبوب برای سازمانهایی تبدیل کرده است که به دنبال کاهش Downtime و افزایش پایداری زیرساخت هستند.
البته Galera تنها یک ابزار برای Replication نیست. این فناوری معماری متفاوتی نسبت به MySQL Replication سنتی دارد و مفاهیمی مانند Multi-Master Replication، Synchronous Replication، Quorum، Flow Control و Write Set Certification را وارد دنیای MySQL میکند. شناخت این مفاهیم برای طراحی یک زیرساخت پایدار ضروری است.
نکته
یکی از اشتباهات رایج این است که Galera را صرفاً یک افزونه برای Replication بدانیم. در واقع Galera یک راهکار کامل برای ایجاد کلاسترهای High Availability در MySQL و MariaDB است که مدل همگامسازی دادهها و مدیریت نودها را بهطور اساسی تغییر میدهد.
در این مقاله چه چیزهایی یاد میگیرید؟
در این راهنمای جامع، علاوه بر معرفی Galera Cluster، معماری داخلی، نحوه همگامسازی دادهها، مزایا و معایب، سناریوهای مناسب استفاده، روشهای مانیتورینگ، بکاپ، بهترین شیوههای پیادهسازی و اشتباهات رایج را نیز بررسی خواهیم کرد. همچنین Galera را با MySQL Replication، MySQL Group Replication و سایر راهکارهای High Availability مقایسه میکنیم تا بتوانید بر اساس نیاز واقعی پروژه خود تصمیمگیری کنید.
| در این مقاله خواهید آموخت | توضیح |
|---|---|
| Galera Cluster چیست؟ | معرفی معماری و نحوه عملکرد |
| تفاوت Galera و MySQL | مقایسه معماری و قابلیتها |
| مزایا و محدودیتها | بررسی فنی و عملیاتی |
| معماری داخلی | Quorum، SST، IST، wsrep و Flow Control |
| سناریوهای مناسب استفاده | چه زمانی Galera بهترین انتخاب است؟ |
| مانیتورینگ و بکاپ | بهترین ابزارها و روشها |
| Best Practices | توصیههای عملی برای محیط Production |
چرا MySQL بهتنهایی برای زیرساختهای Enterprise کافی نیست؟
MySQL یکی از محبوبترین سیستمهای مدیریت پایگاه داده (DBMS) در جهان است و میلیونها وبسایت، اپلیکیشن و سرویس آنلاین از آن استفاده میکنند. سادگی راهاندازی، عملکرد مناسب، جامعه کاربری بزرگ و متنباز بودن باعث شده MySQL به انتخاب اول بسیاری از توسعهدهندگان تبدیل شود.
اما زمانی که یک پروژه رشد میکند، تعداد کاربران افزایش مییابد و توقف سرویس حتی برای چند دقیقه قابل قبول نیست، معماری تکسروری (Single Node) دیگر پاسخگوی نیازهای سازمان نخواهد بود.
فرض کنید یک فروشگاه اینترنتی روزانه هزاران سفارش ثبت میکند یا یک سامانه بانکی بهصورت ۲۴ ساعته در حال پردازش تراکنشها است. اگر تنها سرور MySQL به هر دلیلی از دسترس خارج شود، کل سرویس متوقف خواهد شد؛ حتی اگر سرورهای وب و اپلیکیشن کاملاً سالم باشند.
این همان چیزی است که در معماری زیرساخت به آن Single Point of Failure (SPOF) گفته میشود؛ یعنی وجود یک نقطه که خرابی آن باعث از کار افتادن کل سامانه میشود.
Single Point of Failure چیست؟
هر بخشی از زیرساخت که خرابی آن بتواند کل سرویس را متوقف کند، یک Single Point of Failure محسوب میشود. در بسیاری از پروژهها، پایگاه داده مهمترین SPOF زیرساخت است.
محدودیتهای MySQL در معماری تکسروری
اگرچه MySQL از نظر عملکرد بسیار قدرتمند است، اما در حالت پیشفرض برای اجرا روی یک سرور طراحی شده است. این موضوع محدودیتهایی ایجاد میکند که با رشد کسبوکار بیشتر نمایان میشوند.
| محدودیت | توضیح | تأثیر بر کسبوکار |
|---|---|---|
| Single Point of Failure | تمام دادهها روی یک سرور قرار دارند. | Downtime کامل سرویس |
| عدم تحمل خرابی | خرابی سختافزار یا سیستمعامل باعث توقف دیتابیس میشود. | از دسترس خارج شدن سرویس |
| نیاز به Downtime برای برخی عملیات | برخی بهروزرسانیها یا تعمیرات نیازمند توقف سرویس هستند. | اختلال در سرویسدهی |
| مقیاسپذیری محدود | تمام بار نوشتن روی یک سرور انجام میشود. | کاهش Performance در بار بالا |
| ریسک بیشتر هنگام بکاپ | عملیات Backup ممکن است روی عملکرد سیستم تأثیر بگذارد. | افزایش Latency |
آیا MySQL Replication این مشکل را حل میکند؟
اولین راهکاری که معمولاً برای افزایش دسترسپذیری پیشنهاد میشود، استفاده از MySQL Replication است. در این معماری، یک سرور Primary (یا Master) تمام عملیات نوشتن را انجام میدهد و تغییرات به یک یا چند Replica منتقل میشوند.
این روش میتواند برای افزایش ظرفیت خواندن (Read Scaling) بسیار مفید باشد، اما تمام مشکلات را برطرف نمیکند.
| قابلیت | MySQL Replication |
|---|---|
| Read Scaling | ✅ |
| Write روی چند Node | ❌ |
| Failover خودکار | محدود |
| Replication کاملاً همزمان | ❌ |
| احتمال از دست رفتن آخرین تراکنشها | وجود دارد |
در بسیاری از پیادهسازیهای سنتی، Replication بهصورت Asynchronous انجام میشود؛ یعنی ممکن است بین ثبت اطلاعات روی Primary و رسیدن همان اطلاعات به Replica چند ثانیه یا حتی بیشتر فاصله وجود داشته باشد. اگر در این فاصله Primary از دسترس خارج شود، احتمال از دست رفتن آخرین تراکنشها وجود دارد.
سازمانها به چه چیزی نیاز دارند؟
در پروژههای Enterprise معمولاً تنها داشتن یک نسخه کپی از دادهها کافی نیست. سازمانها انتظار دارند زیرساخت دیتابیس ویژگیهای زیر را فراهم کند:
| نیاز | اهمیت |
|---|---|
| High Availability | عدم توقف سرویس در صورت خرابی یک Node |
| Automatic Failover | ادامه سرویس بدون دخالت اپراتور |
| حداقل احتمال از دست رفتن داده | حفظ تراکنشهای ثبتشده |
| امکان توسعه افقی | افزودن Nodeهای جدید |
| نگهداری بدون Downtime | بهروزرسانی و تعمیرات با کمترین اختلال |
| پایداری در محیط Production | اجرای سرویسهای حیاتی سازمان |
رسیدن به این اهداف با یک MySQL تکسروری یا حتی Replication سنتی همیشه ساده نیست. به همین دلیل راهکارهایی مانند Galera Cluster توسعه یافتهاند تا بتوانند High Availability واقعی را برای MySQL و MariaDB فراهم کنند.
Galera چگونه این مشکلات را برطرف میکند؟
برخلاف MySQL Replication که معمولاً یک سرور Primary دارد، Galera تمام Nodeهای کلاستر را به اعضای فعال تبدیل میکند. هر Node میتواند درخواستهای خواندن را پاسخ دهد و دادهها بهصورت همزمان میان اعضای کلاستر همگام میشوند.
علاوه بر این، Galera مکانیزمهایی مانند Write Set Certification، Quorum و Flow Control را برای جلوگیری از ناسازگاری دادهها و حفظ یکپارچگی کلاستر به کار میگیرد؛ مفاهیمی که در ادامه مقاله بهصورت کامل آنها را بررسی خواهیم کرد.
آنچه در ادامه خواهید دید
اکنون که با محدودیتهای MySQL و نیازهای زیرساختهای Enterprise آشنا شدیم، در بخش بعدی معماری Galera Cluster را بررسی میکنیم تا ببینیم این فناوری چگونه بدون استفاده از معماری سنتی Master/Replica، امکان ایجاد یک کلاستر پایدار و High Availability را فراهم میکند.
Galera Cluster چیست؟
Galera Cluster یک راهکار High Availability و Multi-Master Replication برای پایگاههای داده MySQL و MariaDB است که امکان اجرای چندین سرور دیتابیس بهصورت یک کلاستر واحد را فراهم میکند.
برخلاف معماری سنتی MySQL Replication که تنها یک سرور مسئول نوشتن اطلاعات (Primary یا Master) است، در Galera تمام Nodeهای کلاستر نسخهای یکسان از دادهها را نگهداری میکنند و هر Node میتواند بهصورت همزمان به درخواستهای خواندن پاسخ دهد. همچنین در بسیاری از سناریوها امکان انجام عملیات نوشتن (Write) روی هر Node نیز وجود دارد.
در نتیجه اگر یکی از Nodeها به هر دلیل از دسترس خارج شود، سایر اعضای کلاستر بدون نیاز به بازیابی دستی یا انجام Failover پیچیده، به سرویسدهی ادامه میدهند. این ویژگی باعث شده Galera یکی از محبوبترین گزینهها برای پیادهسازی دیتابیسهای High Availability در سازمانها باشد.
یک مثال واقعی
فرض کنید یک فروشگاه اینترنتی سه سرور دیتابیس دارد. در معماری سنتی MySQL Replication، تنها یکی از این سرورها عملیات نوشتن را انجام میدهد و دو سرور دیگر صرفاً Replica هستند.
حال اگر سرور اصلی دچار خرابی شود، معمولاً لازم است فرآیند Failover انجام شود، Replica جدید به Primary تبدیل گردد و سرویس دوباره تنظیم شود. بسته به معماری، این فرآیند ممکن است از چند ثانیه تا چند دقیقه زمان ببرد.
اما در Galera Cluster هر سه سرور عضو یک کلاستر واحد هستند و همواره دادههای یکسانی در اختیار دارند. در صورت خرابی یکی از Nodeها، سایر اعضا بدون تغییر معماری و با حداقل اختلال به کار خود ادامه میدهند.
چرا این موضوع اهمیت دارد؟
برای سامانههایی مانند فروشگاههای اینترنتی، ERP، CRM، سامانههای مالی و سرویسهای SaaS، حتی چند دقیقه Downtime میتواند هزینه قابل توجهی ایجاد کند. Galera دقیقاً برای کاهش این نوع ریسکها طراحی شده است.
معماری Galera Cluster
هر Galera Cluster از چند Node تشکیل میشود که هر کدام یک نمونه کامل از MySQL یا MariaDB را اجرا میکنند. این Nodeها از طریق شبکه با یکدیگر در ارتباط هستند و تمام تغییرات داده را میان خود همگام میکنند.
در ظاهر هر Node یک دیتابیس مستقل به نظر میرسد، اما از دید برنامههای کاربردی، همه آنها اعضای یک کلاستر واحد هستند.
| جزء | وظیفه |
|---|---|
| Node | اجرای MySQL یا MariaDB و نگهداری دادهها |
| Galera Provider | مدیریت Replication و هماهنگی اعضای کلاستر |
| wsrep API | ارتباط بین موتور دیتابیس و Galera |
| Network | انتقال Write Set میان Nodeها |
| Client | ارسال درخواستهای Read و Write |
چرا به Galera، Multi-Master گفته میشود؟
در معماریهای سنتی معمولاً تنها یک سرور اجازه ثبت اطلاعات جدید را دارد و سایر سرورها صرفاً دریافتکننده تغییرات هستند.
اما Galera از معماری Multi-Master استفاده میکند؛ یعنی همه اعضای کلاستر از نظر معماری قابلیت پذیرش عملیات نوشتن را دارند. البته این موضوع به معنای آن نیست که همیشه باید درخواستهای Write میان تمام Nodeها توزیع شوند.
در بسیاری از زیرساختهای Production، عملیات نوشتن همچنان از طریق یک Load Balancer یا Proxy به یک Node هدایت میشود و سایر Nodeها بیشتر برای افزایش دسترسپذیری و پاسخگویی به درخواستهای خواندن استفاده میشوند. این طراحی احتمال بروز Conflict را کاهش داده و مدیریت کلاستر را سادهتر میکند.
Best Practice
اگرچه Galera از Multi-Master پشتیبانی میکند، اما در بسیاری از پروژههای Enterprise توصیه میشود مسیر Write کنترلشده باشد و عملیات نوشتن از طریق ProxySQL، HAProxy یا راهکارهای مشابه مدیریت شود.
Replication در Galera چگونه انجام میشود؟
یکی از مهمترین تفاوتهای Galera با MySQL Replication، نحوه همگامسازی دادهها است.
در Replication سنتی، تغییرات ابتدا روی Primary ثبت شده و سپس به Replicaها ارسال میشوند. اما در Galera، قبل از نهایی شدن یک تراکنش، تغییرات به سایر Nodeها نیز ارسال و اعتبارسنجی میشوند.
به همین دلیل معمولاً Galera را یک سیستم Virtually Synchronous Replication مینامند. این مدل باعث میشود احتمال ناسازگاری دادهها به میزان قابل توجهی کاهش پیدا کند و تمام Nodeها وضعیت بسیار نزدیک به یکدیگر داشته باشند.
| ویژگی | MySQL Replication | Galera Cluster |
|---|---|---|
| معماری | Primary / Replica | Multi-Master |
| همگامسازی | Asynchronous (در اغلب پیادهسازیها) | Virtually Synchronous |
| احتمال اختلاف داده | بیشتر | بسیار کم |
| نیاز به Failover | بله | بسیار کمتر |
| پیچیدگی مدیریت | متوسط | بالاتر |
Galera از چه موتورهای دیتابیسی پشتیبانی میکند؟
Galera بهصورت مستقیم یک سیستم مدیریت پایگاه داده نیست، بلکه به MySQL و MariaDB قابلیت تشکیل کلاستر را اضافه میکند. امروزه رایجترین پیادهسازیهای Galera عبارتاند از:
| محصول | پشتیبانی از Galera | کاربرد رایج |
|---|---|---|
| MariaDB Server | ✅ داخلی | رایجترین انتخاب |
| Percona XtraDB Cluster | ✅ | محیطهای Enterprise |
| MySQL + Galera Provider | محدودتر | سناریوهای خاص |
جمعبندی این بخش
Galera Cluster تنها یک مکانیزم Replication نیست؛ بلکه یک معماری کامل برای ایجاد کلاسترهای پایدار MySQL و MariaDB است. این فناوری با استفاده از مدل Multi-Master، همگامسازی نزدیک به همزمان و مکانیزمهای داخلی برای حفظ یکپارچگی دادهها، امکان ارائه سرویس با دسترسپذیری بالا را برای سازمانها فراهم میکند.
Galera چگونه دادهها را همگامسازی میکند؟
یکی از مهمترین تفاوتهای Galera Cluster با روشهای سنتی Replication، نحوه مدیریت تراکنشها است. در معماریهای معمول، ابتدا اطلاعات روی سرور اصلی ثبت شده و سپس به سایر سرورها ارسال میشوند. اما Galera مسیر متفاوتی را انتخاب کرده است.
در Galera، هر تراکنش قبل از نهایی شدن، توسط سایر اعضای کلاستر اعتبارسنجی میشود. تنها زمانی که همه اعضای موردنیاز کلاستر آن تراکنش را معتبر بدانند، عملیات Commit انجام خواهد شد.
به همین دلیل، تمام Nodeهای کلاستر تقریباً همیشه نسخهای یکسان از دادهها را نگهداری میکنند و احتمال اختلاف اطلاعات میان آنها بسیار کمتر از معماریهای Asynchronous Replication است.
Virtually Synchronous Replication
اگرچه Galera معمولاً بهعنوان یک سیستم Synchronous Replication شناخته میشود، اما از نظر فنی مدل آن Virtually Synchronous Replication است. یعنی تراکنشها پیش از Commit در کل کلاستر اعتبارسنجی میشوند، اما همه عملیات بهصورت قفلشده و کاملاً همزمان اجرا نمیشوند. این رویکرد تعادل مناسبی میان Performance و یکپارچگی دادهها ایجاد میکند.
Write Set چیست؟
وقتی یک Query مانند INSERT، UPDATE یا DELETE در یکی از Nodeهای Galera
اجرا میشود، کل دیتابیس برای سایر اعضا ارسال نمیشود. در عوض، Galera مجموعه تغییرات ایجادشده توسط آن تراکنش را
استخراج میکند که به آن Write Set گفته میشود.
Write Set شامل اطلاعات موردنیاز برای بازسازی همان تغییر روی سایر Nodeها است. این روش باعث میشود تنها دادههای ضروری در شبکه منتقل شوند و حجم تبادل اطلاعات به حداقل برسد.
| مرحله | آنچه رخ میدهد |
|---|---|
| اجرای Query | تغییرات روی Node محلی ایجاد میشود. |
| تولید Write Set | تغییرات تراکنش استخراج میشود. |
| ارسال به سایر Nodeها | Write Set برای اعضای کلاستر ارسال میشود. |
| اعتبارسنجی | تمام Nodeها بررسی میکنند که تراکنش قابل اعمال باشد. |
| Commit | در صورت تأیید، تراکنش روی همه Nodeها اعمال میشود. |
Certification-Based Replication چیست؟
یکی از ویژگیهای منحصربهفرد Galera استفاده از مکانیزمی به نام Certification-Based Replication است.
در این مدل، بهجای قفل کردن رکوردها در تمام Nodeها، Galera ابتدا اجازه میدهد هر Node تراکنش را بهصورت محلی پردازش کند. سپس قبل از Commit بررسی میکند که آیا این تراکنش با تراکنشهای دیگری که همزمان در حال اجرا هستند تداخل دارد یا خیر.
اگر هیچ تعارضی وجود نداشته باشد، تراکنش تأیید و روی تمام اعضای کلاستر ثبت میشود. اما اگر دو تراکنش همزمان قصد تغییر یک داده مشترک را داشته باشند، یکی از آنها رد شده و باید مجدداً اجرا شود.
مزیت این روش
Certification-Based Replication بدون استفاده از قفلهای سراسری (Global Lock) امکان حفظ یکپارچگی دادهها را فراهم میکند و در بسیاری از سناریوها Performance بهتری نسبت به روشهای مبتنی بر Locking ارائه میدهد.
wsrep چیست؟
احتمالاً هنگام کار با Galera بارها پارامترهایی مانند wsrep_cluster_size، wsrep_ready
یا wsrep_local_state را مشاهده خواهید کرد.
عبارت wsrep مخفف Write Set Replication API است؛ لایهای که ارتباط میان موتور پایگاه داده و Galera Provider را برقرار میکند.
تمام فرآیندهای مربوط به ارسال Write Set، مدیریت اعضای کلاستر، بررسی وضعیت Nodeها و همگامسازی دادهها از طریق wsrep انجام میشود.
| پارامتر wsrep | کاربرد |
|---|---|
| wsrep_cluster_size | تعداد اعضای فعال کلاستر |
| wsrep_ready | آمادگی Node برای پاسخگویی |
| wsrep_connected | وضعیت اتصال به کلاستر |
| wsrep_cluster_status | وضعیت Primary Component |
| wsrep_local_state_comment | وضعیت فعلی Node |
چرا Galera به Primary و Replica نیاز ندارد؟
در MySQL Replication سنتی، یک سرور مسئول ثبت اطلاعات است و سایر Nodeها صرفاً تغییرات را دریافت میکنند. بنابراین تمام عملیات نوشتن به یک نقطه وابسته است.
اما Galera چنین وابستگیای ندارد. هر Node میتواند تراکنش را آغاز کند، Write Set تولید کند و آن را برای اعتبارسنجی به سایر اعضا ارسال کند. همین ویژگی باعث شده معماری Galera بهعنوان Multi-Master شناخته شود.
البته همانطور که در بخش قبل اشاره شد، در بسیاری از محیطهای Production مسیر Write از طریق Proxy مدیریت میشود تا احتمال بروز Conflict کاهش یابد و کنترل بیشتری روی بار کاری وجود داشته باشد.
آیا این معماری همیشه سریعتر است؟
خیر. یکی از برداشتهای اشتباه این است که Galera همیشه عملکرد بهتری نسبت به MySQL معمولی دارد.
از آنجا که هر تراکنش باید میان اعضای کلاستر اعتبارسنجی شود، عملیات نوشتن نسبت به یک MySQL تکسروری معمولاً تأخیر بیشتری خواهد داشت. در مقابل، سازمان به قابلیتهایی مانند High Availability، تحمل خرابی و کاهش احتمال از دست رفتن دادهها دست پیدا میکند.
| نوع عملیات | MySQL تکسروری | Galera Cluster |
|---|---|---|
| Read | بسیار سریع | بسیار سریع |
| Write | کمترین Latency | کمی بیشتر به دلیل اعتبارسنجی |
| دسترسپذیری | پایینتر | بسیار بالا |
| تحمل خرابی | محدود | بالا |
| احتمال ناسازگاری داده | بیشتر | بسیار کمتر |
جمعبندی این بخش
قدرت اصلی Galera در سرعت بیشتر نیست؛ بلکه در ایجاد تعادل میان پایداری، یکپارچگی دادهها و دسترسپذیری بالا است. مفاهیمی مانند Write Set، Certification-Based Replication و wsrep باعث میشوند چندین سرور بتوانند بدون وابستگی به یک Master واحد، تقریباً همیشه دادههای یکسانی را نگهداری کنند.
اجزای اصلی Galera Cluster را بشناسید
اگر Galera Cluster را مانند یک ارکستر در نظر بگیریم، هر بخش از این معماری وظیفه مشخصی بر عهده دارد. برخی اجزا مسئول نگهداری دادهها هستند، برخی ارتباط میان Nodeها را مدیریت میکنند و برخی دیگر از یکپارچگی اطلاعات اطمینان حاصل میکنند.
درک این اجزا باعث میشود هنگام پیادهسازی، مانیتورینگ یا عیبیابی Galera بتوانید رفتار کلاستر را بهتر تحلیل کنید و تصمیمهای دقیقتری بگیرید.
| جزء | وظیفه | اهمیت |
|---|---|---|
| Node | اجرای MySQL یا MariaDB | ★★★★★ |
| Galera Provider | مدیریت Replication | ★★★★★ |
| wsrep API | ارتباط بین دیتابیس و Provider | ★★★★★ |
| gcache | ذخیره موقت Write Setها | ★★★★☆ |
| Primary Component | اعضای معتبر کلاستر | ★★★★★ |
| Quorum | جلوگیری از Split Brain | ★★★★★ |
| Flow Control | کنترل سرعت Replication | ★★★★☆ |
| SST / IST | همگامسازی Nodeهای جدید | ★★★★★ |
Node چیست؟
هر Node در Galera یک نمونه کامل از MySQL یا MariaDB است که علاوه بر اجرای موتور پایگاه داده، قابلیت عضویت در کلاستر را نیز دارد.
هر Node دادههای کامل را نگهداری میکند؛ بنابراین برخلاف بسیاری از سیستمهای توزیعشده، اطلاعات بین Nodeها تقسیم (Sharding) نمیشود. هر عضو کلاستر نسخهای کامل و همگام از پایگاه داده را در اختیار دارد.
نکته
به همین دلیل ظرفیت ذخیرهسازی موردنیاز هر Node تقریباً برابر با حجم کل دیتابیس است. اگر پایگاه داده شما ۳ ترابایت باشد، هر Node نیز تقریباً به همین میزان فضای ذخیرهسازی نیاز خواهد داشت.
Galera Provider چیست؟
Galera Provider را میتوان مغز متفکر کلاستر دانست. این مؤلفه مسئول برقراری ارتباط میان اعضای کلاستر، ارسال Write Setها، مدیریت عضویت Nodeها، کنترل Replication و هماهنگی عملیات Commit است.
موتور MySQL مستقیماً با سایر Nodeها ارتباط برقرار نمیکند؛ بلکه تمام این ارتباطات از طریق Galera Provider انجام میشود.
| وظیفه Galera Provider | توضیح |
|---|---|
| Membership Management | مدیریت اعضای کلاستر |
| Replication | ارسال Write Set |
| Certification | اعتبارسنجی تراکنشها |
| Flow Control | کنترل سرعت همگامسازی |
| Failure Detection | تشخیص خرابی Nodeها |
gcache چیست؟
یکی از قابلیتهای بسیار مهم Galera، استفاده از gcache یا Galera Cache است.
gcache فضایی روی دیسک است که آخرین Write Setهای کلاستر را نگهداری میکند. زمانی که یک Node برای مدت کوتاهی از کلاستر خارج میشود، در بسیاری از موارد نیازی به دریافت دوباره کل دیتابیس نخواهد داشت.
اگر اطلاعات موردنیاز هنوز داخل gcache سایر Nodeها موجود باشد، تنها تغییرات از دسترفته دریافت میشوند. این فرآیند که Incremental State Transfer (IST) نام دارد، بسیار سریعتر از انتقال کامل دیتابیس است.
Best Practice
یکی از رایجترین اشتباهات در پیادهسازی Galera، کوچک در نظر گرفتن اندازه gcache است. اگر gcache ظرفیت کافی نداشته باشد، Nodeها مجبور خواهند شد بهجای IST از SST استفاده کنند که زمان بسیار بیشتری نیاز دارد.
Primary Component چیست؟
Galera همیشه بررسی میکند که کدام Nodeها اعضای معتبر کلاستر هستند. مجموعه این اعضا Primary Component نام دارد.
تنها Nodeهایی که داخل Primary Component قرار دارند اجازه پردازش تراکنشهای جدید را خواهند داشت. اگر ارتباط یک Node با اکثریت اعضای کلاستر قطع شود، آن Node برای جلوگیری از ناسازگاری دادهها عملیات نوشتن را متوقف میکند.
این رفتار یکی از مهمترین تفاوتهای Galera با بسیاری از سیستمهای Replication سنتی است و نقش مهمی در جلوگیری از ایجاد دادههای متناقض دارد.
Quorum چیست؟
فرض کنید یک کلاستر سهنودی دارید و ارتباط شبکه دچار اختلال میشود. اگر هر Node تصور کند تنها عضو فعال کلاستر است و به پذیرش درخواستهای جدید ادامه دهد، پس از برقراری ارتباط مجدد، دادههای ناسازگار ایجاد خواهند شد. به این وضعیت Split Brain گفته میشود.
برای جلوگیری از این مشکل، Galera از مفهومی به نام Quorum استفاده میکند.
Quorum به معنای داشتن اکثریت اعضای کلاستر است. تنها گروهی از Nodeها که اکثریت را در اختیار داشته باشند اجازه ادامه فعالیت خواهند داشت.
| تعداد Node | حداقل اعضای لازم برای Quorum |
|---|---|
| 1 | 1 |
| 2 | 2 |
| 3 | 2 |
| 5 | 3 |
| 7 | 4 |
هشدار
به همین دلیل استفاده از کلاستر دو نودی در محیط Production معمولاً توصیه نمیشود. در صورت قطع ارتباط میان دو Node، هیچیک قادر به تشکیل Quorum نخواهند بود و کلاستر عملاً از سرویس خارج میشود.
Flow Control چیست؟
تمام Nodeهای Galera باید تقریباً با یک سرعت یکسان حرکت کنند. اگر یکی از اعضای کلاستر به دلیل کند بودن دیسک، کمبود منابع یا مشکلات شبکه از سایر Nodeها عقب بماند، احتمال ایجاد صف طولانی از Write Setها وجود دارد.
برای جلوگیری از این وضعیت، Galera از مکانیزمی به نام Flow Control استفاده میکند.
در این حالت، اگر یکی از Nodeها نتواند تغییرات را با سرعت کافی پردازش کند، Galera بهصورت موقت سرعت ارسال تراکنشهای جدید را کاهش میدهد تا همه اعضای کلاستر دوباره همگام شوند.
نکته عملی
فعال شدن مکرر Flow Control معمولاً نشانه وجود یک مشکل در زیرساخت است؛ مانند Storage کند، Latency بالای شبکه، کمبود CPU یا تنظیمات نامناسب ماشین مجازی. به همین دلیل مانیتورینگ شاخصهای Flow Control یکی از مهمترین بخشهای Observability در کلاسترهای Galera محسوب میشود.
جمعبندی اجزای معماری Galera
برخلاف تصور بسیاری از افراد، Galera تنها یک افزونه برای Replication نیست. این فناوری از مجموعهای از مؤلفهها تشکیل شده که هر کدام وظیفه مشخصی در حفظ یکپارچگی دادهها، مدیریت اعضای کلاستر و افزایش دسترسپذیری بر عهده دارند.
درک مفاهیمی مانند gcache، Quorum، Flow Control و Primary Component برای طراحی یک کلاستر پایدار ضروری است و در ادامه مقاله نیز هنگام بررسی SST، IST و سناریوهای واقعی پیادهسازی بارها به آنها بازخواهیم گشت.
معماری استاندارد Galera Cluster در محیط Production
راهاندازی Galera Cluster تنها نصب چند بسته نرمافزاری و اضافه کردن چند Node به یکدیگر نیست. طراحی صحیح معماری کلاستر تأثیر مستقیمی بر پایداری، Performance، قابلیت توسعه و حتی امنیت اطلاعات دارد.
یکی از اشتباهات رایج این است که تصور شود هرچه تعداد Nodeها بیشتر باشد، کلاستر بهتر عمل میکند. در عمل، تعداد Nodeها، محل استقرار آنها، کیفیت شبکه، نوع Storage و نحوه توزیع درخواستها همگی در عملکرد نهایی Galera نقش دارند.
بهترین تعداد Node برای Galera Cluster
از نظر تئوری، Galera میتواند با دو یا چند Node راهاندازی شود، اما همه این سناریوها برای محیط Production مناسب نیستند.
| تعداد Node | وضعیت | توضیح |
|---|---|---|
| 1 Node | ❌ | فاقد High Availability |
| 2 Node | ⚠️ | ریسک از دست رفتن Quorum |
| 3 Node | ✅ بهترین انتخاب | تعادل مناسب میان هزینه و پایداری |
| 5 Node | ✅ | برای سازمانهای بزرگ |
| 7 Node یا بیشتر | ⚠️ | پیچیدگی و ترافیک Replication بیشتر |
در اکثر پروژههای Enterprise، معماری سهنودی بهترین تعادل را میان هزینه، تحمل خرابی و مدیریت کلاستر ایجاد میکند. با سه Node، حتی اگر یکی از سرورها از دسترس خارج شود، دو عضو باقیمانده همچنان Quorum را حفظ کرده و سرویس بدون وقفه ادامه پیدا میکند.
Best Practice
اگر محدودیت خاصی وجود ندارد، برای اولین پیادهسازی Galera از سه Node با سختافزار مشابه و شبکه پایدار استفاده کنید. این معماری سادهترین و قابلاعتمادترین گزینه برای اکثر سازمانها است.
چرا کلاستر دو نودی پیشنهاد نمیشود؟
یکی از رایجترین سؤالات این است که آیا میتوان Galera را فقط روی دو سرور اجرا کرد؟
پاسخ کوتاه این است: بله، اما معمولاً توصیه نمیشود.
فرض کنید دو Node دارید و ارتباط شبکه بین آنها قطع میشود. هر Node تصور میکند شاید Node دیگر از کار افتاده باشد. از آنجا که هیچکدام اکثریت (Quorum) را در اختیار ندارند، برای جلوگیری از Split Brain عملیات نوشتن متوقف خواهد شد.
هشدار
بسیاری از Downtimeهای Galera ناشی از خرابی سرورها نیستند؛ بلکه به دلیل از دست رفتن Quorum در کلاسترهای دو نودی رخ میدهند.
Garbd (Galera Arbitrator) چیست؟
اگر به هر دلیل مجبور به استفاده از دو Node هستید، میتوانید از Galera Arbitrator یا Garbd استفاده کنید.
Garbd یک عضو سبک (Lightweight) از کلاستر است که هیچ دادهای ذخیره نمیکند و عملیات Read یا Write انجام نمیدهد، اما در رأیگیری Quorum شرکت میکند.
به این ترتیب، حتی اگر یکی از دو Node اصلی از دسترس خارج شود، Node باقیمانده به همراه Garbd همچنان اکثریت آرا را خواهد داشت و کلاستر به فعالیت خود ادامه میدهد.
| ویژگی | Node معمولی | Garbd |
|---|---|---|
| نگهداری داده | ✅ | ❌ |
| پذیرش Query | ✅ | ❌ |
| شرکت در Quorum | ✅ | ✅ |
| مصرف منابع | زیاد | بسیار کم |
نکته
Garbd جایگزین یک Node واقعی نیست. اگر امکان اضافه کردن Node سوم وجود دارد، تقریباً همیشه استفاده از یک Node کامل انتخاب بهتری خواهد بود.
آیا میتوان Galera را بین دو دیتاسنتر اجرا کرد؟
از نظر فنی بله، اما باید با دقت بسیار زیاد طراحی شود.
از آنجا که Galera پیش از Commit تراکنشها نیاز به تبادل پیام میان Nodeها دارد، تأخیر (Latency) شبکه مستقیماً روی سرعت عملیات نوشتن تأثیر میگذارد.
| Latency شبکه | وضعیت پیشنهادی |
|---|---|
| کمتر از ۱ میلیثانیه | ⭐⭐⭐⭐⭐ ایدهآل |
| ۱ تا ۵ میلیثانیه | ⭐⭐⭐⭐ مناسب |
| ۵ تا ۱۰ میلیثانیه | ⭐⭐ قابل قبول با بررسی |
| بیش از ۱۰ میلیثانیه | ⚠️ احتمال کاهش محسوس Performance |
| WAN بین کشورها | ❌ معمولاً توصیه نمیشود |
اگر هدف شما ایجاد Disaster Recovery بین دو شهر یا دو کشور است، معمولاً بهتر است از معماریهای دیگری مانند Replication غیرهمزمان یا راهکارهای اختصاصی DR استفاده کنید تا از Galera.
Load Balancer در معماری Galera چه نقشی دارد؟
در بیشتر استقرارهای Production، کاربران مستقیماً به Nodeهای Galera متصل نمیشوند. بین برنامه و کلاستر معمولاً یک لایه Load Balancer قرار میگیرد که وظیفه توزیع هوشمند درخواستها را بر عهده دارد.
| ابزار | کاربرد | میزان محبوبیت |
|---|---|---|
| HAProxy | توزیع Read و Write | ⭐⭐⭐⭐⭐ |
| ProxySQL | Routing هوشمند Queryها | ⭐⭐⭐⭐⭐ |
| MariaDB MaxScale | ویژه MariaDB | ⭐⭐⭐⭐ |
| Nginx Stream | TCP Load Balancing | ⭐⭐⭐ |
ابزارهایی مانند ProxySQL علاوه بر توزیع بار، قابلیتهایی مانند Health Check، تشخیص Nodeهای سالم، مدیریت Session و هدایت هوشمند درخواستهای Read و Write را نیز ارائه میدهند.
توصیه تیم Ultimate Cloud
برای اکثر پروژههای سازمانی، ترکیب Galera + ProxySQL + سه Node دیتابیس یکی از متعادلترین و قابلاعتمادترین معماریها محسوب میشود. این ساختار علاوه بر High Availability، مدیریت سادهتر، Failover سریعتر و انعطافپذیری بیشتری نسبت به اتصال مستقیم برنامه به Nodeهای دیتابیس فراهم میکند.
معماری پیشنهادی برای اکثر سازمانها
اگر قصد دارید برای یک سامانه ERP، CRM، فروشگاه اینترنتی یا سرویس SaaS یک کلاستر Galera طراحی کنید، معماری زیر در بسیاری از پروژهها نقطه شروع مناسبی خواهد بود:
| لایه | پیشنهاد |
|---|---|
| Load Balancer | ProxySQL یا HAProxy (بهصورت Redundant) |
| Database Cluster | ۳ Node Galera با سختافزار مشابه |
| Storage | NVMe SSD با Latency پایین |
| Network | شبکه اختصاصی 10GbE یا سریعتر |
| Monitoring | Prometheus + Grafana |
| Backup | Percona XtraBackup یا MariaBackup |
در بخش بعدی، فرآیندهای SST (State Snapshot Transfer) و IST (Incremental State Transfer) را بررسی میکنیم؛ دو مکانیزم کلیدی که مشخص میکنند یک Node جدید چگونه به کلاستر ملحق میشود یا پس از قطعی، مجدداً همگامسازی خواهد شد.