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

MXS-1845 Update documentation

Browse Source 
Small cleanup and updates to release notes.
This commit is contained in:
Esa Korhonen
2018-10-03 11:10:14 +03:00
parent 30eb21914f
commit e73ecae677
2 changed files with 22 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
Documentation/Monitors/MariaDB-Monitor.md
View File

@ -247,20 +247,26 @@ section [Manual activation](#manual-activation) for more details.
**Failover** replaces a failed master with a running slave. It does the **Failover** replaces a failed master with a running slave. It does the
following: following:
1. Select the most up-to-date slave of the old master to be the new master. If 1. Select the most up-to-date slave of the old master to be the new master. The
the new master has unprocessed relay log items, cancel and try again later. selection criteria is as follows in descending priority:
2. Prepare the new master: 1. gtid_IO_pos (latest event in relay log)
2. gtid_current_pos (most processed events)
3. log_slave_updates is on
4. disk space is not low
2. If the new master has unprocessed relay log items, cancel and try again
later.
3. Prepare the new master:
1. Remove the slave connection the new master used to replicate from the old 1. Remove the slave connection the new master used to replicate from the old
master. master.
2. Disable the *read\_only*-flag. 2. Disable the *read\_only*-flag.
3. Enable scheduled server events (if event handling is on). 3. Enable scheduled server events (if event handling is on).
4. Run the commands in `promotion_sql_file`. 4. Run the commands in `promotion_sql_file`.
5. Start replication from external master is one existed. 5. Start replication from external master is one existed.
3. Redirect all other slaves to replicate from the new master: 4. Redirect all other slaves to replicate from the new master:
1. STOP SLAVE and RESET SLAVE 1. STOP SLAVE and RESET SLAVE
2. CHANGE MASTER TO 2. CHANGE MASTER TO
3. START SLAVE 3. START SLAVE
4. Check that all slaves are replicating. 5. Check that all slaves are replicating.
Failover may lose events if no slave managed to replicate the events before the Failover may lose events if no slave managed to replicate the events before the
master went down. master went down.
@ -272,11 +278,10 @@ following:
1. Stop any external replication. 1. Stop any external replication.
2. Enable the *read\_only*-flag to stop writes. 2. Enable the *read\_only*-flag to stop writes.
3. Disable scheduled server events (if event handling is on). 3. Disable scheduled server events (if event handling is on).
4. Flush the binary log (FLUSH LOGS) so that all events are on disk. 4. Run the commands in `demotion_sql_file`.
5. Run the commands in `demotion_sql_file`. 5. Flush the binary log (FLUSH LOGS) so that all events are on disk.
2. Wait for all slaves to catch up with the old master by repeatedly querying 2. Wait for the new master to catch up with the old master.
their gtid:s. 3. Promote new master and redirect slaves as in failover steps 3 and 4. Also
3. Promote new master and redirect slaves as in failover steps 2 and 3. Also
redirect the demoted old master. redirect the demoted old master.
4. Check that all slaves are replicating. 4. Check that all slaves are replicating.

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

@ -110,7 +110,13 @@ connections, the smallest lag is used.
With recent MariaDB Server versions, the monitor can check the disk space on the With recent MariaDB Server versions, the monitor can check the disk space on the
backends and detect if the server is running low. The monitor can be set to backends and detect if the server is running low. The monitor can be set to
automatically switchover a master low on disk space. Slaves are instead set to automatically switchover a master low on disk space. Slaves are instead set to
maintenance mode. maintenance mode. Disk space is also considered when selecting a new master for
promotion.
#### Replication reset feature
The *reset-replication* monitor command deletes all slave connections and binary
logs, and then sets up replication. Useful when data is in sync but gtid:s are not.
#### Unused parameters #### Unused parameters