راهاندازی کلاستر Galera با MariaDB روی چند سرور مجازی و اختصاصی: دیتابیس Multi-Master بدون Downtime
وقتی یک سرویس روی یک دیتابیس تکنود اجرا میشود، هر ریاستارت یا کرش سرور یعنی قطعی برای کاربر. راهحل رایج، replication ساده master-slave است؛ اما در آن فقط یک نود نوشتن را قبول میکند و failover اغلب دستی یا با تاخیر اتفاق میافتد. کلاستر Galera این مشکل را از ریشه حل میکند: هر نود همزمان هم master است و هم slave، و نوشتن روی هر نودی که باشد، بلافاصله روی بقیه هم اعمال میشود.
این راهنما نصب و راهاندازی کلاستر Galera با MariaDB را روی سه سرور توضیح میدهد — میتوانند سه VPS، سه سرور اختصاصی، یا ترکیبی از این دو باشند. هدف رسیدن به دیتابیسی است که با از دست رفتن یک نود، سرویسدهی متوقف نشود.
کلاستر Galera چیست و چه فرقی با Replication معمولی دارد
Galera یک لایه synchronous multi-master replication برای MariaDB و MySQL است. برخلاف replication استاندارد که async است و ممکن است slave چند ثانیه عقبتر از master باشد، در Galera هر تراکنش قبل از commit روی همه نودهای کلاستر certify میشود. یعنی وقتی یک نوشتن روی نود ۱ تایید شد، همان لحظه روی نود ۲ و ۳ هم قابل خواندن و نوشتن است.
نتیجه عملی این معماری:
- هر نود میتواند همزمان درخواست خواندن و نوشتن بگیرد؛ نیازی به تعیین یک master ثابت نیست.
- از دست رفتن یک نود، کلاستر را متوقف نمیکند — تا وقتی اکثریت نودها (quorum) زنده باشند.
- نیازی به ابزار جداگانه برای failover مثل MHA یا Orchestrator نیست، چون همه نودها از قبل نوشتنپذیرند.
نکته مهم: Galera برای سه نود یا بیشتر طراحی شده. با دو نود، از دست رفتن یکی یعنی نصف کلاستر باقی میماند و quorum شکل نمیگیرد — کلاستر برای جلوگیری از split-brain خودش را read-only میکند. حداقل استاندارد سه نود است.
پیشنیازها روی سرورهای مجازی و اختصاصی
برای این راهنما سه سرور با آدرسهای فرضی زیر در نظر میگیریم:
- Node1: 10.0.0.11
- Node2: 10.0.0.12
- Node3: 10.0.0.13
سیستمعامل Ubuntu 22.04 یا Debian 12 با MariaDB 10.11 یا 11.x فرض شده (پکیجهای wsrep از نسخه 10.4 به بعد در ریپازیتوری رسمی MariaDB موجودند). اگر سرورها روی سرور مجازی آریانت هستند، هر سه نود باید در یک شبکه داخلی (Private Network) یا حداقل با لتنسی پایین به هم متصل باشند — Galera replication حساس به latency بین نودهاست و روی لینکهای کند، throughput نوشتن به شدت پایین میآید. روی سرور اختصاصی، پایداری این لینک را میتوان با Network Bonding چند NIC بیشتر هم کرد.
هر نود به حداقل ۲ عدد vCPU، ۴ گیگابایت RAM و دیسک SSD نیاز دارد؛ برای بار production واقعی این عدد را بالاتر ببرید. ذخیرهسازی هر سه نود مستقل است — Galera شبکه را replicate میکند، نه یک storage مشترک را.
باز کردن پورتهای لازم برای Galera
قبل از نصب، فایروال هر سه سرور باید این پورتها را بین خودشان (نه لزوماً به دنیای بیرون) باز کند:
| پورت | پروتوکل | کاربرد |
|---|---|---|
| 3306 | TCP | اتصال کلاینتهای MySQL/MariaDB |
| 4567 | TCP + UDP | ارتباط اصلی Galera بین نودها (Group Communication) |
| 4568 | TCP | انتقال State Snapshot Transfer (SST) به روش IST |
| 4444 | TCP | State Snapshot Transfer با ابزار rsync/mariabackup |
با ufw اینطور باز میشود (روی هر نود، برای IP دو نود دیگر):
sudo ufw allow from 10.0.0.11 to any port 3306,4567,4568,4444 proto tcp
sudo ufw allow from 10.0.0.11 to any port 4567 proto udp
همین دستور را با IP نودهای دیگر هم تکرار کنید. اگر سرورها روی شبکه داخلی آریانت هستند، محدود کردن این پورتها فقط به رنج IP داخلی، امنیت را بدون افت performance تامین میکند.
نصب MariaDB و پکیج wsrep
روی هر سه سرور، ابتدا ریپازیتوری رسمی MariaDB را اضافه و پکیجها را نصب کنید:
curl -LsS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash
sudo apt update
sudo apt install -y mariadb-server mariadb-backup
از نسخه 10.4 به بعد پکیج اصلی mariadb-server ماژول wsrep را همراه خودش دارد؛ نصب جدا کردن galera-4 معمولاً لازم نیست ولی بد نیست چک کنید که فایل /usr/lib/galera/libgalera_smm.so موجود باشد — همین فایل در تنظیمات wsrep_provider استفاده میشود. روی توزیعهای خانواده RHEL مراحل نصب پکیجها کمی فرق دارد؛ نصب MariaDB در CentOS 8 این تفاوتها را جداگانه توضیح داده.
بعد از نصب، سرویس را متوقف کنید — هنوز پیکربندی نشده و راهاندازی زودهنگام آن باعث خطای اتصال میشود:
sudo systemctl stop mariadb
پیکربندی فایل my.cnf برای هر نود
یک فایل جدید بسازید (مثلاً /etc/mysql/mariadb.conf.d/60-galera.cnf) و روی هر سه نود اعمال کنید — فقط wsrep_node_address و wsrep_node_name باید مخصوص هر سرور تنظیم شود:
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = "arianet_galera_cluster"
wsrep_cluster_address = "gcomm://10.0.0.11,10.0.0.12,10.0.0.13"
wsrep_node_address = "10.0.0.11"
wsrep_node_name = "node1"
binlog_format = ROW
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
wsrep_sst_method = mariabackup
wsrep_sst_auth = "sst_user:StrongPassw0rd"
نکاتی که اغلب فراموش میشوند:
binlog_format=ROWاجباری است — Galera با statement-based replication کار نمیکند.innodb_autoinc_lock_mode=2لازم است تا AUTO_INCREMENT بین نودها تداخل نکند.- کاربر
sst_userباید قبل از bootstrap روی حداقل یک نود ساخته شود، با دسترسی کافی برای backup. اگر رمز کاربر root MariaDB را هم همین موقع میخواهید تنظیم یا بازنشانی کنید، این راهنما مراحلش را پوشش میدهد.
Bootstrap کردن کلاستر
Bootstrap فقط یکبار، فقط روی اولین نود انجام میشود — این کار یک کلاستر جدید با یک عضو میسازد که بقیه نودها بعداً به آن میپیوندند:
sudo galera_new_cluster
بعد از اجرا، وضعیت کلاستر را چک کنید:
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
خروجی باید wsrep_cluster_size=1 باشد — یعنی کلاستر فعال است با یک عضو.
افزودن نود دوم و سوم
روی نود دوم و سوم، همان فایل پیکربندی را با IP و نام مخصوص خودشان اعمال کنید، سپس سرویس را بهصورت معمول (نه با galera_new_cluster) بالا بیاورید:
sudo systemctl start mariadb
نود جدید بهطور خودکار به wsrep_cluster_address وصل میشود، و بسته به حجم داده موجود، یکی از دو روش انتقال داده را اجرا میکند:
- IST (Incremental State Transfer): اگر نود قبلاً بخشی از کلاستر بوده و فقط چند تراکنش عقبتر است، فقط تفاوت منتقل میشود — سریع.
- SST (State Snapshot Transfer): اگر نود کاملاً خالی است، کل دیتابیس با
mariabackupکپی میشود — روی دیتابیسهای بزرگ ممکن است چند دقیقه طول بکشد و در این مدت نود donor بار بیشتری میکشد.
بعد از اتصال هر نود، دوباره wsrep_cluster_size را چک کنید؛ باید به ترتیب ۲ و سپس ۳ برسد.
تست HA و بررسی بدون Downtime بودن
برای اطمینان از اینکه کلاستر واقعاً multi-master است، یک جدول تست روی نود ۱ بسازید و بلافاصله از نود ۳ بخوانید:
-- روی نود ۱
CREATE TABLE ha_test (id INT PRIMARY KEY, note VARCHAR(50));
INSERT INTO ha_test VALUES (1, 'from node1');
-- روی نود ۳، بدون فاصله زمانی
SELECT * FROM ha_test;
اگر ردیف بلافاصله دیده شود، replication همزمان کار میکند. برای تست واقعی failover، سرویس MariaDB را روی یکی از نودها متوقف کنید و مطمئن شوید دو نود باقیمانده همچنان کوئری قبول میکنند:
sudo systemctl stop mariadb # روی نود ۲
mysql -h 10.0.0.13 -u root -p -e "SELECT @@wsrep_cluster_size;"
مقدار باید ۲ باشد، و نود ۳ همچنان به درخواستها پاسخ میدهد. این دقیقا همان چیزی است که کلاینتهای اپلیکیشن باید ببینند: قطع یک نود، بدون قطع سرویس.
مقایسه Galera Multi-Master با Replication سنتی
| ویژگی | Galera Cluster (Sync Multi-Master) | Replication سنتی (Async Master-Slave) |
|---|---|---|
| نوشتن | روی هر نودی مجاز است | فقط روی master |
| تاخیر داده بین نودها | صفر — commit روی همه نودها همزمان تایید میشود | چند میلیثانیه تا چند ثانیه، بسته به بار |
| Failover | خودکار، بدون از دست دادن نود نوشتن | نیاز به ابزار جدا (مثل Orchestrator) یا promote دستی slave |
| حداقل تعداد نود برای HA واقعی | ۳ (برای quorum) | ۲ کافی است ولی بدون HA نوشتن |
| پیچیدگی راهاندازی | بالاتر — نیاز به تنظیم SST/IST و شبکه بین نودها | پایینتر |
انتخاب بین این دو به نوع بار اپلیکیشن بستگی دارد. اگر اپلیکیشن نوشتن سنگین و همزمان از چند سرور اپلیکیشن دارد، Galera مزیت واقعی میدهد. اگر بار خواندن غالب است و یک نقطه نوشتن کافی است، replication سنتی سادهتر و کمهزینهتر خواهد بود.
نکاتی برای اجرای Production
چند نکته که در محیط واقعی تفاوت ایجاد میکند:
- Arbitrator برای کلاسترهای دو دیتاسنتری: اگر نودها بین دو مرکز داده تقسیم شدهاند، یک
garbd(Galera Arbitrator) روی سرور سوم سبکوزن اضافه کنید تا در قطع ارتباط بین دو دیتاسنتر، quorum درست تشخیص داده شود. - Load balancing بین نودها: یک لایه مثل ProxySQL یا HAProxy جلوی سه نود قرار دهید تا کلاینتها مستقیم به IP یک نود وابسته نباشند و ترافیک بین نودها توزیع شود.
- مانیتورینگ
wsrep_local_state: این متغیر باید همیشه ۴ (Synced) باشد. مقدار ۲ یا ۳ یعنی نود در حال Donor/Desync یا Joining است و نباید ترافیک نوشتن جدید بگیرد. برای هشدار خودکار روی این متغیر میتوانید همین مانیتورینگ چند سرور با Zabbix را روی هر سه نود پیاده کنید. - بکاپ مستقل از SST: SST یک روش انتقال داده بین نودهاست، نه بکاپ. برای بازیابی فاجعه، همچنان به
mariabackupیاmysqldumpمنظم روی یک نود جدا نیاز دارید.
اگر سرورهای شما ترکیبی از VPS و سرور اختصاصی آریانت هستند، نود روی سرور اختصاصی را میتوان برای بار نوشتن سنگینتر در نظر گرفت، چون منابع دیسک و شبکه آن اختصاصی و پیشبینیپذیرتر است.
جمعبندی
کلاستر Galera با MariaDB یک دیتابیس multi-master میسازد که با از دست رفتن یک نود متوقف نمیشود، به شرط اینکه حداقل سه نود، پورتهای 3306، 4567، 4568 و 4444 بین آنها باز، و binlog_format روی ROW تنظیم شده باشد. Bootstrap فقط یکبار روی نود اول انجام میشود؛ نودهای بعدی از طریق IST یا SST به کلاستر میپیوندند. اگر لایه اپلیکیشن هم روی چند سرور کلاستر شده، راهاندازی کلاستر Docker Swarm روی چند سرور مجازی و اختصاصی مکمل خوبی برای این راهنماست.
اگر میخواهید این معماری را روی زیرساخت خودتان تست کنید، سریعترین راه شروع، بالا آوردن سه نود یکسان و کمهزینه است. میتوانید سه سرور مجازی آریانت را در چند دقیقه راهاندازی کنید و همین راهنما را روی آنها اجرا کنید — برای تست، بعداً هرکدام را جداگانه میتوانید به سرور اختصاصی ترفیع دهید.
