MariaDB
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> MariaDB

Galera Cluster Recovery 101 - Đi sâu vào phân vùng mạng

Một trong những tính năng thú vị trong Galera là cung cấp nút tự động và kiểm soát thành viên. Nếu một nút bị lỗi hoặc mất liên lạc, nó sẽ tự động bị loại khỏi cụm và vẫn chưa hoạt động. Miễn là phần lớn các nút vẫn đang giao tiếp (Galera gọi đây là PC - thành phần chính), thì khả năng rất cao là nút bị lỗi sẽ có thể tự động tham gia lại, đồng bộ hóa lại và tiếp tục sao chép sau khi kết nối trở lại.

Nói chung, tất cả các nút Galera đều bằng nhau. Chúng nắm giữ cùng một tập dữ liệu và có cùng vai trò như chính, có khả năng xử lý đọc và ghi đồng thời, nhờ vào giao tiếp nhóm Galera và plugin sao chép dựa trên chứng chỉ. Do đó, thực tế không có chuyển đổi dự phòng từ quan điểm cơ sở dữ liệu do trạng thái cân bằng này. Chỉ từ phía ứng dụng yêu cầu chuyển đổi dự phòng, để bỏ qua các nút chưa hoạt động trong khi cụm được phân vùng.

Trong bài đăng trên blog này, chúng ta sẽ tìm hiểu cách Galera Cluster thực hiện khôi phục nút và cụm trong trường hợp phân vùng mạng xảy ra. Chỉ là một lưu ý phụ, chúng tôi đã đề cập đến một chủ đề tương tự trong bài đăng trên blog này một thời gian trước. Codership đã giải thích rất chi tiết về khái niệm khôi phục của Galera trong trang tài liệu, Node Failure and Recovery.

Lỗi nút và trục xuất

Để hiểu được quá trình khôi phục, trước tiên chúng ta phải hiểu cách Galera phát hiện lỗi và quá trình loại bỏ nút. Hãy đưa điều này vào một kịch bản thử nghiệm có kiểm soát để chúng ta có thể hiểu rõ hơn về quá trình trục xuất. Giả sử chúng ta có một Cụm Galera ba nút như được minh họa bên dưới:

Lệnh sau có thể được sử dụng để truy xuất các tùy chọn nhà cung cấp Galera của chúng tôi:

mysql> SHOW VARIABLES LIKE 'wsrep_provider_options'\G

Đó là một danh sách dài, nhưng chúng ta chỉ cần tập trung vào một số thông số để giải thích quá trình:

evs.inactive_check_period = PT0.5S; 
evs.inactive_timeout = PT15S; 
evs.keepalive_period = PT1S; 
evs.suspect_timeout = PT5S; 
evs.view_forget_timeout = P1D;
gmcast.peer_timeout = PT3S;

Trước hết, Galera tuân theo định dạng ISO 8601 để thể hiện thời lượng. P1D có nghĩa là thời lượng là một ngày, trong khi PT15S có nghĩa là thời lượng là 15 giây (lưu ý bộ chỉ định thời gian, T, đứng trước giá trị thời gian). Ví dụ:nếu một người muốn tăng evs.view_forget_timeout đến 1 ngày rưỡi, một người sẽ đặt P1DT12H hoặc PT36H.

Xem xét tất cả các máy chủ chưa được định cấu hình với bất kỳ quy tắc tường lửa nào, chúng tôi sử dụng tập lệnh sau có tên là block_galera.sh trên galera2 để mô phỏng lỗi mạng đến / từ nút này:

#!/bin/bash
# block_galera.sh
# galera2, 192.168.55.172

iptables -I INPUT -m tcp -p tcp --dport 4567 -j REJECT
iptables -I INPUT -m tcp -p tcp --dport 3306 -j REJECT
iptables -I OUTPUT -m tcp -p tcp --dport 4567 -j REJECT
iptables -I OUTPUT -m tcp -p tcp --dport 3306 -j REJECT
# print timestamp
date

Bằng cách thực thi tập lệnh, chúng tôi nhận được kết quả sau:

$ ./block_galera.sh
Wed Jul  4 16:46:02 UTC 2018

Dấu thời gian được báo cáo có thể được coi là thời điểm bắt đầu phân vùng cụm, nơi chúng ta mất galera2, trong khi galera1 và galera3 vẫn trực tuyến và có thể truy cập được. Tại thời điểm này, kiến ​​trúc Cụm Galera của chúng tôi trông giống như sau:

Từ phối cảnh nút phân vùng

Trên galera2, bạn sẽ thấy một số bản in bên trong nhật ký lỗi MySQL. Hãy chia chúng thành nhiều phần. Thời gian ngừng hoạt động được bắt đầu vào khoảng 16:46:02 giờ UTC và sau gmcast.peer_timeout =PT3S , thông tin sau sẽ xuất hiện:

2018-07-04 16:46:05 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') connection to peer 8b2041d6 with addr tcp://192.168.55.173:4567 timed out, no messages seen in PT3S
2018-07-04 16:46:05 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://192.168.55.173:4567
2018-07-04 16:46:06 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') connection to peer 737422d6 with addr tcp://192.168.55.171:4567 timed out, no messages seen in PT3S
2018-07-04 16:46:06 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') reconnecting to 8b2041d6 (tcp://192.168.55.173:4567), attempt 0

Khi nó đi qua evs.suspect_timeout =PT5S , cả hai nút galera1 và galera3 đều bị nghi ngờ là đã chết bởi galera2:

2018-07-04 16:46:07 140454904243968 [Note] WSREP: evs::proto(62116b35, OPERATIONAL, view_id(REG,62116b35,54)) suspecting node: 8b2041d6
2018-07-04 16:46:07 140454904243968 [Note] WSREP: evs::proto(62116b35, OPERATIONAL, view_id(REG,62116b35,54)) suspected node without join message, declaring inactive
2018-07-04 16:46:07 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') reconnecting to 737422d6 (tcp://192.168.55.171:4567), attempt 0
2018-07-04 16:46:08 140454904243968 [Note] WSREP: evs::proto(62116b35, GATHER, view_id(REG,62116b35,54)) suspecting node: 737422d6
2018-07-04 16:46:08 140454904243968 [Note] WSREP: evs::proto(62116b35, GATHER, view_id(REG,62116b35,54)) suspected node without join message, declaring inactive

Sau đó, Galera sẽ sửa đổi chế độ xem cụm hiện tại và vị trí của nút này:

2018-07-04 16:46:09 140454904243968 [Note] WSREP: view(view_id(NON_PRIM,62116b35,54) memb {
        62116b35,0
} joined {
} left {
} partitioned {
        737422d6,0
        8b2041d6,0
})
2018-07-04 16:46:09 140454904243968 [Note] WSREP: view(view_id(NON_PRIM,62116b35,55) memb {
        62116b35,0
} joined {
} left {
} partitioned {
        737422d6,0
        8b2041d6,0
})

Với chế độ xem cụm mới, Galera sẽ thực hiện phép tính đại số để quyết định xem nút này có phải là một phần của thành phần chính hay không. Nếu thành phần mới nhìn thấy "primary =no", Galera sẽ hạ cấp trạng thái nút cục bộ từ SYNCED thành OPEN:

2018-07-04 16:46:09 140454288942848 [Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 0, memb_num = 1
2018-07-04 16:46:09 140454288942848 [Note] WSREP: Flow-control interval: [16, 16]
2018-07-04 16:46:09 140454288942848 [Note] WSREP: Trying to continue unpaused monitor
2018-07-04 16:46:09 140454288942848 [Note] WSREP: Received NON-PRIMARY.
2018-07-04 16:46:09 140454288942848 [Note] WSREP: Shifting SYNCED -> OPEN (TO: 2753699)

Với thay đổi mới nhất về chế độ xem cụm và trạng thái nút, Galera trả lại chế độ xem cụm sau loại bỏ và trạng thái toàn cục như bên dưới:

2018-07-04 16:46:09 140454222194432 [Note] WSREP: New cluster view: global state: 55238f52-41ee-11e8-852f-3316bdb654bc:2753699, view# -1: non-Primary, number of nodes: 1, my index: 0, protocol version 3
2018-07-04 16:46:09 140454222194432 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.

Bạn có thể thấy trạng thái toàn cầu sau đây của galera2 đã thay đổi trong khoảng thời gian này:

mysql> SELECT * FROM information_schema.global_status WHERE variable_name IN ('WSREP_CLUSTER_STATUS','WSREP_LOCAL_STATE_COMMENT','WSREP_CLUSTER_SIZE','WSREP_EVS_DELAYED','WSREP_READY');
+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------+
| VARIABLE_NAME             | VARIABLE_VALUE                                                                                                                    |
+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------+
| WSREP_CLUSTER_SIZE        | 1                                                                                                                                 |
| WSREP_CLUSTER_STATUS      | non-Primary                                                                                                                       |
| WSREP_EVS_DELAYED         | 737422d6-7db3-11e8-a2a2-bbe98913baf0:tcp://192.168.55.171:4567:1,8b2041d6-7f62-11e8-87d5-12a76678131f:tcp://192.168.55.173:4567:2 |
| WSREP_LOCAL_STATE_COMMENT | Initialized                                                                                                                       |
| WSREP_READY               | OFF                                                                                                                               |
+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------+

Tại thời điểm này, máy chủ MySQL / MariaDB trên galera2 vẫn có thể truy cập được (cơ sở dữ liệu đang lắng nghe trên 3306 và Galera trên 4567) và bạn có thể truy vấn các bảng hệ thống mysql và liệt kê các cơ sở dữ liệu và bảng. Tuy nhiên, khi bạn chuyển sang các bảng không thuộc hệ thống và thực hiện một truy vấn đơn giản như sau:

mysql> SELECT * FROM sbtest1;
ERROR 1047 (08S01): WSREP has not yet prepared node for application use

Bạn sẽ ngay lập tức gặp lỗi cho biết WSREP đã được tải nhưng nút này chưa sẵn sàng để sử dụng, như được báo cáo bởi wsrep_ready tình trạng. Điều này là do nút mất kết nối với Thành phần chính và nó chuyển sang trạng thái không hoạt động (trạng thái nút cục bộ đã được thay đổi từ SYNCED thành OPEN). Dữ liệu đọc từ các nút ở trạng thái không hoạt động được coi là cũ, trừ khi bạn đặt wsrep_dirty_reads =ON để cho phép đọc, mặc dù Galera vẫn từ chối bất kỳ lệnh nào sửa đổi hoặc cập nhật cơ sở dữ liệu.

Cuối cùng, Galera sẽ tiếp tục lắng nghe và kết nối lại vô hạn với các thành viên khác trong nền:

2018-07-04 16:47:12 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') reconnecting to 8b2041d6 (tcp://192.168.55.173:4567), attempt 30
2018-07-04 16:47:13 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') reconnecting to 737422d6 (tcp://192.168.55.171:4567), attempt 30
2018-07-04 16:48:20 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') reconnecting to 8b2041d6 (tcp://192.168.55.173:4567), attempt 60
2018-07-04 16:48:22 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') reconnecting to 737422d6 (tcp://192.168.55.171:4567), attempt 60

Có thể tóm tắt luồng quy trình loại bỏ bằng giao tiếp nhóm Galera cho nút được phân vùng trong sự cố mạng như sau:

  1. Ngắt kết nối khỏi cụm sau gmcast.peer_timeout .
  2. Nghi ngờ các nút khác sau evs.suspect_timeout .
  3. Truy xuất chế độ xem cụm mới.
  4. Thực hiện phép tính đại số để xác định trạng thái của nút.
  5. Giảm hạng nút từ SYNCED thành OPEN.
  6. Cố gắng kết nối lại với thành phần chính (các nút Galera khác) trong nền.

Từ Phối cảnh Thành phần Chính

Trên galera1 và galera3 tương ứng, sau gmcast.peer_timeout =PT3S , phần sau xuất hiện trong nhật ký lỗi MySQL:

2018-07-04 16:46:05 139955510687488 [Note] WSREP: (8b2041d6, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://192.168.55.172:4567
2018-07-04 16:46:06 139955510687488 [Note] WSREP: (8b2041d6, 'tcp://0.0.0.0:4567') reconnecting to 62116b35 (tcp://192.168.55.172:4567), attempt 0

Sau khi nó vượt qua evs.suspect_timeout =PT5S , galera2 bị nghi ngờ là đã chết bởi galera3 (và galera1):

2018-07-04 16:46:10 139955510687488 [Note] WSREP: evs::proto(8b2041d6, OPERATIONAL, view_id(REG,62116b35,54)) suspecting node: 62116b35
2018-07-04 16:46:10 139955510687488 [Note] WSREP: evs::proto(8b2041d6, OPERATIONAL, view_id(REG,62116b35,54)) suspected node without join message, declaring inactive

Galera kiểm tra xem các nút khác có phản hồi với giao tiếp nhóm trên galera3 hay không, nó nhận thấy galera1 đang ở trạng thái chính và ổn định:

2018-07-04 16:46:11 139955510687488 [Note] WSREP: declaring 737422d6 at tcp://192.168.55.171:4567 stable
2018-07-04 16:46:11 139955510687488 [Note] WSREP: Node 737422d6 state prim

Galera sửa đổi chế độ xem cụm của nút này (galera3):

2018-07-04 16:46:11 139955510687488 [Note] WSREP: view(view_id(PRIM,737422d6,55) memb {
        737422d6,0
        8b2041d6,0
} joined {
} left {
} partitioned {
        62116b35,0
})
2018-07-04 16:46:11 139955510687488 [Note] WSREP: save pc into disk

Sau đó, Galera xóa nút được phân vùng khỏi Thành phần chính:

2018-07-04 16:46:11 139955510687488 [Note] WSREP: forgetting 62116b35 (tcp://192.168.55.172:4567)

Thành phần chính mới hiện bao gồm hai nút, galera1 và galera3:

2018-07-04 16:46:11 139955502294784 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 1, memb_num = 2

Thành phần chính sẽ trao đổi trạng thái giữa nhau để thống nhất về chế độ xem cụm mới và trạng thái toàn cục:

2018-07-04 16:46:11 139955502294784 [Note] WSREP: STATE EXCHANGE: Waiting for state UUID.
2018-07-04 16:46:11 139955510687488 [Note] WSREP: (8b2041d6, 'tcp://0.0.0.0:4567') turning message relay requesting off
2018-07-04 16:46:11 139955502294784 [Note] WSREP: STATE EXCHANGE: sent state msg: b3d38100-7f66-11e8-8e70-8e3bf680c993
2018-07-04 16:46:11 139955502294784 [Note] WSREP: STATE EXCHANGE: got state msg: b3d38100-7f66-11e8-8e70-8e3bf680c993 from 0 (192.168.55.171)
2018-07-04 16:46:11 139955502294784 [Note] WSREP: STATE EXCHANGE: got state msg: b3d38100-7f66-11e8-8e70-8e3bf680c993 from 1 (192.168.55.173)

Galera tính toán và xác minh số đại biểu trao đổi trạng thái giữa các thành viên trực tuyến:

2018-07-04 16:46:11 139955502294784 [Note] WSREP: Quorum results:
        version    = 4,
        component  = PRIMARY,
        conf_id    = 27,
        members    = 2/2 (joined/total),
        act_id     = 2753703,
        last_appl. = 2753606,
        protocols  = 0/8/3 (gcs/repl/appl),
        group UUID = 55238f52-41ee-11e8-852f-3316bdb654bc
2018-07-04 16:46:11 139955502294784 [Note] WSREP: Flow-control interval: [23, 23]
2018-07-04 16:46:11 139955502294784 [Note] WSREP: Trying to continue unpaused monitor

Galera cập nhật chế độ xem cụm mới và trạng thái toàn cầu sau khi loại bỏ galera2:

2018-07-04 16:46:11 139955214169856 [Note] WSREP: New cluster view: global state: 55238f52-41ee-11e8-852f-3316bdb654bc:2753703, view# 28: Primary, number of nodes: 2, my index: 1, protocol version 3
2018-07-04 16:46:11 139955214169856 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2018-07-04 16:46:11 139955214169856 [Note] WSREP: REPL Protocols: 8 (3, 2)
2018-07-04 16:46:11 139955214169856 [Note] WSREP: Assign initial position for certification: 2753703, protocol version: 3
2018-07-04 16:46:11 139956691814144 [Note] WSREP: Service thread queue flushed.
Clean up the partitioned node (galera2) from the active list:
2018-07-04 16:46:14 139955510687488 [Note] WSREP: cleaning up 62116b35 (tcp://192.168.55.172:4567)

Tại thời điểm này, cả galera1 và galera3 sẽ báo cáo trạng thái toàn cầu tương tự:

mysql> SELECT * FROM information_schema.global_status WHERE variable_name IN ('WSREP_CLUSTER_STATUS','WSREP_LOCAL_STATE_COMMENT','WSREP_CLUSTER_SIZE','WSREP_EVS_DELAYED','WSREP_READY');
+---------------------------+------------------------------------------------------------------+
| VARIABLE_NAME             | VARIABLE_VALUE                                                   |
+---------------------------+------------------------------------------------------------------+
| WSREP_CLUSTER_SIZE        | 2                                                                |
| WSREP_CLUSTER_STATUS      | Primary                                                          |
| WSREP_EVS_DELAYED         | 1491abd9-7f6d-11e8-8930-e269b03673d8:tcp://192.168.55.172:4567:1 |
| WSREP_LOCAL_STATE_COMMENT | Synced                                                           |
| WSREP_READY               | ON                                                               |
+---------------------------+------------------------------------------------------------------+

Họ liệt kê thành viên có vấn đề trong wsrep_evs_delayed tình trạng. Vì trạng thái cục bộ là "Đã đồng bộ hóa", các nút này đang hoạt động và bạn có thể chuyển hướng các kết nối máy khách từ galera2 đến bất kỳ nút nào trong số chúng. Nếu bước này không thuận tiện, hãy xem xét sử dụng bộ cân bằng tải ở phía trước cơ sở dữ liệu để đơn giản hóa điểm cuối kết nối từ các máy khách.

Khôi phục và tham gia nút

Một nút Galera được phân vùng sẽ tiếp tục cố gắng thiết lập kết nối với Thành phần chính một cách vô hạn. Hãy xóa các quy tắc iptables trên galera2 để cho phép nó kết nối với các nút còn lại:

# on galera2
$ iptables -F

Khi nút có khả năng kết nối với một trong các nút, Galera sẽ bắt đầu thiết lập lại giao tiếp nhóm tự động:

2018-07-09 10:46:34 140075962705664 [Note] WSREP: (1491abd9, 'tcp://0.0.0.0:4567') connection established to 8b2041d6 tcp://192.168.55.173:4567
2018-07-09 10:46:34 140075962705664 [Note] WSREP: (1491abd9, 'tcp://0.0.0.0:4567') connection established to 737422d6 tcp://192.168.55.171:4567
2018-07-09 10:46:34 140075962705664 [Note] WSREP: declaring 737422d6 at tcp://192.168.55.171:4567 stable
2018-07-09 10:46:34 140075962705664 [Note] WSREP: declaring 8b2041d6 at tcp://192.168.55.173:4567 stable

Sau đó, nút galera2 sẽ kết nối với một trong các Thành phần chính (trong trường hợp này là galera1, ID nút 737422d6) để có được chế độ xem cụm hiện tại và trạng thái các nút:

2018-07-09 10:46:34 140075962705664 [Note] WSREP: Node 737422d6 state prim
2018-07-09 10:46:34 140075962705664 [Note] WSREP: view(view_id(PRIM,1491abd9,142) memb {
        1491abd9,0
        737422d6,0
        8b2041d6,0
} joined {
} left {
} partitioned {
})
2018-07-09 10:46:34 140075962705664 [Note] WSREP: save pc into disk

Galera sau đó sẽ thực hiện trao đổi trạng thái với các thành viên còn lại có thể tạo thành Thành phần chính:

2018-07-09 10:46:34 140075954312960 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 0, memb_num = 3
2018-07-09 10:46:34 140075954312960 [Note] WSREP: STATE_EXCHANGE: sent state UUID: 4b23eaa0-8322-11e8-a87e-fe4e0fce2a5f
2018-07-09 10:46:34 140075954312960 [Note] WSREP: STATE EXCHANGE: sent state msg: 4b23eaa0-8322-11e8-a87e-fe4e0fce2a5f
2018-07-09 10:46:34 140075954312960 [Note] WSREP: STATE EXCHANGE: got state msg: 4b23eaa0-8322-11e8-a87e-fe4e0fce2a5f from 0 (192.168.55.172)
2018-07-09 10:46:34 140075954312960 [Note] WSREP: STATE EXCHANGE: got state msg: 4b23eaa0-8322-11e8-a87e-fe4e0fce2a5f from 1 (192.168.55.171)
2018-07-09 10:46:34 140075954312960 [Note] WSREP: STATE EXCHANGE: got state msg: 4b23eaa0-8322-11e8-a87e-fe4e0fce2a5f from 2 (192.168.55.173)

Trao đổi trạng thái cho phép galera2 tính toán số đại biểu và tạo ra kết quả sau:

2018-07-09 10:46:34 140075954312960 [Note] WSREP: Quorum results:
        version    = 4,
        component  = PRIMARY,
        conf_id    = 71,
        members    = 2/3 (joined/total),
        act_id     = 2836958,
        last_appl. = 0,
        protocols  = 0/8/3 (gcs/repl/appl),
        group UUID = 55238f52-41ee-11e8-852f-3316bdb654bc

Sau đó, Galera sẽ thúc đẩy trạng thái nút cục bộ từ MỞ sang CHÍNH, để bắt đầu và thiết lập kết nối nút với Thành phần chính:

2018-07-09 10:46:34 140075954312960 [Note] WSREP: Flow-control interval: [28, 28]
2018-07-09 10:46:34 140075954312960 [Note] WSREP: Trying to continue unpaused monitor
2018-07-09 10:46:34 140075954312960 [Note] WSREP: Shifting OPEN -> PRIMARY (TO: 2836958)

Như đã báo cáo ở dòng trên, Galera tính toán khoảng cách về khoảng cách nút phía sau so với cụm. Nút này yêu cầu chuyển trạng thái để bắt kịp bộ ghi số 2836958 từ 2761994:

2018-07-09 10:46:34 140075929970432 [Note] WSREP: State transfer required:
        Group state: 55238f52-41ee-11e8-852f-3316bdb654bc:2836958
        Local state: 55238f52-41ee-11e8-852f-3316bdb654bc:2761994
2018-07-09 10:46:34 140075929970432 [Note] WSREP: New cluster view: global state: 55238f52-41ee-11e8-852f-3316bdb654bc:2836958, view# 72: Primary, number of nodes:
3, my index: 0, protocol version 3
2018-07-09 10:46:34 140075929970432 [Warning] WSREP: Gap in state sequence. Need state transfer.
2018-07-09 10:46:34 140075929970432 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2018-07-09 10:46:34 140075929970432 [Note] WSREP: REPL Protocols: 8 (3, 2)
2018-07-09 10:46:34 140075929970432 [Note] WSREP: Assign initial position for certification: 2836958, protocol version: 3

Galera chuẩn bị trình nghe IST trên cổng 4568 trên nút này và yêu cầu bất kỳ nút nào được Đồng bộ hóa trong cụm trở thành nhà tài trợ. Trong trường hợp này, Galera tự động chọn galera3 (192.168.55.173) hoặc nó cũng có thể chọn một nhà tài trợ từ danh sách trong wsrep_sst_donor (nếu được xác định) cho hoạt động đồng bộ hóa:

2018-07-09 10:46:34 140075996276480 [Note] WSREP: Service thread queue flushed.
2018-07-09 10:46:34 140075929970432 [Note] WSREP: IST receiver addr using tcp://192.168.55.172:4568
2018-07-09 10:46:34 140075929970432 [Note] WSREP: Prepared IST receiver, listening at: tcp://192.168.55.172:4568
2018-07-09 10:46:34 140075954312960 [Note] WSREP: Member 0.0 (192.168.55.172) requested state transfer from '*any*'. Selected 2.0 (192.168.55.173)(SYNCED) as donor.

Sau đó, nó sẽ thay đổi trạng thái nút cục bộ từ PRIMARY thành JOINER. Ở giai đoạn này, galera2 được cấp yêu cầu chuyển trạng thái và bắt đầu lưu vào bộ nhớ cache các bộ ghi:

2018-07-09 10:46:34 140075954312960 [Note] WSREP: Shifting PRIMARY -> JOINER (TO: 2836958)
2018-07-09 10:46:34 140075929970432 [Note] WSREP: Requesting state transfer: success, donor: 2
2018-07-09 10:46:34 140075929970432 [Note] WSREP: GCache history reset: 55238f52-41ee-11e8-852f-3316bdb654bc:2761994 -> 55238f52-41ee-11e8-852f-3316bdb654bc:2836958
2018-07-09 10:46:34 140075929970432 [Note] WSREP: GCache DEBUG: RingBuffer::seqno_reset(): full reset

Node galera2 bắt đầu nhận các bản ghi còn thiếu từ gcache của nhà tài trợ đã chọn (galera3):

2018-07-09 10:46:34 140075954312960 [Note] WSREP: 2.0 (192.168.55.173): State transfer to 0.0 (192.168.55.172) complete.
2018-07-09 10:46:34 140075929970432 [Note] WSREP: Receiving IST: 74964 writesets, seqnos 2761994-2836958
2018-07-09 10:46:34 140075593627392 [Note] WSREP: Receiving IST...  0.0% (    0/74964 events) complete.
2018-07-09 10:46:34 140075954312960 [Note] WSREP: Member 2.0 (192.168.55.173) synced with group.
2018-07-09 10:46:34 140075962705664 [Note] WSREP: (1491abd9, 'tcp://0.0.0.0:4567') connection established to 737422d6 tcp://192.168.55.171:4567
2018-07-09 10:46:41 140075962705664 [Note] WSREP: (1491abd9, 'tcp://0.0.0.0:4567') turning message relay requesting off
2018-07-09 10:46:44 140075593627392 [Note] WSREP: Receiving IST... 36.0% (27008/74964 events) complete.
2018-07-09 10:46:54 140075593627392 [Note] WSREP: Receiving IST... 71.6% (53696/74964 events) complete.
2018-07-09 10:47:02 140075593627392 [Note] WSREP: Receiving IST...100.0% (74964/74964 events) complete.
2018-07-09 10:47:02 140075929970432 [Note] WSREP: IST received: 55238f52-41ee-11e8-852f-3316bdb654bc:2836958
2018-07-09 10:47:02 140075954312960 [Note] WSREP: 0.0 (192.168.55.172): State transfer from 2.0 (192.168.55.173) complete.

Sau khi tất cả các tập ghi còn thiếu được nhận và áp dụng, Galera sẽ quảng cáo galera2 dưới dạng THAM GIA cho đến seqno 2837012:

2018-07-09 10:47:02 140075954312960 [Note] WSREP: Shifting JOINER -> JOINED (TO: 2837012)
2018-07-09 10:47:02 140075954312960 [Note] WSREP: Member 0.0 (192.168.55.172) synced with group.

Nút áp dụng bất kỳ tập ghi được lưu trong bộ nhớ cache nào trong hàng đợi nô lệ của nó và kết thúc việc bắt kịp với cụm. Hàng đợi nô lệ của nó hiện đang trống. Galera sẽ quảng bá galera2 thành SYNCED, cho biết nút hiện đã hoạt động và sẵn sàng phục vụ khách hàng:

2018-07-09 10:47:02 140075954312960 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 2837012)
2018-07-09 10:47:02 140076605892352 [Note] WSREP: Synchronized with group, ready for connections

Tại thời điểm này, tất cả các nút đã hoạt động trở lại. Bạn có thể xác minh bằng cách sử dụng các câu lệnh sau trên galera2:

mysql> SELECT * FROM information_schema.global_status WHERE variable_name IN ('WSREP_CLUSTER_STATUS','WSREP_LOCAL_STATE_COMMENT','WSREP_CLUSTER_SIZE','WSREP_EVS_DELAYED','WSREP_READY');
+---------------------------+----------------+
| VARIABLE_NAME             | VARIABLE_VALUE |
+---------------------------+----------------+
| WSREP_CLUSTER_SIZE        | 3              |
| WSREP_CLUSTER_STATUS      | Primary        |
| WSREP_EVS_DELAYED         |                |
| WSREP_LOCAL_STATE_COMMENT | Synced         |
| WSREP_READY               | ON             |
+---------------------------+----------------+

wsrep_cluster_size được báo cáo là 3 và trạng thái cụm là Chính, cho biết galera2 là một phần của Thành phần chính. wsrep_evs_delayed cũng đã bị xóa và trạng thái cục bộ hiện đã được Đồng bộ hóa.

Quy trình khôi phục cho nút được phân vùng trong sự cố mạng có thể được tóm tắt như sau:

  1. Thiết lập lại giao tiếp nhóm với các nút khác.
  2. Truy xuất chế độ xem cụm từ một trong các Thành phần chính.
  3. Thực hiện trao đổi trạng thái với Thành phần chính và tính toán số đại biểu.
  4. Thay đổi trạng thái nút cục bộ từ MỞ sang CHÍNH.
  5. Tính toán khoảng cách giữa nút cục bộ và cụm.
  6. Thay đổi trạng thái nút cục bộ từ PRIMARY thành JOINER.
  7. Chuẩn bị bộ nghe / bộ nhận IST trên cổng 4568.
  8. Yêu cầu chuyển trạng thái qua IST và chọn một nhà tài trợ.
  9. Bắt đầu nhận và áp dụng bộ ghi còn thiếu từ bộ nhớ đệm của nhà tài trợ đã chọn.
  10. Thay đổi trạng thái nút cục bộ từ JOINER thành JOINED.
  11. Bắt kịp cụm bằng cách áp dụng các bộ ghi được lưu trong bộ nhớ cache trong hàng đợi nô lệ.
  12. Thay đổi trạng thái nút cục bộ từ JOINED thành SYNCED.

Lỗi cụm

Một Cụm Galera được coi là không thành công nếu không có thành phần chính (PC) nào khả dụng. Hãy xem xét một Cụm Galera ba nút tương tự như được mô tả trong sơ đồ bên dưới:

Một cụm được coi là hoạt động nếu tất cả các nút hoặc phần lớn các nút đều trực tuyến. Trực tuyến có nghĩa là họ có thể nhìn thấy nhau thông qua lưu lượng sao chép của Galera hoặc giao tiếp nhóm. Nếu không có lưu lượng truy cập nào đến và đi từ nút, cụm sẽ gửi một báo hiệu nhịp tim để nút phản hồi kịp thời. Nếu không, nó sẽ được đưa vào danh sách trì hoãn hoặc bị nghi ngờ theo cách phản hồi của nút.

Nếu một nút gặp trục trặc, giả sử nút C, cụm sẽ vẫn hoạt động vì nút A và B vẫn ở trong số đại biểu với 2 phiếu bầu trong số 3 để tạo thành một thành phần chính. Bạn sẽ nhận được trạng thái cụm sau trên A và B:

mysql> SHOW STATUS LIKE 'wsrep_cluster_status';
+----------------------+---------+
| Variable_name        | Value   |
+----------------------+---------+
| wsrep_cluster_status | Primary |
+----------------------+---------+

Nếu giả sử một công tắc chính bị lỗi, như được minh họa trong sơ đồ sau:

Tại thời điểm này, mọi nút đơn lẻ đều mất liên lạc với nhau và trạng thái cụm sẽ được báo cáo là không phải Chính trên tất cả các nút (như những gì đã xảy ra với galera2 trong trường hợp trước). Mỗi nút sẽ tính toán số đại biểu và phát hiện ra rằng nó là thiểu số (1 phiếu bầu trong số 3) do đó mất đi số đại biểu, có nghĩa là không có Thành phần chính nào được hình thành và do đó tất cả các nút từ chối cung cấp bất kỳ dữ liệu nào. Đây được coi là lỗi cụm.

Khi sự cố mạng được giải quyết, Galera sẽ tự động thiết lập lại giao tiếp giữa các thành viên, trao đổi trạng thái của nút và xác định khả năng cải tổ thành phần chính bằng cách so sánh trạng thái nút, UUID và seqnos. Nếu xác suất là có, Galera sẽ hợp nhất các thành phần chính như được hiển thị trong các dòng sau:

2018-06-27  0:16:57 140203784476416 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 2, memb_num = 3
2018-06-27  0:16:57 140203784476416 [Note] WSREP: STATE EXCHANGE: Waiting for state UUID.
2018-06-27  0:16:57 140203784476416 [Note] WSREP: STATE EXCHANGE: sent state msg: 5885911b-795c-11e8-8683-931c85442c7e
2018-06-27  0:16:57 140203784476416 [Note] WSREP: STATE EXCHANGE: got state msg: 5885911b-795c-11e8-8683-931c85442c7e from 0 (192.168.55.171)
2018-06-27  0:16:57 140203784476416 [Note] WSREP: STATE EXCHANGE: got state msg: 5885911b-795c-11e8-8683-931c85442c7e from 1 (192.168.55.172)
2018-06-27  0:16:57 140203784476416 [Note] WSREP: STATE EXCHANGE: got state msg: 5885911b-795c-11e8-8683-931c85442c7e from 2 (192.168.55.173)
2018-06-27  0:16:57 140203784476416 [Warning] WSREP: Quorum: No node with complete state:

        Version      : 4
        Flags        : 0x3
        Protocols    : 0 / 8 / 3
        State        : NON-PRIMARY
        Desync count : 0
        Prim state   : SYNCED
        Prim UUID    : 5224a024-791b-11e8-a0ac-8bc6118b0f96
        Prim  seqno  : 5
        First seqno  : 112714
        Last  seqno  : 112725
        Prim JOINED  : 3
        State UUID   : 5885911b-795c-11e8-8683-931c85442c7e
        Group UUID   : 55238f52-41ee-11e8-852f-3316bdb654bc
        Name         : '192.168.55.171'
        Incoming addr: '192.168.55.171:3306'

        Version      : 4
        Flags        : 0x2
        Protocols    : 0 / 8 / 3
        State        : NON-PRIMARY
        Desync count : 0
        Prim state   : SYNCED
        Prim UUID    : 5224a024-791b-11e8-a0ac-8bc6118b0f96
        Prim  seqno  : 5
        First seqno  : 112714
        Last  seqno  : 112725
        Prim JOINED  : 3
        State UUID   : 5885911b-795c-11e8-8683-931c85442c7e
        Group UUID   : 55238f52-41ee-11e8-852f-3316bdb654bc
        Name         : '192.168.55.172'
        Incoming addr: '192.168.55.172:3306'

        Version      : 4
        Flags        : 0x2
        Protocols    : 0 / 8 / 3
        State        : NON-PRIMARY
        Desync count : 0
        Prim state   : SYNCED
        Prim UUID    : 5224a024-791b-11e8-a0ac-8bc6118b0f96
        Prim  seqno  : 5
        First seqno  : 112714
        Last  seqno  : 112725
        Prim JOINED  : 3
        State UUID   : 5885911b-795c-11e8-8683-931c85442c7e
        Group UUID   : 55238f52-41ee-11e8-852f-3316bdb654bc
        Name         : '192.168.55.173'
        Incoming addr: '192.168.55.173:3306'

2018-06-27  0:16:57 140203784476416 [Note] WSREP: Full re-merge of primary 5224a024-791b-11e8-a0ac-8bc6118b0f96 found: 3 of 3.
2018-06-27  0:16:57 140203784476416 [Note] WSREP: Quorum results:
        version    = 4,
        component  = PRIMARY,
        conf_id    = 5,
        members    = 3/3 (joined/total),
        act_id     = 112725,
        last_appl. = 112722,
        protocols  = 0/8/3 (gcs/repl/appl),
        group UUID = 55238f52-41ee-11e8-852f-3316bdb654bc
2018-06-27  0:16:57 140203784476416 [Note] WSREP: Flow-control interval: [28, 28]
2018-06-27  0:16:57 140203784476416 [Note] WSREP: Trying to continue unpaused monitor
2018-06-27  0:16:57 140203784476416 [Note] WSREP: Restored state OPEN -> SYNCED (112725)
2018-06-27  0:16:57 140202564110080 [Note] WSREP: New cluster view: global state: 55238f52-41ee-11e8-852f-3316bdb654bc:112725, view# 6: Primary, number of nodes: 3, my index: 2, protocol version 3

A good indicator to know if the re-bootstrapping process is OK is by looking at the following line in the error log:

[Note] WSREP: Synchronized with group, ready for connections

ClusterControl Auto Recovery

ClusterControl comes with node and cluster automatic recovery features, because it oversees and understands the state of all nodes in the cluster. Automatic recovery is by default enabled if the cluster is deployed using ClusterControl. To enable or disable the cluster, simply clicking on the power icon in the summary bar as shown below:

Green icon means automatic recovery is turned on, while red is the opposite. You can monitor the recovery progress from the Activity -> Jobs dialog, like in this case, galera2 was totally inaccessible due to firewall blocking, thus forcing ClusterControl to report the following:

The recovery process will only be commencing after a graceful timeout (30 seconds) to give Galera node a chance to recover itself beforehand. If ClusterControl fails to recover a node or cluster, it will first pull all MySQL error logs from all accessible nodes and will raise the necessary alarms to notify the user via email or by pushing critical events to the third-party integration modules like PagerDuty, VictorOps or Slack. Manual intervention is then required. For Galera Cluster, ClusterControl will keep on trying to recover the failure until you mark the node as under maintenance, or disable the automatic recovery feature.

ClusterControl's automatic recovery is one of most favorite features as voted by our users. It helps you to take the necessary actions quickly, with a complete report on what has been attempted and recommendation steps to troubleshoot further on the issue. For users with support subscriptions, you can look for extra hands by escalating this issue to our technical support team for assistance.

Kết luận

Galera automatic node recovery and membership control are neat features to simplify the cluster management, improve the database reliability and reduce the risk of human error, as commonly haunting other open-source database replication technology like MySQL Replication, Group Replication and PostgreSQL Streaming/Logical Replication.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Cách làm cho cơ sở dữ liệu MySQL hoặc MariaDB của bạn khả dụng cao trên AWS và Google Cloud

  2. MariaDB ROW_COUNT () được giải thích

  3. Cách trừ một ngày khỏi một ngày trong MariaDB

  4. Cách RADIANS () hoạt động trong MariaDB

  5. Đặt Bộ ký tự và đối chiếu của một cột trong MariaDB