Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Not a Bug
-
2.2.3
-
None
-
Two physical nodes running CentOS 7 and MariaDB 10.2.6 with Galera 25.3.20-1
One virtual node running garbd (25.3.22-1)
rsync as sst_method is used.
2 physical nodes running Centos 7, with Maxscale 2.2.3.
one of the maxscales are using the readconn (for a wp-installation)
router_options=Synced (later changed to Running)
the other maxscale uses the rwspliter (for an Escenic installation)
router_options=disable_sescmd_history=true,master_accept_reads=true
Two physical nodes running CentOS 7 and MariaDB 10.2.6 with Galera 25.3.20-1 One virtual node running garbd (25.3.22-1) rsync as sst_method is used. 2 physical nodes running Centos 7, with Maxscale 2.2.3. one of the maxscales are using the readconn (for a wp-installation) router_options=Synced (later changed to Running) the other maxscale uses the rwspliter (for an Escenic installation) router_options=disable_sescmd_history=true,master_accept_reads=true
Description
First of all, this is not really a bug, more like strange behaviour.
I talked to Markusjm on irc and he asked me to write this.
So here we go:
We had a failure of one of the nodes.
When it started to do its sst, the remaining node when into donor status, hence making the maxscales think that it does not have any server available, effectively stopping both applications.
Galera never lost majority with the remaning node + arbiter.
We changed on one maxscale that was running the readconn to router_options=Running just to make wordpress run again. (Kinda expected, since the monitor status was not 'Synced' since that is what the config initially said)
On the maxscale running rwsplit, we did stop the monitor, and did a 'set server master' to enable it to run both as donor and master at the same time, so we could serve applications and sst-sync at the same time.
I hope it made some sense, please let me know if you need additional information, happy to help out.