Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
2.3.6
-
None
Description
The following documentation section appears to be incomplete:
Using secondary masters
From MaxScale 2.3 onwards it is possible to specify secondary masters that the binlog router can use in case the connection to the default master fails.
Note: This is only supported in conjunction with a Galera cluster and provided the following holds: @@log_slave_updates is enabled on all servers, all nodes in the Galera cluster have the same server_id, and all nodes in the Galera cluster use the same* basename for the binlog files (specified in the server config file with log_bin=basename).
https://mariadb.com/kb/en/mariadb-maxscale-23-binlogrouter/#using-secondary-masters
This section does not mention:
- That wsrep_gtid_mode=ON needs to be set on all nodes.
- That wsrep_gtid_domain_id needs to be set to the same value on all nodes.
- And even if all of these are set properly, wsrep_gtid_mode is imperfect, and GTIDs can get out of sync within a cluster.
I think the section should read more like this:
Using secondary masters
From MaxScale 2.3 onwards it is possible to specify secondary masters that the binlog router can use in case the connection to the default master fails.
Note: This is only supported in a Galera Cluster environment in which:
- Wsrep GTID mode is enabled in the cluster.
- All of the requirements for wsrep GTID mode are met by the cluster.
- Wsrep GTID mode is also imperfect, so this secondary master functionality is only guaranteed to work if GTIDs have not become inconsistent within the cluster.
- See here for more information: https://mariadb.com/kb/en/library/using-mariadb-gtids-with-mariadb-galera-cluster/#wsrep-gtid-mode
Attachments
Issue Links
- relates to
-
MXS-1980 Support Galera cluster nodes as masters for Binlog Router
- Closed