[MXS-2649] Reason for mmmon removal Created: 2019-08-26 Updated: 2019-09-13 Resolved: 2019-09-09 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | Monitor |
| Affects Version/s: | 2.4.1 |
| Fix Version/s: | 2.4.2 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Anoop P Alias | Assignee: | Esa Korhonen |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
all |
||
| Sprint: | MXS-SPRINT-89, MXS-SPRINT-90 |
| Description |
|
I have been using mmmon successfully in a production environment with mariadb master master replication and found that the monitor has been removed in the latest version Was there any design issues that led to the removal? , because on a practical use case this monitor was very good and quiet easy to use |
| Comments |
| Comment by Esa Korhonen [ 2019-08-27 ] |
|
The removal of mmmon was mostly about removing a duplicated feature and code. The multimaster-monitor hadn't been updated for quite some time and its use-case was very limited. It basically assigns the master and slave roles by just looking at the read_only-flag instead of properly checking who is replicating from who. It also seems as if the monitor could assign multiple masters, which is somewhat misleading as e.g. readwritesplit will only use one master. Please try the MariaDB-Monitor. It should handle quite a variety of topologies and is far more tested. |
| Comment by Anoop P Alias [ 2019-08-27 ] |
|
Does MariaDB-Monitor work fine with a Master-Master replication topology, there is no mention of that in the doc and the doc mostly say (perhaps I am understanding it wrong) MariaDB-Monitor is for a typical Master-Slave topology? |
| Comment by Esa Korhonen [ 2019-08-29 ] |
|
The master selection logic of MariaDB-Monitor is explained in https://mariadb.com/kb/en/mariadb-maxscale-24-mariadb-monitor/#master-selection In practice this should be how it worked before, since if ReadWriteSplit detects multiple masters it will stick to one of them. |