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

MXS-1484: set binlog storage to TREE mode

Browse Source 
When mariadb10_master_gtid is on the storage of binlog file is
automatically set to TREE mode.
This commit is contained in:
MassimilianoPinto
2017-10-23 11:25:19 +02:00
parent 37c804e0d3
commit 65dc9e0d30
3 changed files with 14 additions and 80 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
Documentation/Routers/Binlogrouter.md
View File

@ -336,22 +336,6 @@ in the binlog files with ignorable events.
- It's not possible to specify the GTID _domain_id: the master one
is being used for all operations. All slave servers must use the same replication domain as the master server.
### `binlog_structure`
This option controls the way binlog file are saved in the _binlogdir_:
there are two possible values, `flat | tree`
The `tree` mode can only be set with `mariadb10_master_gtid=On`
- `flat` is the default value, files are saved as usual.
- `tree` enables the saving of files using this hierarchy model:
_binlogdir_/_domain_id_/_server_id_/_filename_
The _tree_ structure easily allows the changing of the master server
without caring about binlog filename and sequence:
just change _host_ and _port_, the replication will
resume from last GTID MaxScale has seen.
### `master_retry_count`
This option sets the maximum number of connection retries when the master server is disconnected or not reachable.
@ -392,7 +376,6 @@ follows.
encryption_key_file=/var/binlogs/enc_key.txt,
mariadb10_slave_gtid=On,
mariadb10_master_gtid=Off,
binlog_structure=flat,
slave_hostname=maxscale-blr-1,
master_retry_count=1000,
connect_retry=60

45
Documentation/Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md
View File

@ -68,7 +68,6 @@ A **complete example** of a service entry for a binlog router service would be a
encryption_key_file=/var/binlogs/enc_key.txt,
mariadb10_slave_gtid=On,
mariadb10_master_gtid=Off,
binlog_structure=flat,
slave_hostname=maxscale-blr-1,
master_retry_count=1000,
connect_retry=60
@ -285,7 +284,7 @@ The default is that a slave connection must not include any GTID
feature: `MASTER_USE_GTID=no`
Starting from MaxScale 2.2 it's also possible to register to MariaDB 10.X master using
**GTID** using the two new options *mariadb10_master_gtid* and *binlog_structure*.
**GTID** using the new option *mariadb10_master_gtid*.
Current GTID implementation limitations:
@ -458,19 +457,12 @@ error logs and in *SHOW SLAVE STATUS*,
##### MariaDB 10 GTID
If _mariadb10_master_gtid_ is On changing the master doesn't require the setting of a
new _file_ and _pos_, just specify new host and port with CHANGE MASTER; depending on the _binlog_structure_ values some additional steps might be required.
new _file_ and _pos_, just specify new host and port with CHANGE MASTER.
If _binlog_structure=flat_, in order to keep previous binlog files untouched in MaxScale _binlogdir_ (no overwriting),
the next in sequence file must exist in the Master server, as per above scenario _file and pos_ (2).
It might also happen that each server in the replication setup has its own binlog file name
convention (server1_bin, server2_bin etc) or the user doesn't want to care at all about
name and sequence. The _binlog_structure_ option set to _tree_ value simplifies the change
master process: as the binlog files are saved using a hierarchy model
As the binlog files will be automatically saved using a hierarchy model
(_binlogdir/domain_id/server_id/_filename_), MaxScale can work with any filename and any
sequence and no binlog file will be overwritten by accident.
**Scenario** example:
Let's start saying it's a good practice to issue in the new Master `FLUSH TABLES` which
@ -508,38 +500,17 @@ MariaDB> SELECT @@global.gtid_current_pos;
```
Starting the replication in MaxScale, `START SLAVE`,
will result in new events being downloaded and stored.
If _binlog_structure=flat_ (default), the binlog events are saved in the new file
`mysql-bin.000061`, which should have been created in the Master before starting
replication from MaxScale, see above scenario (2)
If _binlog_structure=tree_, the binlog events are saved in the new file
`0/10333/mysql-bin.000001` (which is the current file in the new master)
The latter example clearly shows that the binlog file has a different sequence number
(1 instead of 61) and possibly a new name.
will result in new events being downloaded and stored in the new file
`0/10333/mysql-bin.000001` (which should be the current file in the new master)
As usual, check for any error in log files and with
MariaDB> SHOW SLAVE STATUS;
Issuing the admin command `SHOW BINARY LOGS` it's possible to see the list
of log files which have been downloaded:
```
MariaDB> SHOW BINARY LOGS;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000113 | 2214 |
...
| mysql-bin.000117 | 535 |
+------------------+-----------+
```
It's possible to follow the _master change_ history if option `binlog_structure=tree`:
the displayed log file names have a prefix with replication domain_id and server_id.
of log files which have been downloaded and to follow the _master change_
history: the displayed log file names have a prefix with
replication domain_id and server_id.
```
MariaDB> SHOW BINARY LOGS;