grastate.dat mit seqno -1 auf einem fehlerfreien Cluster.Warum?
https://dba.stackexchange.com/questions/108437
-
28-09-2020 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Wir verwenden diese Versionen:
# 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
Das ist unser 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:
Der seqno: -1 sieht faul aus.Auf anderen Clustern gibt es eine Nummer.Ich weiß nicht warum.Den Dokumenten zufolge scheint dies „abgestürzt“ zu sein.Die -1 steht nach einem Ausfall.Aber dieser Cluster ist gesund.
Die Änderungszeit ist lange her
# 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: -
aus Protokollen (keine Fehler, nur Informationen und Warnungen):
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 <info@codership.com> |
| wsrep_provider_version | 3.5(rXXXX) |
| wsrep_ready | ON |
| wsrep_thread_count | 2 |
+------------------------------+----------------------------------------------------------+
48 rows in set (0.00 sec)
Lösung
A grastate.dat mit einer Sequenznummer von -1 ist auf einem laufenden Knoten in Ordnung.
Wenn der Cluster sauber stoppt, wird die Sequenznummer auf jedem Knoten auf einen Wert gesetzt.Anschließend müssen Sie den Cluster von dem Knoten aus booten, der über die fortschrittlichste Sequenznummer verfügt.
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit dba.stackexchange
