We use on RHEL7
# rpm -qa | grep maria
mariadb-5.5.41-2.el7_0.x86_64
mariadb-galera-common-5.5.41-2.el7ost.x86_64
mariadb-galera-server-5.5.41-2.el7ost.x86_64
Do I analyze logs correct that Galera crashed because of an ALTER TABLE statement?
I found a few forum posts that ALTER TABLE crashes Galera
151019 1:07:09 [Note] WSREP: Restored state OPEN -> SYNCED (5678)
151019 1:07:09 [Note] WSREP: New cluster view: global state: 846a887d-5613-11e5-802f-53450430e144:5678, view# 15: Primary, number of nodes: 3, my index: 2, protocol version 3
151019 1:07:09 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
151019 1:07:09 [Note] WSREP: REPL Protocols: 5 (3, 1)
151019 1:07:09 [Note] WSREP: Service thread queue flushed.
151019 1:07:09 [Note] WSREP: Assign initial position for certification: 5678, protocol version: 3
151019 1:07:09 [Note] WSREP: Service thread queue flushed.
151019 1:07:09 [Warning] WSREP: Releasing seqno 5678 before 5679 was assigned.
151019 1:07:09 [Note] WSREP: Synchronized with group, ready for connections
151019 1:07:09 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
151019 12:05:01 [Note] WSREP: Provider paused at 846a887d-5613-11e5-802f-53450430e144:5702 (5883)
151019 12:05:01 [Note] WSREP: resuming provider at 5883
151019 12:05:01 [Note] WSREP: Provider resumed.
151019 14:39:10 InnoDB: Error: in ALTER TABLE `EXAMPLE_DB`.`example_table`
InnoDB: has or is referenced in foreign key constraints
InnoDB: which are not compatible with the new table definition.
151019 15:10:13 InnoDB: Error: in ALTER TABLE `EXAMPLE_DB`.`example_table`
InnoDB: has or is referenced in foreign key constraints
InnoDB: which are not compatible with the new table definition.
151020 0:05:01 [Note] WSREP: Provider paused at 846a887d-5613-11e5-802f-53450430e144:17391 (17675)
151020 0:05:01 [Note] WSREP: resuming provider at 17675
151020 0:05:01 [Note] WSREP: Provider resumed.
151020 12:05:01 [Note] WSREP: Provider paused at 846a887d-5613-11e5-802f-53450430e144:17396 (17681)
151020 12:05:01 [Note] WSREP: resuming provider at 17681
151020 12:05:01 [Note] WSREP: Provider resumed.
151021 0:05:01 [Note] WSREP: Provider paused at 846a887d-5613-11e5-802f-53450430e144:17407 (17693)
151021 0:05:01 [Note] WSREP: resuming provider at 17693
151021 0:05:01 [Note] WSREP: Provider resumed.
151021 12:05:01 [Note] WSREP: Provider paused at 846a887d-5613-11e5-802f-53450430e144:17431 (17718)
151021 12:05:01 [Note] WSREP: resuming provider at 17718
151021 12:05:01 [Note] WSREP: Provider resumed.
151021 16:35:53 [Note] WSREP: declaring 78a2ff94-5614-11e5-866e-5efcfcd895ce stable
151021 16:35:53 [Note] WSREP: (846a2093-5613-11e5-be75-b693a6ef3794, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://10.0.20.42:4567
151021 16:35:53 [Note] WSREP: Node 78a2ff94-5614-11e5-866e-5efcfcd895ce state prim
151021 16:35:53 [Note] WSREP: view(view_id(NON_PRIM,78a2ff94-5614-11e5-866e-5efcfcd895ce,39) memb {
846a2093-5613-11e5-be75-b693a6ef3794,0
} joined {
} left {
} partitioned {
78a2ff94-5614-11e5-866e-5efcfcd895ce,0
7b8466ae-5614-11e5-b288-6e62756b3770,0
})
151021 16:35:53 [Note] WSREP: view(view_id(NON_PRIM,846a2093-5613-11e5-be75-b693a6ef3794,40) memb {
846a2093-5613-11e5-be75-b693a6ef3794,0
} joined {
} left {
} partitioned {
78a2ff94-5614-11e5-866e-5efcfcd895ce,0
7b8466ae-5614-11e5-b288-6e62756b3770,0
})
151021 16:35:53 [Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 0, memb_num = 1
151021 16:35:53 [Note] WSREP: Flow-control interval: [16, 16]
151021 16:35:53 [Note] WSREP: Received NON-PRIMARY.
151021 16:35:53 [Note] WSREP: Shifting SYNCED -> OPEN (TO: 17485)
151021 16:35:53 [Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 0, memb_num = 1
151021 16:35:53 [Note] WSREP: Flow-control interval: [16, 16]
151021 16:35:53 [Note] WSREP: Received NON-PRIMARY.
151021 16:35:53 [Note] WSREP: New cluster view: global state: 846a887d-5613-11e5-802f-53450430e144:17485, view# -1: non-Primary, number of nodes: 1, my index: 0, protocol version 3
151021 16:35:53 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
151021 16:35:53 [Note] WSREP: New cluster view: global state: 846a887d-5613-11e5-802f-53450430e144:17485, view# -1: non-Primary, number of nodes: 1, my index: 0, protocol version 3
151021 16:35:53 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
151021 16:35:54 [Note] WSREP: (846a2093-5613-11e5-be75-b693a6ef3794, 'tcp://0.0.0.0:4567') reconnecting to 7b8466ae-5614-11e5-b288-6e62756b3770 (tcp://10.0.20.42:4567), attempt 0
151021 16:35:54 [Note] WSREP: (846a2093-5613-11e5-be75-b693a6ef3794, 'tcp://0.0.0.0:4567') reconnecting to 78a2ff94-5614-11e5-866e-5efcfcd895ce (tcp://10.0.20.43:4567), attempt 0
We offer Galera Cluster for DBaaS. Is there a way to limit statements?
Disallow https://mariadb.com/kb/en/mariadb/mariadb-galera-cluster-known-limitations
Writes go to the primary only. There is no multi master writes!