hcq/MaxScale
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

MXS-2472 Update BLR docs on secondary masters

Browse Source
This commit is contained in:
Johan Wikman
2019-05-09 15:32:13 +03:00
parent 3c5a932010
commit 034dc6a67e
1 changed files with 11 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
Documentation/Routers/Binlogrouter.md
View File

@ -416,12 +416,17 @@ encryption_key_file=/var/binlogs/enc_key.txt
From MaxScale 2.3 onwards it is possible to specify secondary masters that 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. 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 **Note:** This is _only_ supported in a Galera Cluster environment in which:
provided the following holds:
* `@@log_slave_updates` is enabled on all servers, * _Wsrep GTID mode_ is enabled in the cluster.
* all nodes in the Galera cluster have the *same* `server_id`, and * _All_ of the requirements for wsrep GTID mode are met by the cluster.
* all nodes in the Galera cluster use the *same* basename for the
binlog files (specified in the server config file with `log_bin=basename`). _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
[Wsrep GTID Mode](https://mariadb.com/kb/en/library/using-mariadb-gtids-with-mariadb-galera-cluster/#wsrep-gtid-mode)
for more information.
The initial setup is performed exactly like when there is but one default master. The initial setup is performed exactly like when there is but one default master.
``` ```