Percona XtraDB Cluster (PXC) یک راهحل پایگاه داده متنباز و با کارایی بالا است که بر پایه MySQL و با استفاده از فناوری Galera توسعه یافته است. این سیستم برای ارائه مقیاسپذیری، دسترسیپذیری بالا (High Availability) و همگامسازی دادهها بهصورت همزمان در چندین گره (Node) طراحی شده است. با استفاده از Galera، دادهها بهصورت خودکار بین گرههای مختلف در یک خوشه (Cluster) همگامسازی میشوند، بهطوری که هر گره میتواند بهعنوان یک نسخه کامل و قابل اعتماد از پایگاه داده عمل کند. این ویژگی، PXC را به گزینهای ایدهآل برای برنامههایی که نیاز به تحمل خطا، توزیع بار و اطمینان از یکپارچگی دادهها دارند، تبدیل میکند. PXC از موتور ذخیرهسازی XtraDB (که نسخه بهبودیافتهای از InnoDB است) استفاده میکند و قابلیتهایی مانند تراکنشهای همزمان، پشتیبانی از عملیات خواندن و نوشتن در تمام گرهها و مدیریت خودکار خرابیها را فراهم میآورد.
نام Galera Cluster از کلمه اسپانیایی “galera” گرفته شده است که به معنای «کشتی پارویی» یا «گالی» است، نوعی کشتی قدیمی که با پارو و بادبان حرکت میکرد و معمولاً برای حمل بار یا در جنگها استفاده میشد. این نام به صورت استعاری برای توصیف نحوه کار این فناوری انتخاب شده است. در یک کشتی پارویی (galera)، پاروزنان باید به صورت هماهنگ و همزمان پارو بزنند تا کشتی به طور مؤثر حرکت کند. به همین ترتیب، در Galera Cluster، نودهای دیتابیس باید به صورت هماهنگ و همزمان (Synchronous Replication) با یکدیگر کار کنند تا دادهها در همه نودها یکسان و بهروز بمانند. این هماهنگی در قلب فناوری Galera قرار دارد.
همانطور که یک کشتی گالرا توسط چندین پاروزن هدایت میشود، Galera Cluster نیز یک سیستم توزیعشده است که از چندین نود تشکیل شده و هر نود نقش خود را در حفظ یکپارچگی و عملکرد کلاستر ایفا میکند. این نودها مانند پاروزنان با هم همکاری میکنند تا کلاستر به طور مؤثر عمل کند.
Galera Cluster توسط شرکت فنلاندی Codership توسعه داده شد. توسعهدهندگان این فناوری نام «Galera» را به دلیل شباهت مفهومی این سیستم به هماهنگی و همکاری در یک کشتی پارویی انتخاب کردند. این نام همچنین کوتاه، بهیادماندنی و مرتبط با ماهیت چندنودی و هماهنگ این فناوری است.
Galera Cluster یک فناوری برای هماهنگسازی همزمان (Synchronous Replication) دیتابیسهای رابطهای (مانند MySQL یا MariaDB) است که امکان ایجاد کلاسترهای چندنودی با یکپارچگی دادهها را فراهم میکند. ویژگی کلیدی آن این است که تمام نودها میتوانند همزمان عملیات خواندن و نوشتن را انجام دهند (Multi-Master Replication)، و تغییرات به صورت خودکار بین نودها هماهنگ میشود. Percona XtraDB Cluster یکی از پیادهسازیهای این فناوری است که بر پایه MySQL توسعه یافته است.
پیشنیازها:
۱. حداقل سه گره (Node): Percona XtraDB Cluster برای اطمینان از تحمل خطا و اجماع (Consensus) به حداقل سه گره نیاز دارد. هر گره باید یک سرور Ubuntu (فیزیکی یا مجازی) باشد.
2. اتصال شبکهای پایدار: گرهها باید از طریق شبکه به یکدیگر متصل باشند و فایروالها (مانند ufw) یا قوانین شبکه باید اجازه ارتباط روی پورتهای موردنیاز (معمولاً ۳۳۰۶، ۴۴۴۴، ۴۵۶۷، ۴۵۶۸) را بدهند.
3. تهیه نسخه پشتیبان: قبل از هرگونه تغییر، از دیتابیس MySQL فعلی خود نسخه پشتیبان تهیه کنید.
4. دسترسی root: باید به حساب root یا کاربری با دسترسی sudo روی هر گره دسترسی داشته باشید.
در این راهنما ما از سه نود با IPهای زیر استفاده میکنیم. فرض بر این است که هر کدام از این نودها در یک شبکه مجزا قرار دارند ولی یکدیگر را در لایه شبکه میبینند:
- نود ۱ (با نام PXC-01): 10.1.1.120
- نود ۲ (با نام PXC-02): 10.2.1.120
- نود ۳ (با نام Garbd-01): 10.3.1.120
همچنین اطمینان از باز بودن پورتهای لازم برای ارتباط بین گرهها بسیار مهم است. پورتهای پیشفرض عبارتند از ۳۳۰۶ (MySQL)، ۴۴۴۴ (SST)، ۴۵۶۷ (Galera replication) و ۴۵۶۸ (IST).
نکته: نود ۱ و نود ۲ حامل کل دیتابیس هستند. نود ۳ به عنوان گره آربیتر برای کمک به تشکیل Quorum در کلاستر است و حامل دیتابیس نیست. به همین دلیل میتوانید آن را بر روی یک سیستم معمولی در کنار سایر سرویسهای خود قرار دهید.
در زیر میتوانید پادکست صوتی این مقاله را به صورت خلاصه بشنوید:
مراحل نصب و راهاندازی Percona XtraDB Cluster در نود ۱ و ۲
نصب Percona XtraDB Cluster:
– مخزن Percona را اضافه کنید:
#wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb
#dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb
#percona-release setup pxc80
#apt update
– Percona XtraDB Cluster را نصب کنید:
#apt install percona-xtradb-cluster
– در طول نصب، ممکن است از شما رمز عبور root برای MySQL/Percona خواسته شود. آن را تنظیم کنید.
توقف سرویس Percona روی همه گرهها:
پس از نصب، سرویس Percona را روی هر دو گره متوقف کنید تا برای پیکربندی خوشه آماده شوند:
#systemctl stop mysql
پیکربندی Percona XtraDB Cluster
فایل پیکربندی Percona را روی هر گره ویرایش کنید:
#vim /etc/mysql/mysql.conf.d/galera.cnf
تنظیمات زیر را اضافه یا ویرایش کنید (مقادیر را بر اساس نیاز خود تنظیم کنید):
galera.cnf
[client]
socket=/var/run/mysqld/mysqld.sock
[mysqld] # General Server Settings
datadir=/var/lib/mysql
socket=/var/run/mysqld/mysqld.sock
user=mysql
bind-address=0.0.0.0
log-error=/var/log/mysql/error.log
pid-file=/var/run/mysqld/mysqld.pid
binlog_expire_logs_seconds=604800
# Galera Provider Configuration
wsrep_provider=/usr/lib/galera4/libgalera_smm.so
wsrep_cluster_name=”pxc-cluster”
wsrep_cluster_address=”gcomm://10.1.1.120,10.2.1.120,10.3.1.120″
wsrep_node_name=”pxc-node2″
wsrep_node_address=”10.1.1.120″
wsrep_sst_method=xtrabackup-v2
pxc_encrypt_cluster_traffic=OFF
binlog_format=ROW
wsrep_slave_threads=8
wsrep_log_conflicts
pxc_strict_mode=ENFORCING
# InnoDB Settings for Galera
innodb_autoinc_lock_mode=2
اگر دستور زیر که مربوط به همگامسازی ssl است را نزنیم ممکن است خطای Certificate Signature Failure را در زمان اجرای mysql در نود ۲ دریافت کنیم. برای رفع این مشکل یا باید خط زیر را در فایل galera.cnf که قبلا ساختهایم ایجاد کنیم. رمزگذاری نکردن ترافیک بین نودها توصیه نمیشود.
pxc_encrypt_cluster_traffic=OFF
سادهترین راه برای رفع این مشکل، پاک کردن آنها و اجازه دادن به Percona برای بازسازی کامل آنهاست. دستور زیر را در هر دو نود میزنیم:
#rm /var/lib/mysql/ca.pem /var/lib/mysql/server-cert.pem /var/lib/mysql/server-key.pem /var/lib/mysql/ca-key.pem /var/lib/mysql/private_key.pem /var/lib/mysql/public_key.pem
برای initialize اولیه کلاستر، باید اولین گره را “bootstrap” کنید. این فرآیند راهاندازی ویژه، آن را به عنوان جزء اصلی کلاستر جدید تعیین میکند و فقط برای یکبار زده میشود.
#systemctl start mysql@bootstrap.service
این دستور نود اول را بهعنوان نقطه شروع کلاستر راهاندازی میکند. mysql@bootstrap.service مانند کلید استارت زدن ماشین است. شما فقط یک لحظه کلید را در حالت استارت نگه میدارید تا موتور روشن شود. پس از روشن شدن موتور، شما کلید را رها میکنید. کلید دیگر در حالت “استارت” باقی نمیماند. سرویس mysql@bootstrap.service دقیقاً همینطور است. این یک دستور یک بار مصرف است که فقط برای روشن کردن “موتور” کلاستر (یعنی اولین گره) زمانی که کل کلاستر خاموش است، استفاده میشود. پس از اینکه اولین گره با موفقیت راهاندازی شد، وظیفه این سرویس تمام شده و غیرفعال (inactive) میشود.
در نود ۲ نیز mysql را اجرا میکنیم:
#systemctl start mysql
نود ۲ بهطور خودکار به کلاستر متصل شده و دادهها را از نود اول همگامسازی میکند (این فرآیند ممکن است بسته به حجم دادهها زمانبر باشد).
راه اندازی نود سوم: گره آربیتر (Garbd) چیست؟
گره آربیتر (Galera Arbitrator یا Garbd) یک ابزار سبکوزن در Galera Cluster (که Percona XtraDB Cluster از آن استفاده میکند) است که برای کمک به تشکیل کوروم (Quorum) در کلاسترهای دیتابیس طراحی شده است، بدون اینکه دادههای دیتابیس را ذخیره کند یا به عنوان یک نود کامل عمل کند. در ادامه توضیح دقیقتری ارائه میشود:
Garbd یک فرآیند مستقل است که به کلاستر Galera متصل میشود و در مکانیزم اجماع (Consensus) شرکت میکند، اما هیچ دادهای از دیتابیس را ذخیره یا پردازش نمیکند. برخلاف نودهای کامل (که دادههای دیتابیس را ذخیره میکنند و عملیات خواندن/نوشتن را انجام میدهند)، آربیتر فقط برای رأیگیری در فرآیند کوروم استفاده میشود. هدف اصلی آن کمک به حفظ کوروم در شرایطی است که تعداد نودهای کامل محدود است یا برای صرفهجویی در منابع، نمیخواهید نود کامل اضافه کنید.
چرا از گره آربیتر استفاده میشود؟
۱. جلوگیری از Split-Brain:
در یک کلاستر Galera، برای جلوگیری از مشکل Split-Brain (تقسیم شبکه و ناسازگاری دادهها)، اکثریت نودها (بیش از نصف) باید فعال باشند. آربیتر بهعنوان یک عضو اضافی در کلاستر عمل میکند و به تشکیل اکثریت کمک میکند.
۲. صرفهجویی در منابع:
راهاندازی یک نود کامل (که دیتابیس را ذخیره و پردازش میکند) نیاز به منابع سختافزاری قابلتوجهی (CPU، RAM، دیسک) دارد. آربیتر بسیار سبک است و نیازی به ذخیره داده یا اجرای MySQL ندارد، بنابراین میتواند روی یک سرور با منابع کم اجرا شود.
۳. پشتیبانی از کوروم در کلاسترهای کوچک:
در یک کلاستر با دو نود کامل، اگر یکی از نودها از دسترس خارج شود، کوروم تشکیل نمیشود و کلاستر متوقف میشود. افزودن یک آربیتر (بهعنوان عضو سوم) این امکان را فراهم میکند که در صورت خرابی یک نود، دو عضو باقیمانده (یک نود کامل + آربیتر) همچنان کوروم را تشکیل دهند و کلاستر فعال بماند.
نحوه کار گره آربیتر:
– نقش در اجماع: آربیتر در فرآیند رأیگیری برای تأیید تراکنشها و تشکیل کوروم شرکت میکند، اما دادههای واقعی دیتابیس را دریافت یا پردازش نمیکند.
– اتصال به کلاستر: آربیتر از طریق پروتکل Galera به نودهای کلاستر متصل میشود و وضعیت کلاستر را مانیتور میکند.
– عدم دخالت در دادهها: چون آربیتر دادهای ذخیره نمیکند، در فرآیندهای State Transfer (مانند IST یا SST) شرکت نمیکند و فقط برای حفظ کوروم استفاده میشود.
مثال سناریو:
فرض کنید یک کلاستر با دو نود کامل دارید. اگر یک نود از کار بیفتد، نود باقیمانده نمیتواند کوروم تشکیل دهد (زیرا ۱ از ۲ اکثریت نیست) و کلاستر متوقف میشود. با افزودن یک آربیتر، کلاستر حالا سه عضو دارد (دو نود کامل + یک آربیتر). اگر یک نود کامل از دسترس خارج شود، نود کامل دیگر و آربیتر همچنان میتوانند کوروم را تشکیل دهند (۲ از ۳) و کلاستر به کار خود ادامه میدهد. آربیتر نمیتواند به تنهایی کوروم را حفظ کند. حداقل یک نود کامل باید فعال باشد.
نصب و پیکربندی Garbd
ابتدا روی سرور جدید اوبونتو، مخازن (Repository) پرکونا را اضافه کنید (اگر قبلاً این کار را نکردهاید).
#wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
#dpkg -i percona-release_latest.generic_all.deb
#percona-release setup pxc80
#apt update
#apt install percona-xtradb-cluster-garbd -y
نصب دستی: با توجه به اینکه در تاریخ این مقاله سایت Percona آدرسهای IP ایران را بسته است، و با استفاده از DNSهای شکن نیز موفقیت آمیز نبود، میتوانید پکیج زیر را در یک نسخه اوبونتو یکسان دانلود کرده و آن را در سیستم خود با دستورات زیر نصب کنید:
#apt download percona-xtradb-cluster-common-8.0
#scp dpkg -i percona-xtradb-cluster-garbd_1%3a8.0.41-32-1.noble_amd64.deb root@<your_destination_IP>:/root/
#dpkg -i percona-xtradb-cluster-garbd_1%3a8.0.41-32-1.noble_amd64.deb
دستور dpkg -i پکیج شما را باز کرده (unpack) ولی به دلیل نبودِ پیشنیاز، آن را پیکربندی نکرده است. شما میتوانید از apt بخواهید که این مشکل را به صورت خودکار حل کند. apt پکیج libboost-program-options1.83.0 را از مخازن استاندارد اوبونتو ۲۴.۰۴ دانلود و نصب کرده و سپس پیکربندی percona-xtradb-cluster-garbd را تکمیل میکند.
#apt-get -f install
پیکربندی Garbd:
vim /etc/default/garb
(Remove this line from file: # REMOVE THIS AFTER CONFIGURATION)
garb
# Copyright (C) 2012 Codership Oy
# This config file is to be sourced by garb service script.
# A comma-separated list of node addresses (address[:port]) in the cluster
# GALERA_NODES=””
GALERA_NODES=”10.1.1.120:4567, 10.2.1.120:4567″
# Galera cluster name, should be the same as on the rest of the nodes.
# GALERA_GROUP=””
GALERA_GROUP=”pxc-cluster”
# Optional Galera internal options string (e.g. SSL settings)
# see https://galeracluster.com/library/documentation/galera-parameters.html
# GALERA_OPTIONS=””
# Log file for garbd. Optional, by default logs to syslog
# Deprecated for CentOS7, use journalctl to query the log for garbd
# LOG_FILE=””
LOG_FILE=”/var/log/garbd.log”
# Where to persist necessary data
# WORK_DIR=””
#touch /var/log/garbd.log
#chown nobody:nogroup /var/log/garbd.log
#service garbd start
#service garbd status
بررسی فایل لاگ آربیتر:
#tail -f /var/log/garbd.log
به یکی از گرههای اصلی دیتابیس خود با کلاینت mysql متصل شوید و دستور زیر را اجرا کنید:
SHOW STATUS LIKE ‘wsrep_cluster_size’;
بررسی کلاستر
برای تایید اینکه کلاستر سه نودی شما فعال و در حال اجرا است، میتوانید در هر یک از نودها به کلاینت MySQL وارد شوید و وضعیت کلاستر را بررسی کنید.
#mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
خروجی باید مقدار ۳ را نشان دهد که نشان میدهد هر سه نود بخشی از کلاستر هستند.
+——————–+——-+
| Variable_name | Value |
+——————–+——-+
| wsrep_cluster_size | 3 |
+——————–+——-+
#mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_incoming_addresses';"
+————————–+————————————————-+
| Variable_name | Value |
+————————–+————————————————-+
| wsrep_incoming_addresses | 10.1.1.120:3306,10.1.1.122:3306,10.1.1.121:3306 |
+————————–+————————————————-+
#mysql -u root -p -e "SHOW STATUS LIKE 'wsrep%';"
مطمئن شوید که `wsrep_ready` برابر با ON است.
پرسش و پاسخ
مهاجرت از موتور ذخیرهسازی InnoDB به XtraDB چگونه است؟
XtraDB در واقع نسخه بهبودیافتهای از InnoDB است که توسط Percona توسعه یافته و در Percona Server یا Percona XtraDB Cluster استفاده میشود. از نظر ساختاری، XtraDB کاملاً با InnoDB سازگار است، زیرا XtraDB بر پایه کد InnoDB ساخته شده و تغییرات آن بیشتر در جهت بهبود عملکرد، مقیاسپذیری و ویژگیهای اضافی است. بنابراین، تبدیل دادهها از InnoDB به XtraDB به معنای تغییر فرمت فایلهای داده نیست، بلکه معمولاً به معنای مهاجرت به یک سرور Percona (مانند Percona Server یا Percona XtraDB Cluster) است که از XtraDB بهعنوان موتور ذخیرهسازی استفاده میکند.
چرا در راهکار Percona XtraDB Cluster نیاز به سه نود برای کلاستر کردن دیتابیس وجود دارد؟
در Percona XtraDB Cluster (PXC) که یک راهکار مبتنی بر Galera Cluster برای کلاستر کردن دیتابیس MySQL است، نیاز به حداقل سه نود برای تشکیل یک کلاستر پایدار به دلایل زیر وجود دارد:
۱. مکانیزم اجماع (Consensus) و تحمل خطا:
PXC از پروتکل اجماع برای اطمینان از هماهنگی دادهها بین نودها استفاده میکند. برای دستیابی به اجماع و جلوگیری از مشکل Split-Brain (تقسیم شبکه که در آن نودها به دو گروه جداگانه تقسیم میشوند و دادهها ناسازگار میشوند)، نیاز به اکثریت نودها (Quorum) است. در یک کلاستر با سه نود، حداقل دو نود باید فعال باشند تا کلاستر به کار خود ادامه دهد. اگر فقط دو نود داشته باشیم و یکی از کار بیفتد، نود باقیمانده نمیتواند اکثریت را تشکیل دهد و کلاستر متوقف میشود.
۲. الگوریتم کوروم (Quorum):
در PXC، کوروم به این معناست که بیش از نیمی از نودها باید در دسترس باشند تا کلاستر بتواند عملیات نوشتن یا هماهنگسازی را انجام دهد. با سه نود، اگر یک نود از دسترس خارج شود، دو نود دیگر همچنان میتوانند اکثریت را تشکیل دهند (۲ از ۳). اما با دو نود، اگر یکی از کار بیفتد، نود دیگر نمیتواند به تنهایی ادامه دهد، زیرا اکثریت (بیش از ۵۰%) وجود ندارد.
۳. جلوگیری از Split-Brain:
در سناریوی Split-Brain، اگر شبکه بین نودها قطع شود، ممکن است هر گروه از نودها فکر کند که گروه دیگر از کار افتاده و به طور مستقل شروع به پذیرش تغییرات کند، که منجر به ناسازگاری دادهها میشود. با سه نود، گروهی که دو نود دارد به عنوان گروه اصلی (Primary Component) انتخاب میشود و گروه تکنودی متوقف میشود، که این امر از ناسازگاری جلوگیری میکند.
۴. حداقل تعداد نودها برای تحمل خطا:
برای تحمل خطای یک نود (Fault Tolerance = 1)، حداقل سه نود لازم است.
۵. پشتیبانی از هماهنگسازی همزمان (Synchronous Replication):
PXC از هماهنگسازی همزمان استفاده میکند، که نیازمند تأیید تراکنشها توسط اکثریت نودها است. وجود سه نود تضمین میکند که حتی در صورت خرابی یک نود، دو نود دیگر میتوانند هماهنگسازی را ادامه دهند و کلاستر به کار خود ادامه دهد.
اگرچه سه نود حداقل تعداد توصیهشده است، میتوان با تعداد بیشتری نود (مثلاً ۵ یا ۷) کلاستر تشکیل داد تا تحمل خطای بیشتری داشته باشیم، اما سه نود حداقل استاندارد برای یک کلاستر پایدار و قابل اعتماد است.
اگر به هر دلیلی به صورت موقت دو تا از نودها از دسترسی خارج شدند، آیا همان تک نود قابل استفاده است و یا سایت (یا اپلیکیشن) از کار می افتد؟ وقتی دو نود دیگر به مدار برگشتند چه اتفاقی می افتد؟
در Percona XtraDB Cluster (PXC) که مبتنی بر Galera Cluster است، اگر به هر دلیلی دو نود از سه نود کلاستر به صورت موقت از دسترس خارج شوند، رفتار سیستم و اتفاقاتی که در بازگشت نودها رخ میدهد به شرح زیر است:
۱. وقتی دو نود از دسترس خارج میشوند و فقط یک نود باقی میماند:
– توقف عملیات کلاستر (عدم دسترسی به تک نود):
در PXC، برای ادامه فعالیت کلاستر، نیاز به اکثریت نودها (Quorum) است. در یک کلاستر سهنودی، حداقل دو نود باید فعال باشند تا کوروم تشکیل شود. اگر دو نود از دسترس خارج شوند، نود باقیمانده نمیتواند به تنهایی کوروم را تشکیل دهد. در نتیجه:
– نود باقیمانده به حالت non-primary (غیراصلی) تغییر وضعیت میدهد.
– این نود از پذیرش درخواستهای نوشتن (Write) یا حتی خواندن (Read) در بسیاری از موارد خودداری میکند، زیرا نمیتواند هماهنگی دادهها را با بقیه کلاستر تضمین کند.
– در این حالت، اگر وبسایت یا برنامه شما به دیتابیس وابسته باشد، به احتمال زیاد سایت از کار میافتد یا حداقل عملکرد دیتابیس متوقف میشود، مگر اینکه برنامه شما به گونهای طراحی شده باشد که با حالت read-only یا cache کار کند.
– چرا تک نود کار نمیکند؟
این رفتار به دلیل مکانیزم اجماع (Consensus) و جلوگیری از Split-Brain است. اگر تک نود اجازه ادامه فعالیت داشته باشد، ممکن است تغییراتی در دادهها اعمال شود که با بازگشت نودهای دیگر ناسازگار باشد، که این امر منجر به مشکلات جدی در یکپارچگی دادهها میشود.
۲. وقتی دو نود دیگر به مدار بازمیگردند:
– تشخیص وضعیت و هماهنگسازی (Synchronization):
وقتی نودهای از دسترس خارجشده دوباره آنلاین شوند، PXC به صورت خودکار تلاش میکند تا کلاستر را به حالت عادی بازگرداند:
– تشکیل مجدد کوروم: اگر حداقل دو نود (در این مورد، با بازگشت یک یا هر دو نود، تعداد نودهای فعال به دو یا سه میرسد) دوباره آنلاین شوند، کلاستر میتواند کوروم را بازسازی کند و به حالت primary بازگردد.
– هماهنگسازی دادهها (State Transfer): نودهایی که دوباره آنلاین شدهاند، وضعیت خود را با نود فعال (یا نودهایی که دادههای بهروز دارند) هماهنگ میکنند. این فرآیند به دو شکل ممکن است رخ دهد:
– Incremental State Transfer (IST): اگر نودهای بازگشتی فقط تغییرات محدودی را از دست داده باشند، فقط تغییرات جدید (Write-set) از نود فعال به آنها منتقل میشود.
– Snapshot State Transfer (SST): اگر نودها تغییرات زیادی را از دست داده باشند یا کاملاً از کلاستر جدا شده باشند، یک کپی کامل از دیتابیس از نود فعال به نودهای بازگشتی منتقل میشود. این فرآیند ممکن است زمانبر باشد، بهویژه اگر دیتابیس بزرگ باشد.
– بازگشت به حالت عادی: پس از هماهنگسازی، کلاستر به حالت عادی بازمیگردد و تمام نودها دوباره آماده پذیرش درخواستهای خواندن و نوشتن میشوند. وبسایت یا برنامه شما نیز در این مرحله باید به عملکرد عادی خود بازگردد، به شرطی که هیچ مشکلی در فرآیند هماهنگسازی رخ ندهد.
اگر به دلایلی هر سه نود از دسترس خارج شدند هم دیگر نیاز به bootstrap کردن نیست؟
نه، در این سناریوی خاص که تمام گرههای دیتابیس به طور همزمان از کار میافتند، حتماً نیاز به بوتاسترپ کردن وجود دارد. وقتی کلاستر در حال اجرا است: اگر یک گره از کار بیفتد و سپس برگردد، یک “مولفه اولیه” (Primary Component) از کلاستر هنوز فعال است. گره بازگشته به سادگی به این مولفه اولیه موجود میپیوندد و اطلاعات خود را همگامسازی میکند. وقتی تمام گرههای دیتابیس خاموش هستند: دیگر “کلاستر فعالی” یا “مولفه اولیه” وجود ندارد که گرهها بتوانند به صورت خودکار به آن بپیوندند. در این حالت، کلاستر به طور کامل از هم پاشیده است. شما باید به صورت دستی به یکی از گرهها بگویید: “تو اولین نفر هستی، کلاستر جدید را شروع کن.” این عمل دقیقاً همان بوتاسترپ کردن است.
برای بوتاسترپ کردن، پیدا کردن گرهای که جدیدترین اطلاعات را دارد حیاتیترین مرحله برای جلوگیری از از دست رفتن دادهها است. به هر یک از سرورهای دیتابیس خود بروید. محتوای فایل `/var/lib/mysql/grastate.dat` را بخوانید. مقدار `seqno` (شماره توالی) را در تمام گرههای دیتابیس با هم مقایسه کنید. گرهای که بالاترین عدد `seqno` را دارد، جدیدترین گره است و کلاستر باید از آن بوتاسترپ شود. فایل `grastate.dat` آن را ویرایش کنید. مقدار `safe_to_bootstrap: 0` را به `safe_to_bootstrap: 1` تغییر دهید. فایل را ذخیره کنید. حالا کلاستر را از این گره بوتاسترپ کنید.
عیبیابی PXC
متن خطا:
It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster…
این خطا یک مکانیزم حفاظتی بسیار مهم در Galera Cluster است و از پاک شدن ناخواسته اطلاعات (Data Loss) جلوگیری میکند. این یک ارور عادی نیست، بلکه یک هشدار جدی است. بوتاسترپ کردن کلاستر از این گره ممکن است امن نباشد. این گره آخرین گرهی نبوده که از کلاستر خارج شده و ممکن است شامل تمام آپدیتها نباشد.
سناریو را تصور کنید: شما یک کلاستر ۳ گرهای دارید. فرض کنید هر سه سرور خاموش میشوند. حالا شما میخواهید کلاستر را دوباره راهاندازی کنید (Bootstrap). Galera باید مطمئن شود که شما کلاستر را از گرهی شروع میکنید که آخرین و جدیدترین اطلاعات را دارد. اگر شما به اشتباه از گرهی شروع کنید که اطلاعاتش قدیمیتر است، تمام تراکنشهایی که بعد از آن روی گرههای دیگر انجام شده برای همیشه پاک خواهند شد، زیرا این گره قدیمی به عنوان “منبع حقیقت” جدید برای کل کلاستر شناخته میشود. این خطا به شما میگوید: “من (این گره) بررسی کردم و متوجه شدم که گره دیگری در کلاستر وجود دارد که اطلاعاتش از من جدیدتر است. برای جلوگیری از پاک شدن اطلاعات، من از بوتاسترپ شدن خودداری میکنم.”
ابتدا مطمئن شوید سرویس mysql روی تمام گرهها (از جمله همین گره) کاملاً متوقف است تا وضعیت آنها تغییر نکند.
#systemctl stop mysql
حالا باید فایل وضعیت (grastate.dat) را در هر سه گره بررسی کنید تا ببینید کدام یک بالاترین شماره توالی (sequence number یا seqno) را دارد. در هر سرور، محتوای فایل grastate.dat را با دستور زیر بخوانید:
#cat /var/lib/mysql/grastate.dat
مقدار seqno را در هر سه سرور با هم مقایسه کنید. گرهای که بالاترین عدد seqno را دارد، جدیدترین گره است و کلاستر باید از آن بوتاسترپ شود. حالا که گره صحیح (با بالاترین seqno) را پیدا کردید، فقط و فقط به همان گره بروید. فایل grastate.dat آن را ویرایش کنید:
#vim /var/lib/mysql/grastate.dat
مقدار safe_to_bootstrap: 0 را به safe_to_bootstrap: 1 تغییر دهید.
#systemctl start mysql@bootstrap.service
پس از اینکه گره اول با موفقیت بوتاسترپ شد، به دو گره دیگر بروید و آنها را به صورت عادی استارت بزنید. آنها به صورت خودکار به گره اول متصل شده و اطلاعات خود را همگامسازی میکنند.
#systemctl start mysql
با دنبال کردن این مراحل، شما کلاستر را به صورت امن و بدون ریسک از دست دادن اطلاعات، مجدداً راهاندازی کردهاید.
