[MXS-503] Add support for replication sources Created: 2015-12-11  Updated: 2021-09-03  Resolved: 2021-09-03

Status: Closed
Project: MariaDB MaxScale
Component/s: mariadbmon
Affects Version/s: None
Fix Version/s: N/A

Type: New Feature Priority: Major
Reporter: markus makela Assignee: markus makela
Resolution: Won't Fix Votes: 1
Labels: None

Issue Links:
Relates
relates to MXS-3755 Handle multiple replication sources o... Closed

 Description   

Allowing the monitors to only monitor a specific replication source would allow proper use of multi-source replication with MaxScale. Right now it is not possible to define overlapping clusters due to the fact that SHOW ALL SLAVES STATUS is used instead of SHOW SLAVE STATUS for a specific source. SHOW ALL SLAVES STATUS will tell if all source are replicated but it is not always the desired outcome.

Setting default_master_connection at the start of the monitor's session would allow the monitor to only monitor one replication source. This would allow multiple monitors to monitor the same set of servers without actually monitoring the same replication stream.



 Comments   
Comment by markus makela [ 2018-03-26 ]

Needs to be thought of for 2.3, closing as Won't Fix.

Comment by Manjot Singh (Inactive) [ 2021-08-30 ]

If you have a primary/replica controlled by maxscale but the primary has multi-source incoming from many other primaries, you want a failover to restore all replication connections on internal failovers.

Comment by markus makela [ 2021-08-31 ]

Multi-source replication being restored on failover is not what this issue was originally about: it didn't exist at this point in time. I think one option would be to close this issue (like it originally was) and open more specific and up-to-date ones for things we want to be added.

Comment by markus makela [ 2021-09-03 ]

Closing this again since it's not relevant to the problem being discussed. I'll open another ticket (MXS-3755) for managing the multiple replication sources on failover.

Generated at Thu Feb 08 03:59:45 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.