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

Merge branch '2.3' into 2.4

Browse Source
This commit is contained in:
Esa Korhonen
2019-09-23 18:43:18 +03:00
parent 4d513941a7 74016322fd
commit 752dfbeaa8
2 changed files with 13 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
.gitignore vendored
View File

@ -37,12 +37,6 @@ depend.mk
.*.swp .*.swp
/build/ /build/
# Reviewboard configuration file
*.reviewboardrc
# Netbeans Project files
nbproject/
# CMake directories # CMake directories
build/ build/
CMakeFiles/* CMakeFiles/*
@ -58,6 +52,9 @@ Makefile
nbproject/ nbproject/
/build/ /build/
CLion project files
/.idea
# RBCommons # RBCommons
.reviewboardrc .reviewboardrc
# vscode # vscode

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

@ -329,6 +329,9 @@ server. See the section on `handle_server_events` for more information.
All cluster operations can be activated manually through MaxAdmin/MaxCtrl. See All cluster operations can be activated manually through MaxAdmin/MaxCtrl. See
section [Manual activation](#manual-activation) for more details. section [Manual activation](#manual-activation) for more details.
See [Limitations and requirements](#limitations-and-requirements) for
information on possible issues with failover and switchover.
### Operation details ### Operation 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
@ -552,8 +555,14 @@ Failover may lose events. If a master goes down before sending new events to at
least one slave, those events are lost when a new master is chosen. If the old least one slave, those events are lost when a new master is chosen. If the old
master comes back online, the other servers have likely moved on with a master comes back online, the other servers have likely moved on with a
diverging history and the old master can no longer join the replication cluster. diverging history and the old master can no longer join the replication cluster.
To minimize the chance for this happening, use To reduce the chance for this happening, use
[semisynchronous replication](https://mariadb.com/kb/en/library/semisynchronous-replication/). [semisynchronous replication](https://mariadb.com/kb/en/library/semisynchronous-replication/).
Even a controlled shutdown of the master may lose events. The server does not by
default wait for all data to be replicated to the slaves when shutting down and
instead simply closes all connections. When shutting down the master with the
intention of having a slave promoted, run *switchover* first to ensure that all
data is replicated. For more information on server shutdown, see
[Binary Log Dump Threads and the Shutdown Process](https://mariadb.com/kb/en/library/replication-threads/#binary-log-dump-threads-and-the-shutdown-process).
Switchover requires that the cluster is "frozen" for the duration of the Switchover requires that the cluster is "frozen" for the duration of the
operation. This means that no data modifying statements such as INSERT or UPDATE operation. This means that no data modifying statements such as INSERT or UPDATE