WSREP: Node consistency compromised, aborting

Mariadb Galera Cluster中的两个节点几乎同时宕机，检查日志发现如下错误

[Warning] WSREP: BF applier failed to open_and_lock_tables: 1146, fatal: 0 wsrep = (ex
ec_mode: 1 conflict_state: 0 seqno: 1080339)
[ERROR] Slave SQL: Error executing row event: 'Table 'db01.msg_order' doesn't exist', Internal MariaDB error code: 1146
[Warning] WSREP: RBR event 2 Write_rows_v1 apply warning: 1146, 1080339
[ERROR] WSREP: Failed to apply trx: source: ef13caac-5d6f-11e8-9d54-32f26fe8a706 version: 3 local: 0 state: APPLYING flags: 1 conn_id: 8 trx_id: 1106700 seqnos (l: 383, g: 1080339, s: 1080
338, d: 1080333, ts: 329789474547098)
**
[ERROR] WSREP: Failed to apply trx 1080339 4 times
[ERROR] WSREP: Node consistency compromised, aborting...
**

日志中先出现了1146错误，1146的含义是要访问的表不存在。
perror 1146
MySQL error code 1146 (ER_NO_SUCH_TABLE): Table ‘%-.192s.%-.192s’ doesn’t exist

接着日志中出现了Node consistency compromised, aborting，由此判断出是由于节点间数据不一致，导致的宕机。

出现上述情况后，修复方式很简单，只需要重启关闭的节点，做全量的SST即可。
由于是异常宕机grastate.dat中的seqno为-1，此时重启库只能做SST.

GALERA saved state

version: 2.1
uuid: 874d8e7e-5980-11e8-8c23-83493ba049c2
seqno: -1
safe_to_bootstrap: 0

尝试手工修改grastate.dat中的seqno，但没重启成功。

GALERA saved state

version: 2.1
uuid: 874d8e7e-5980-11e8-8c23-83493ba049c2
seqno: 1080333
safe_to_bootstrap: 0

出现如下错误：

[ERROR] WSREP: gcs/src/gcs_group.cpp:gcs_group_init_history():80: Non-negative state s
eqno requires non-nil history UUID.
**[ERROR] WSREP: gcs init failed:Invalid argument**
[ERROR] WSREP: wsrep::connect(gcomm://192.168.0.3:4567,192.168.0.2:4567,192.168.0.1:4567) failed: 7
[ERROR] Aborting

想想这种情况也是有道理的，即便是手工设置seqno重启成功了。由于这个节点中的数据与主节点已经处于不一致状态。即便是增量的IST也不会成功的（或者成功的几率很小）。所以Galera Cluster中节点数据不一致导致的全量SST也应该是可以接受的。线上尽量避免这种情况出现吧。