5

We use those versions:

# 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 

that's our 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: 

The seqno: -1 looks fishy. On other clusters there is a number. I don't know why. According to docs this seems "crashed". The -1 is after outage. But this cluster is healthy.

modify time is long ago

# 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: - 

from logs (no errors only info and warnings):

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 

status

> 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 <[email protected]> | | wsrep_provider_version | 3.5(rXXXX) | | wsrep_ready | ON | | wsrep_thread_count | 2 | +------------------------------+----------------------------------------------------------+ 48 rows in set (0.00 sec) 
0

2 Answers 2

4

A grastate.dat with a sequence number of -1 is fine on a running node.

When the cluster stops cleanly, the sequence number will be set to a value on each node. You'll then have to bootstrap the cluster from the node which has the most advanced seqno.

0

second with this link, an error occurred when the nodes were disconnected without order, as in my cluster, my main node is not connecting anymore. erro of mysql:

[ERROR] WSREP: It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster and may not contain all the updates. To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .

so I decided to change /var/lib/mysql/grastate.dat

safe_to_bootstrap: 1

0

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.