Linux
在健康集群上帶有 seqno -1 的 grastate.dat。為什麼？
我們使用這些版本：
# rpm -qa | egrep '(galera|maria)' mariadb-libs-5.5.41-2.el7_0.x86_64 mariadb-galera-common-5.5.40-6.el7ost.x86_64 mariadb-galera-server-5.5.40-6.el7ost.x86_64 mariadb-5.5.41-2.el7_0.x86_64 galera-25.3.5-6.el7ost.x86_64那是我們的 grastate.dat
# cat /var/lib/mysql/data/grastate.dat # GALERA saved state version: 2.1 uuid: e7ead849-f2a3-11e4-bfda-7f651f709ee3 seqno: -1 cert_index:
seqno: -1看起來很腥。在其他集群上有一個數字。我不知道為什麼。根據文件，這似乎“崩潰了”。-1 是在中斷之後。但是這個集群是健康的。修改時間很久了
# stat /var/lib/mysql/data/grastate.dat File: â/var/lib/mysql/data/grastate.datâ Size: 104 Blocks: 8 IO Block: 4096 regular file Device: fd09h/64777d Inode: 108 Links: 1 Access: (0660/-rw-rw----) Uid: ( 1000/ mysql) Gid: ( 1000/ mysql) Context: system_u:object_r:mysqld_db_t:s0 Access: 2015-07-29 14:51:25.170699518 +0200 Modify: 2015-06-02 11:50:21.564360655 +0200 Change: 2015-06-02 11:50:21.564360655 +0200 Birth: -從日誌（沒有錯誤只有資訊和警告）：
150504 23:24:11 [Note] WSREP: gcomm: connected 150504 23:24:11 [Note] WSREP: Changing maximum packet size to 64500, resulting msg size: 32636 150504 23:24:11 [Note] WSREP: Shifting CLOSED -> OPEN (TO: 0) 150504 23:24:11 [Note] WSREP: Opened channel 'galera_cluster' 150504 23:24:11 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 0, memb_num = 1 150504 23:24:11 [Note] WSREP: Waiting for SST to complete. 150504 23:24:11 [Note] WSREP: Starting new group from scratch: e7ead849-f2a3-11e4-bfda-7f651f709ee3 150504 23:24:11 [Note] WSREP: STATE_EXCHANGE: sent state UUID: e7eae37d-f2a3-11e4-a76e-6e8297197928 150504 23:24:11 [Note] WSREP: STATE EXCHANGE: sent state msg: e7eae37d-f2a3-11e4-a76e-6e8297197928 150504 23:24:11 [Note] WSREP: STATE EXCHANGE: got state msg: e7eae37d-f2a3-11e4-a76e-6e8297197928 from 0 (hostname.domain) 150504 23:24:11 [Note] WSREP: Quorum results: version = 3, component = PRIMARY, conf_id = 0, members = 1/1 (joined/total), act_id = 0, last_appl. = -1, protocols = 0/5/3 (gcs/repl/appl), group UUID = e7ead849-f2a3-11e4-bfda-7f651f709ee3 150504 23:24:11 [Note] WSREP: Flow-control interval: [16, 16] 150504 23:24:11 [Note] WSREP: Restored state OPEN -> JOINED (0) 150504 23:24:11 [Note] WSREP: Member 0.0 (hostname.domain) synced with group. 150504 23:24:11 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 0) 150504 23:24:11 [Note] WSREP: New cluster view: global state: e7ead849-f2a3-11e4-bfda-7f651f709ee3:0, view# 1: Primary, number of nodes: 1, my index: 0, protocol version 3 150504 23:24:11 [Note] WSREP: SST complete, seqno: 0 150504 23:24:11 InnoDB: The InnoDB memory heap is disabled 150504 23:24:11 InnoDB: Mutexes and rw_locks use GCC atomic builtins 150504 23:24:11 InnoDB: Compressed tables use zlib 1.2.7 150504 23:24:11 InnoDB: Using Linux native AIO狀態
> SHOW STATUS LIKE 'wsrep%'; +------------------------------+----------------------------------------------------------+ | Variable_name | Value | +------------------------------+----------------------------------------------------------+ | wsrep_local_state_uuid | e7ead849-f2a3-11e4-bfda-7f651f709ee3 | | wsrep_protocol_version | 5 | | wsrep_last_committed | 15995162 | | wsrep_replicated | 15995162 | | wsrep_replicated_bytes | 7552231516 | | wsrep_repl_keys | 73658848 | | wsrep_repl_keys_bytes | 957160108 | | wsrep_repl_data_bytes | 5571381040 | | wsrep_repl_other_bytes | 0 | | wsrep_received | 127686 | | wsrep_received_bytes | 1023418 | | wsrep_local_commits | 15994368 | | wsrep_local_cert_failures | 8 | | wsrep_local_replays | 0 | | wsrep_local_send_queue | 0 | | wsrep_local_send_queue_avg | 0.000063 | | wsrep_local_recv_queue | 0 | | wsrep_local_recv_queue_avg | 0.002921 | | wsrep_local_cached_downto | 15719139 | | wsrep_flow_control_paused_ns | 0 | | wsrep_flow_control_paused | 0.000000 | | wsrep_flow_control_sent | 0 | | wsrep_flow_control_recv | 0 | | wsrep_cert_deps_distance | 1.046783 | | wsrep_apply_oooe | 0.008655 | | wsrep_apply_oool | 0.000000 | | wsrep_apply_window | 1.009090 | | wsrep_commit_oooe | 0.000000 | | wsrep_commit_oool | 0.000000 | | wsrep_commit_window | 1.000440 | | wsrep_local_state | 4 | | wsrep_local_state_comment | Synced | | wsrep_cert_index_size | 57 | | wsrep_causal_reads | 0 | | wsrep_cert_interval | 0.011088 | | wsrep_incoming_addresses | 192.168.221.22:3306,192.168.211.20:3306,192.168.210.21:3306 | | wsrep_cluster_conf_id | 6 | | wsrep_cluster_size | 3 | | wsrep_cluster_state_uuid | e7ead849-f2a3-11e4-bfda-7f651f709ee3 | | wsrep_cluster_status | Primary | | wsrep_connected | ON | | wsrep_local_bf_aborts | 0 | | wsrep_local_index | 1 | | wsrep_provider_name | Galera | | wsrep_provider_vendor | Codership Oy <info@codership.com> | | wsrep_provider_version | 3.5(rXXXX) | | wsrep_ready | ON | | wsrep_thread_count | 2 | +------------------------------+----------------------------------------------------------+ 48 rows in set (0.00 sec)
序列號為 -1 的A
grastate.dat在正在執行的節點上很好。當集群完全停止時，序列號將在每個節點上設置為一個值。然後，您必須從具有最高級 seqno 的節點引導集群。
第二個使用此 連結，當節點無序斷開連接時發生錯誤，如在我的集群中，我的主節點不再連接。mysql的錯誤：
$$ ERROR $$WSREP：從該節點引導集群可能不安全。它不是離開集群的最後一個，並且可能不包含所有更新。要使用此節點強制集群引導，請手動編輯 grastate.dat 文件並將 safe_to_bootstrap 設置為 1 。
所以我決定改變
/var/lib/mysql/grastate.dat安全到引導：1