mysql multi-source replication to single slave from Debian repo's?
You shouldn't have to upgrade the master servers until you want to.

Officially, replication requires that the slave server be the same version as the master or newer.  That might seem counterintuitive, but derives from the fact that the replication protocol is always forward-extensible, but not always backward-compatible.  New capabilities can be added to the replication format, and when this happens, it only adds to what the master might write, but it adds to what the slave must be able to interpret.

As a rule, newer slaves know all the tricks an older master can do.  In contrast, newer masters can blow the mind of an older slave, by doing things the older slave won't recognize.

Because of the way replication is designed, the slave can actually learn the version of a master, but the master has essentially no way to learn the same information about a slave... nor is this needed, because the master only has one binlog, and all connected slaves receive exactly the same event stream.

Officially, replication is supported with a gap of one major release... the slave running 5.5 with a master running 5.1 (GA skipped from 5.1 to 5.5, so that's "one.") or the slave running 5.6 and master running 5.5, etc.

Unofficially, from 5.1 onward, you can generally make it work with any gap in the releases, as long as the slave is always newer, and you don't enable slave features the master doesn't implement, where the feature requires both servers to have the same configuration, such as binlog checksums or GTIDs. (...and you understand that Oracle won't be interested in any bug reports about a larger gap not working...)

Connecting a 5.7 slave to any number of pre-5.7 should be workable... but an important point here, relevant to your situation is that in the master/slave relationship, the slave is really in control of the entire interaction.  It initiates the connection to the master, sets any options on the connection, and asks the master to start sending the replication stream.  The master then dutifully sends replication events until the slave disappears, at which time the master closes the abandoned connection and forgets all about the slave.

Try it. The worst thing that should be possible is that you may have to change some defaults on the slave to get it to negotiate successfully with the older masters, but the older masters should not need any changes or be negatively impacted in any way by a connection from newer slave.



It's a matter of opinion, but I never, ever let the package manager mess with my MySQL servers. The package manager can be a bit of a black box, and if anybody is going to screw up my servers, it's going to be me.  If an upgrade ever fails, it's going to be me who broke it. If you use the "Linux Generic" tarballs from Oracle, it's pretty straightforward.

If you symlink /usr/local/mysql to point to the tarball's extraction directory (which is named for the version and architecture) and then symlink data inside the extraction directory to point to your "datadir," then upgrading MySQL to a new version is as simple as extracting the new tarball, stopping the server daemon, changing 2 symlinks, restarting the daemon, and running mysql_upgrade. If the new version won't start for any reason, well, hey, the old version is still right there.  Move the symlinks back, and punt.

The only dependency you have to take care of manually is installing libaio1, which is in the standard distro repositories, just not installed by default.