MySQL پرکاربردترین دیتابیس متنباز رابطهای جهان است و میلیونها وبسایت — از فروشگاههای کوچک تا بزرگترین پلتفرمهای جهان — دادههای خود را به آن میسپارند. اما وقتی کسبوکارتان به یک نسخهٔ MySQL وابسته میشود، خرابی همان یک سرور میتواند همهچیز را متوقف کند.
نسخهٔ ۸.۰ MySQL مجموعهای کامل از فناوریهای دسترسپذیری بالا ارائه میدهد: Group Replication، InnoDB Cluster و پشتیبانی از راهحلهای همگام مثل Galera. در این مقاله یاد میگیریم هر کدام چطور کار میکنند، چه تفاوتی با هم دارند و چطور کلاستر MySQL را بدون نقطهٔ شکست واحد طراحی کنیم.
چرا MySQL به HA نیاز دارد؟
یک نمونهٔ تکنود MySQL سه مشکل اساسی دارد:
- نقطهٔ شکست واحد — خرابی سرور، دیسک یا شبکه یعنی توقف کامل دیتابیس و همهٔ سرویسها
- توقف برای نگهداری — ارتقاء نسخه، پچ امنیتی و تغییر تنظیمات نیاز به توقف سرویس دارد
- بدون مقیاسپذیری خواندن — همهٔ کوئریهای سنگین به یک سرور میخوردند و با رشد ترافیک، سرور به گلوگاه تبدیل میشود
کلاستر HA این مشکلات را با نگهداشتن چند نسخهٔ هماهنگ از داده، فیلاوور خودکار و توزیع ترافیک خواندن بین نودها حل میکند.
Group Replication (ریپلیکیشن گروهی)
Group Replication پلاگین رسمی مایاسکیوال برای ریپلیکیشن در کلاستر است که از نسخهٔ ۵.۷ معرفی شد و در ۸.۰ به بلوغ کامل رسید. در این مدل، گروهی از سرورها دادهها را با یکدیگر همگام میکنند و به دو شکل کار میکنند:
- تکنویسنده (Single-Primary) — فقط یک نود نوشتن را میپذیرد و بقیه replica هستند؛ مدل پیشنهادی برای بیشتر کاربردها
- چندنویسنده (Multi-Primary) — همهٔ نودها میتوانند بنویسند؛ تراکنشهای متناقض توسط مکانیزم Certification حل میشوند
قلب Group Replication یک مکانیزم Certification است: هر تراکنش باید قبل از commit توسط اکثریت اعضای گروه تایید شود تا تضمین شود تراکنشهای همزمان دیگر با آن تداخل ندارند. به همین دلیل، کلاستر هرگز دو نسخهٔ متفاوت از یک دادهٔ یکسان ندارد.
InnoDB Cluster؛ بستهٔ کامل HA
InnoDB Cluster راهحل رسمی و توصیهشدهٔ مایاسکیوال برای HA است که سه جزء را کنار هم میگذارد:
- Group Replication — موتور همگامسازی و فیلاوور خودکار در سطح کلاستر
- MySQL Shell — ابزار ساخت و مدیریت کلاستر با دستورات سادهٔ
mysqlsh - MySQL Router — مسیریاب هوشمند ترافیک: نوشتنها را به primary و خواندنها را بین replicaها توزیع میکند
ساخت کلاستر در چند دستور انجام میشود:
mysqlsh --uri admin@db-1:3306
var cluster = dba.createCluster('lexoya-cluster')
cluster.addInstance('admin@db-2:3306')
cluster.addInstance('admin@db-3:3306')بعد از این، MySQL Router به صورت خودکار آگاه میشود کدام نود primary است و اگر از کار بیفتد، نود جایگزین بلافاصله نقش را میگیرد — اپلیکیشنها بدون تغییر، به کلاستر متصل میمانند.
Galera؛ همگامسازی کامل
Galera Cluster (که در Percona XtraDB Cluster و MariaDB هم استفاده میشود) راهحل محبوب دیگری است با تفاوت بنیادی: همگامسازی همزمان (Synchronous). یعنی هر تراکنش قبل از اینکه به کلاینت تایید شود، باید روی همهٔ نودها commit شده باشد.
ویژگیهای کلیدی Galera:
- چندنویسنده (Multi-Master) — همهٔ نودها همزمان میتوانند بنویسند و بخوانند
- صفر از دست رفتن داده — به دلیل همگام بودن، خرابی یک نود حتی یک تراکنش را از بین نمیبرد
- ورود نود جدید ساده — نود جدید با
SST(انتقال کامل) یاIST(انتقال افزایشی) وارد کلاستر میشود - اتصال مستقیم نودها به هم — بدون نیاز به Router میانی اجباری
فیلاوور اولیه/ثانویه (Primary/Secondary Failover)
در اصطلاح کلاسیک HA مایاسکیوال، Primary نودی است که نوشتن را میپذیرد و Secondary نودهایی هستند که نسخهٔ کپی نگه میدارند. وقتی primary از کار بیفتد، یک secondary ارتقاء مییابد:
- در Group Replication / InnoDB Cluster این انتخاب خودکار است — گروه با رأیگیری، یک primary جدید انتخاب میکند و Router ترافیک را به آن هدایت میکند
- در نصب سنتی Replica (بدون Group Replication) فیلاوور به ابزارهای خارجی مثل MHA یا اسکریپتهای Orchestration وابسته است — سادهتر نیست و خطای انسانی بیشتری دارد
نکتهٔ مهم: سرعت فیلاوور خودکار به دو عامل بستگی دارد — تشخیص خرابی (در InnoDB Cluster معمولاً چند ثانیه) و سرعت ارتقاء secondary. هر دو در Group Replication بهینه و استاندارد شدهاند.
مقیاسپذیری خواندن
در کلاستر ۳ نودی با حالت تکنویسنده، همهٔ نوشتنها به primary میروند و خواندن بین سه نود توزیع میشود. MySQL Router یا یک لود بالانسر مثل HAProxy این تقسیم بار را انجام میدهند؛ بنابراین با هر نود اضافه، ظرفیت خواندن کلاستر هم زیاد میشود.
فقط یک هشدار: دیتای روی secondaryها ممکن است چند میلیثانیه از primary عقب باشد (Replication Lag). کوئریهایی که به تازهترین داده نیاز دارند باید به primary هدایت شوند.
جلوگیری از Split-Brain
خطرناکترین سناریو در هر کلاستر، Split-Brain است: قطعی شبکه، کلاستر را به دو نیمه تقسیم میکند و هر دو نیمه فکر میکنند آنها primary هستند. نتیجهٔ آن، دادههای متناقضی است که شاید هرگز قابل جبران نباشد.
راهحل، مکانیزم اکثریت (Quorum) است: یک نود فقط وقتی میتواند نقش primary را بگیرد یا تراکنشی را تایید کند که اکثریت اعضا را در دسترس داشته باشد. اگر اکثریت نباشد، کلاستر نوشتن را متوقف میکند — به جای آنکه دو پادشاه بسازد. Galera همین کار را با قربانیکردن نود منزوی (Node Isolation) انجام میدهد.
نکتهٔ عملی: کلاستر دو نودی شکننده است و عملاً به یک نود سوم (Arbitrator/Witness) نیاز دارد؛ همیشه کلاستر با تعداد فرد نود (معمولاً ۳) راه بیندازید.
مقایسه: تکنمونه، InnoDB Cluster، Galera
سه مسیر اصلی را کنار هم میبینیم:
| ویژگی | MySQL تکنمونه | InnoDB Cluster (Group Replication) | Galera |
|---|---|---|---|
| توپولوژی | یک نود | تک یا چندنویسنده | چندنویسنده همگام |
| نوع همگامسازی | — | ناهمگام با Certification | همگام (Synchronous) |
| فیلاوور | دستی | خودکار | خودکار |
| نوشتن در چند نود | خیر | بله (در حالت multi-primary) | بله |
| مقیاسپذیری خواندن | ندارد | بله، با MySQL Router | بله، در همهٔ نودها |
| پیچیدگی راهاندازی | کم | متوسط (با mysqlsh ساده شده) | متوسط |
| مناسب برای | پروژهٔ کوچک و توسعه | استاندارد HA مدرن مایاسکیوال | نیاز به صفر از دست رفتن داده |
موارد استفاده (Use Cases)
- سامانههای تراکنشی با نیاز به uptime بالا — فروشگاه اینترنتی، سامانهٔ رزرو و پرداخت
- فینتک و پرداخت — جایی که حتی یک تراکنش نباید گم شود؛ Galera با همگامسازی کامل
- اپلیکیشنهای با ترافیک خواندن بالا — توزیع کوئریها بین replicaها با MySQL Router
- مهاجرت از تکنمونه به کلاستر — بدون تغییر کد اپلیکیشن، با InnoDB Cluster
- نگهداری بدون توقف — ارتقاء و پچ روی نودها به صورت چرخشی (Rolling)
چه زمانی کلاستر MySQL انتخاب مناسبی است؟
- هزینهٔ توقف دیتابیس برای کسبوکارتان واقعاً بالاست و به SLA نیاز دارید
- ترافیک خواندن به یک سرور نمیگنجد و به توزیع بار نیاز دارید
- میخواهید ارتقاء و نگهداری را بدون توقف انجام دهید
- به فیلاوور خودکار در چند ثانیه نیاز دارید، نه ساعتها درگیری شبانه
- تیم زیرساخت شما تجربهٔ کافی برای مدیریت کلاستر دارد (یا از سرویس مدیریتشده استفاده میکنید)
کلاستر MySQL برای چه چیزهایی مناسب نیست؟
- پروژههای کوچک و توسعه — سه نود برای یک اپلیکیشن کمترافیک فقط هزینه و پیچیدگی اضافه است؛ یک نمونهٔ خوب با بکاپ منظم کافی است
- بار نوشتن بسیار سنگین در همهٔ نودها — در حالت چندنویسنده، تراکنشهای متضاد هزینهٔ Certification دارند؛ برای چنین باری شاردینگ یا مدل تکنویسنده بهتر است
- کوچکترین تاخیر ممکن در نوشتن — همگامسازی (مخصوصاً Galera) تاخیر نوشتن را افزایش میدهد؛ اگر تاخیر نوشتن مهمتر از HA است، مدل ناهمگام را بسنجید
- تیم بدون تجربهٔ عملیات کلاستر — یک کلاستر بد مدیریتشده، پیچیدهتر از یک تکنمونهٔ سالم است
MySQL در لکسویا
طراحی کلاستر درست — انتخاب بین InnoDB Cluster و Galera، پیکربندی Router، مدیریت quorum و مانیتورینگ — تخصص و زمان میخواهد. لکسویا این کار را برای شما انجام میدهد.
لکسویا این دیتابیس را به عنوان سرویس دیتابیس ابری (DBaaS) ارائه میدهد — با چند کلیک نمونهٔ تکنمونهای یا کلاستر با دسترسپذیری بالا راه بیندازید.
نتیجهگیری
MySQL 8.0 با Group Replication، InnoDB Cluster و پشتیبانی از Galera، همهٔ ابزارهای لازم برای ساخت کلاستر با دسترسپذیری بالا را در اختیار شما میگذارد: فیلاوور خودکار، مقیاسپذیری خواندن و محافظت در برابر Split-Brain با مکانیزم اکثریت.
انتخاب نهایی به نیاز شما بستگی دارد: InnoDB Cluster استاندارد مدرن و سادهٔ مایاسکیوال برای اکثر تیمهاست و Galera برای کاربردهایی که همگامسازی کامل و نوشتن چندنودی لازم دارند. در هر دو حالت، داشتن سه نود، بکاپ منظم و کسی که کلاستر را ببیند — خودتان یا یک سرویس مدیریتشده — شرط موفقیت است.