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

MXS-1980 Update documentation

Browse Source 
And release note and change log.
This commit is contained in:
Johan Wikman
2018-10-05 10:26:43 +03:00
parent 3d06b5129d
commit 59d45aabb4
3 changed files with 30 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
Documentation/Changelog.md
View File

@ -22,6 +22,9 @@
* Support for runtime router reconfiguration * Support for runtime router reconfiguration
* Experimental resultset concatenation router, `cat` * Experimental resultset concatenation router, `cat`
* The schema router is now capable of table family sharding. * The schema router is now capable of table family sharding.
* The binlog router can now automatically switch to secondary masters
when replicating from a Galera cluster in case the primary master
goes down.
For more details, please refer to: For more details, please refer to:

9
Documentation/Release-Notes/MaxScale-2.3.0-Release-Notes.md
View File

@ -161,6 +161,15 @@ API that provides the same information in a more easy to process format.
## New Features ## New Features
### Binlog Router
If the binlog router is replicating from a Galera cluster it is now
possible to specify secondary masters that the binlog router automatically
will switch to, in case the primary master for some reason goes down.
Please see the binlog router
[documentation](../Routers/Binlogrouter.md)
for details.
### Hints ### Hints
There is now a new hint `last` that will cause a query to be routed to the There is now a new hint `last` that will cause a query to be routed to the

20
Documentation/Routers/Binlogrouter.md
View File

@ -382,8 +382,10 @@ the binlog router can use in case the connection to the default master fails.
**Note:** This is _only_ supported for gtid based replication in conjunction **Note:** This is _only_ supported for gtid based replication in conjunction
with a Galera cluster and provided the following holds: with a Galera cluster and provided the following holds:
* `@@log_slave_updates` is enabled on all servers, and * `@@log_slave_updates` is enabled on all servers,
* all nodes in the Galera cluster have the *same* `server_id`. * 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`).
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.
``` ```
@ -436,6 +438,20 @@ Once the binlog router has successfully connected to a server, it will stay
connected to that server until the connection breaks or `STOP SLAVE` is connected to that server until the connection breaks or `STOP SLAVE` is
issued. issued.
The configurations of the secondary masters are also stored to the
`master.ini` in sections whose name include the connection name.
```
[binlog_configuration]
master_host=192.168.121.150
...
[binlog_configuration:2]
master_host=192.168.121.148
...
[binlog_configuration:3]
master_host=192.168.121.76
...
```
## Examples ## Examples
The [Replication Proxy](../Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md) tutorial will The [Replication Proxy](../Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md) tutorial will