Can I upgrade my slave from 5.6 to 5.7 and connect more masters to it?
When upgrading so that the master version is lower/earlier than the slave version there is always a large risk it will not work. This is because newer versions may have made incompatible changes that means the older version will not be able to process or understand that change in the newer version.
However, there is always a chance that it will work, but it is always recommended that if you want to go this way, attempt it on a test setup first before implementing it in production.
Does multi-source replication require the use of GTIDs?
No, but it is important to make sure that GTIDs are either enable on all servers in the replication process or none of them. You cannot have some using GTIDs and some not using the GTID feature.
What situations would warrant the use of a multi-source replication setup?
There are a number of use cases which involve consolidating data from multiple servers down into one:
- Reduce sharded servers down to a single reporting server to give consolidated reports and viewing
- Similar to the single reporting server, but in this use case it would be a single backup server
- Consolidate remote servers through a single server for geo-replication and/or data transfers
How does multi-source replication deal with conflict resolution?
With multiple masters all replicating down to a single server, there is bound to conflict at some point. The way multi-source replication deals with this at the moment is to leave the responsibility with the application developers. The way the application enforces safety and avoids conflict is to make sure the masters are always working on distinct data sets. Even with this scenario, the application should detect any exceptions and handle accordingly so the service doesn’t fail.
Will multi-source replication be backported to previous versions such as 5.5 or 5.1?
The short answer is – no! It is a new feature that requires new code which is only available from 5.7 onwards.
The concept is simple, but how do I manage all the different masters connecting to the slave?
The 5.7 version has introduced new syntax to manage the changes added with multi-source replication. These additions are predominantly the “FOR CHANNEL” and “ALL CHANNELS” clauses to the existing commands such as:
- CHANGE MASTER TO …
- STOP/START SLAVE …
- FLUSH RELAY LOGS …
Can I use multi-threaded slaves in a multi-source replication setup?
Yes, there is the capability to use multi-threaded slaves as the receiving server for multi-source replication. However, it should be pointed out that there two different ways this can be implemented – database partitioning or parent commit sequencing. These are beyond the scope of this document, but you can get further information from the knowledge base and/or online.
Can multi-threaded replication be used with semi-synchronous replication?
Similar to GTIDs, the answer here is yes, if the semi-synchronous feature is running across all servers in the replication setup. You cannot only have a partial implementation of semi-synchronous servers in the multi-source replication setup.
How do the replication filters apply now that there are multiple channels?
The replication filters are applied globally across all the channels. There is currently no option for per-channel filters to be used.
How many masters can I replicate to a single slave?
That is the proverbial “how long is a piece of string” question! Essentially there is no implemented limit in the server as to how many masters can replicate to a slave, that is, how many channels can be defined for replication. The important point here is that you consider your capacity planning and understand that have 20 servers replicating to a single, identical setup for the slave, even with multi-threading, is probably going to cause a performance issue.
Multi-source replication is still very new, is there any part that will change in any way?
The most obvious areas for change are the replication filters be implemented per channel, and possibly limiting the number of channels/masters that can be replicated to one slave.
Can multi-source replication handle database name conflict among channel?
The answer would be NO, but in MySQL 8.0, it can be implemented as –replicate-rewrite-db:channel_1:(db_name1->db_name2)
Also, replication filter by channel has been developed at 8.0 – https://dev.mysql.com/doc/refman/8.0/en/replication-options-slave.html