گلرا کلاستر
گلرا، یک کلاسترینگ همزمان و چند مستره برای MariaDB، Mysql و Percona-DB می باشد.
معمولا در کلاسترینگ گلرا، با خرابی یا مشکل در یک نود، کلاسترینگ می تواند به کار خود ادامه دهد، اما با خرابی چند نود، کلاسترینگ نیز دچار مشکل شده و نمی توان به صحت عملکردش اعتماد کرد. دلایل ایجاد مشکل برای ارتباط بین نودهای کلاستر محدود به سخت افزار، شبکه، مشکلات نرم افزاری یا اشتباهات کاربری نمی باشد. اما خبر امیدوار کننده این است که در نهایت مشکل کلاستر، حداقل با یک نود پایدار و در حال کار می ماند و این استمرار سرویس کلاسترینگ می باشد. معمولا اتفاقی که بعد از خرابی یک نود می افتد این است که آن نود نمی تواند خود را مجددا به کلاستر متصل کند.
سناریوهای خرابی کلاستر
براساس تعداد نود مشکل خورده در کلاسترینگ، خرابی های Galera Cluster را می توان به سناریوهای زیر دسته بندی کرد:
- خرابی یک نود
- خرابی چند نود
- خرابی کامل کلاسترینگ
جدای از این سه سناریو، خرابی کلاستر موجب خرابی کامل ارتباط دیتابیس ها می گردد. در حالت نرمال، نودها برای به روز رسانی و نگهداری های متداول نیازمند ریست می باشند. زمانی که یک نود موفق ریست شود، خیلی ساده خود را به کلاستر متصل و اطلاعتش را با دیگر نودها همسان سازی می کند.
بررسی سلامت کلاستر
برای شروع لازم است تا نحوه بررسی و چک کردن گلرا کلاستر را بدانیم. برای این مهم به ترتیب زیر عمل می کنیم:
MariaDB [(none)]> show status like 'wsrep_incoming_addresses';
+--------------------------+----------------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------------+
| wsrep_incoming_addresses | 171.20.0.151:3306,171.20.0.152:3306,171.20.0.153:3306 |
+--------------------------+----------------------------------------------+
1 row in set (0.01 sec)
بررسی تعداد نودهای موجود در کلاسترینگ:
MariaDB [(none)]> show status like 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 3 |
+--------------------+-------+
1 row in set (0.01 sec)
بررسی UUID وضعیت کلاسترینگ:
MariaDB [(none)]> show status like 'wsrep_cluster_state_uuid';
+--------------------------+-----------------------------------------+
| Variable_name | Value |
+--------------------------+-----------------------------------------+
| wsrep_cluster_state_uuid | 345098abd2-291a-9893-acbd3-30923abcdef9 |
+--------------------------+-----------------------------------------+
1 row in set (0.01 sec)
نحوه بررسی همسان بودن نود در کلاستر:
MariaDB [(none)]> show status like 'wsrep_local_state_comment';
+---------------------------+--------+
| Variable_name | Value |
+---------------------------+--------+
| wsrep_local_state_comment | Synced |
+---------------------------+--------+
1 row in set (0.01 sec)
بازگرداندن سناریو یک نود
در این سناریو، فقط یک نود در کلاستر با مشکل مواجه شده است. هیچ اطلاعاتی از دست نرفته و هیچ ارتباطی بین دیتابیس ها مشکل نخورده است. طبق این سناریو، وضعیت به این صورت خواهد بود:
MariaDB [(none)]> show status like 'wsrep_incoming_addresses';
+--------------------------+-------------------------------+
| Variable_name | Value |
+--------------------------+-------------------------------+
| wsrep_incoming_addresses | 171.20.0.151:3306,171.20.0.152:3306 |
+--------------------------+-------------------------------+
1 row in set (0.01 sec)
MariaDB [(none)]> show status like 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 2 |
+--------------------+-------+
1 row in set (0.01 sec)
بعد از ریست نود خراب شده، وضعیت آن را برای متصل شدن متصل شدن دوباره به کلاستر بررسی کنید. اگر به دلایلی وصل نشد خیلی ساده خود سرویس MariaDB را ریست کنید:
$ systemctl restart mariadb
سناریو مشکل چند نود در کلاستر
در این سناریو، تمامی نودها به غیر از یکی مشکل خورده اند که موجب از دست رفتن quorum می شود. در این نقطه، گلرا کلاستر درخواست های SQL را پاسخ نمی دهد. اما از آنجایی که هنوز یک نود بالا بوده و درحال اجرا می باشد، اطلاعاتی از دست نرفته است. در این حالت اگر نودهای مشکل خورده برای آنلاین شدن و اتصال به کلاستر تلاش کنند، نمی توانند موفق شوند چرا که کلاستر از دست رفته است:
MariaDB [(none)]> show status like 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 1 |
+--------------------+-------+
1 row in set (0.01 sec)
MariaDB [(none)]> show status like 'wsrep_cluster_status';
+----------------------+---------+
| Variable_name | Value |
+----------------------+---------+
| wsrep_cluster_status | Primary |
+----------------------+---------+
1 row in set (0.01 sec)
در موارد نادر، ممکن است وضعیت کلاستر را non-Primary نشان دهد. اگر این اتفاق افتاد، علت خطا حتما از دست رفتن quorum نخواهد بود، بله احتمال بر قراری ارتباط شبکه می تواند باشد. توجه داشته باشید که قبل از بازسازی quorum حتما وضعیت نود به Primary تغییر کند.
قبل از بازسازی quorum باید از آخرین commit را به دست بیاریم. برای این مهم دو راه وجود دارد:
Bootstrap خودکار
ساده ترین روش برای راه اندازی مجدد quorum استفاده از bootstrap خودکار است. به وسیله فرمان زیر می توان bootstrap خودکار را در نود فعال کرد:
MariaDB [(none)]> set global wsrep_provider_options='pc.bootstrap=YES';
این فرمان موجب می شود تا نود جاری، به اصلی ترین نود خود راه انداز، تبدیل شده تا دیگر نودهای مشکل خورده بتوانند با اتصال به آن، خود را تصحیح کنند.
Bootstrap دستی
با اجرای دستورات زیر نود جاری به صورت دستی، تبدیل به خود راه انداز، خواهد شد:
$ systemctl stop mariadb
$ galera_new_cluster
$ systemctl restart mariadb
بعد از این که این نود به عنوان نود اصلی راه اندازی و اجرا شد، کافی است تا سرویس MaraiDB روی دیگر نودها را یکی یکی ریست کرد.
بازگرداندن کامل کلاستر
در این سناریو، تمامی نودها مشکل خورده یا به درستی خاموش نشده اند. کل اجزاء quorum از دست رفته و کلاستر دیگر هیچ درخواست SQL ای را پاسخگو نیست. در چنین حالتی، حتی اگر تمامی نودها آنلاین شوند سرویس MariaDB قادر به اجرا نیست. و این به علت خاموش شدن نادرست نودها بوده که هیچ کدام امکان اجرای آخرین کامیت را ندارند. براساس انواع خرابی هایی که به صورت کامل برای گلرا کلاستر اتفاق می افتد راهکارهای متفاوتی نیز وجود دارد.
بازسازی براساس بیشترین مقدار seqno
این روش زمانی کاربردی هست که یک حداقل یک نود به صورت درست و کامل در حین خرابی خاموش شده باشد. نودی با داشتن آخرین دیتا دارای بیشترین مقدار seqno در بین تمامی نودهای خراب می باشد. این موضوع در فایل /var/lib/mysql/grastate.dat قابل مشاهده هست. بسته به این که کدام نود دچار خرابی کامل شده مقدار seqno یا منفی بوده و یا یکی از نودها حاوی بیشتر مقدار seqno می باشد.
در ادامه محتویات فایل grastate.dat در ۳ نود را می توانید مشاهده کنید. معمولا حالت نشان داده شده به هنگام پردازش زبان تعریف داده (DDL) رخ می دهد:
$ cat /var/lib/mysql/grastate.dat
# GALERA saved state
version: 2.1
uuid: 00000000-0000-0000-0000-000000000000
seqno: -1
safe_to_bootstrap: 0
در ادامه محتویات فایل grastate.dat در نود ۲ قابل مشاهده می باشد. این نود در حین پرداز ترنس اکشن با seqno منفی اما با group ID کرش کرده است:
$ cat /var/lib/mysql/grastate.dat
# GALERA saved state
version: 2.1
uuid: 886dd8da-3d07-11e8-a109-8a3c80cebab4
seqno: -1
safe_to_bootstrap: 0
همچنین در ادامه محتویات فایل grastate.dat در نود ۱ با بالاترین seqno قابل رویت هست:
$ cat /var/lib/mysql/grastate.dat
# GALERA saved state
version: 2.1
uuid: 886dd8da-3d07-11e8-a109-8a3c80cebab4
seqno: 31929
safe_to_bootstrap: 1
این نکته را فراموش نکنیم که فقط نودی که به درستی خاموش شده باشد دارای بالاترین مقدار seqno مثبت خواهد بود. این نود، همیشه اولین نودی هست که بازیابی از آن شروع می شود.
اگر در تمامی نودها مقدار seqno -1 باشد و safe_to_bootstrap برابر 0 باشد، این نشانه آن است که خرابی کامل کلاستر رخ داده است. در این نقطه، فقط باید کلاستر را با دستور زیر مجددا راه اندازی نمود. اما این کار تا زمانی که مشخص نشود که هر نود دارای کپی مشخصی از دیتای دیتابیس دارد، به هیچ عنوان توصیه نمی شود.
$ galera_new_cluster
قبل از راه اندازی مجدد نود 1 باید در فایل تنظیمات کلاستر /etc/my.cnf.d/server.cnf برای تعیین آدرس IP نودها تغییری ایجاد کنیم:
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://10.0.0.51,10.0.0.52,10.0.0.53"
wsrep_cluster_name='galeraCluster01'
wsrep_node_address='10.0.0.51'
wsrep_node_name='galera-01'
wsrep_sst_method=rsync
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
نکته این که wsrep_cluster_address نشان دهنده آدرس IP تمامی نودهای کلاستر می باشد که باید به صروت زیر تغییر کند:
wsrep_cluster_address="gcomm://"
هم اکنون می توان سرویس ماریا دی بی این نود را ریست نمود:
$ systemctl restart mariadb
تنهای زمانی می توانیم مبادرت به راه اندازی مجدد دیگر نودها نمود که بعد از ریست این نود از راه اندازی سالم آن اطمینان حاصل کنیم. بعد از راه اندازی کامل و سالم تمامی نودهای دیگر، تنظیمات روی نود 1 را با اضافه نمودن آدرس IP دیگر اعضا و ریست مجدد ادامه می دهیم.
wsrep_cluster_address="gcomm://10.8.8.53,10.8.8.54,10.8.8.55"
هم اکنون گلرا کلاستر باید اجرا شده و تمامی نودها باید خود را با نود اولیه یا اصلی همسان کنند.
بازیابی بر اساس آخرین Commit
بدترین حالت ممکن در خرابی گلرا کلاستر این هست که در تمامی نودها seqno مقدار 1- گرفته و تماما خراب شده باشند. همانطور که پیشتر هم ذکر شده بود، اجرای دستور galera_new_cluster روی یک نود و اتصال مجدد دیگر نودها قبل از تعیین آخرین commit ی که روی کدام نود خورده وسوسه انگیز است. زمانی که دستور galera_new_cluster را اجرا کنید، یک کلاستر جدید ایجاد کرده و دیگر نودها به آن متصل و خود را با آن همسان می کنند.
برای این که تعیین کنیم کدام نود آخرین commit را دارد باید مقدار 'wsrep_last_commit' را روی هر نود جداگانه بررسی کنیم. تنها نودی معتبر است که آخرین مقدار آن بالاترین مقدار باشد. سپس از آن نود راه اندازی مجدد کلاستر را آغاز و دیگر نودها به آن متصل می شوند. برای این موضوع به ترتیب زیر عمل می کنیم:
$ systemctl stop mariadb
مقدار wsrep_cluster_address را در فایل /etc/my.cnf.d/server.cnf باید تغییر دهیم.
wsrep_cluster_address="gcomm://"
سپس:
$ systemctl start mariadb
سپس از داخل دیتابیس مقدار را چک می کنیم:
MariaDB [(none)]> show status like 'wsrep_last_committed';
+----------------------+---------+
| Variable_name | Value |
+----------------------+---------+
| wsrep_last_committed | 319589 |
+----------------------+---------+
1 row in set (0.01 sec)
این عمل را برای به دست آوردن آخرین commit روی تمامی نودها انجام دهید. سپس با اجرای دستور زیر روی نودی که بالاترین مقدار روی آخرین commit کلاسترینگ را مجددا راه اندازی می کنیم.
$ galera_new_cluster
سپس مقدار wsrep_cluster_address را روی دیگر نودها با آدرس IP های نودها تغییر داده و سرویس mariadb را روی آن ها ریست کنید.
در نهایت، بعد از گذشت مدتی، آخرین مقدار commit را روی نودهای مجددا بررسی کنید تا از صحت کلاسترینگ اطمینان حاصل کنید.
