[Maria-discuss] Replication New to Old
Hello, I realize that in general replication from a newer master to an older slave is typically not recommended. This said, does anyone have an experience replicating from MariaDB 10.2 to MySQL 5.6? The compatibility matrix found here: https://mariadb.com/kb/en/library/mariadb-vs-mysql-compatibility/ Seems to be missing data on this type of setup. Thanks, Mike
Am 05.04.2018 um 20:22 schrieb Michael Caplan:
I realize that in general replication from a newer master to an older slave is typically not recommended. This said, does anyone have an experience replicating from MariaDB 10.2 to MySQL 5.6?
The compatibility matrix found here: https://mariadb.com/kb/en/library/mariadb-vs-mysql-compatibility/ Seems to be missing data on this type of setup i bet nobody does that because it's a long known fact that a newer version might write statements into the binlog the older slave don't understand - that can happen at any point in time breaking replication silently
Hi Michael, I tried this when 10.1 first came out with a daisy chain replication system but couldn't get it working so upgraded all of my five sites to 10.1 The upgrade proved easy and took less time then I spent trying to get the mixed version replicator to work. Bruce Carlson -----Original Message----- From: Maria-discuss [mailto:maria-discuss-bounces+bruce.carlson=nepean.com@lists.launchpad.net] On Behalf Of Reindl Harald Sent: Friday, 6 April 2018 5:17 AM To: maria-discuss@lists.launchpad.net Subject: Re: [Maria-discuss] Replication New to Old Am 05.04.2018 um 20:22 schrieb Michael Caplan:
I realize that in general replication from a newer master to an older slave is typically not recommended. This said, does anyone have an experience replicating from MariaDB 10.2 to MySQL 5.6?
The compatibility matrix found here: https://mariadb.com/kb/en/library/mariadb-vs-mysql-compatibility/ Seems to be missing data on this type of setup i bet nobody does that because it's a long known fact that a newer version might write statements into the binlog the older slave don't understand - that can happen at any point in time breaking replication silently
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Mike,
Hello,
I realize that in general replication from a newer master to an older slave is typically not recommended. This said, does anyone have an experience replicating from MariaDB 10.2 to MySQL 5.6?
A problem that is evident at once is 10.2 GTID events can not be handled by 5.6. So at least some filtering should be devised. To that part, maybe mysqlbinlog --read-from-remote-server=10.2-"master" | filter | mysql-client-to 5.6-"slave" could be practical?
The compatibility matrix found here: https://mariadb.com/kb/en/library/mariadb-vs-mysql-compatibility/ Seems to be missing data on this type of setup.
True. Cross-vendor replication check is very involving.
Thanks,
Mike
Cheers, Andrei
andrei.elkin@pp.inet.fi writes:
Mike,
Hello,
I realize that in general replication from a newer master to an older slave is typically not recommended. This said, does anyone have an experience replicating from MariaDB 10.2 to MySQL 5.6?
A problem that is evident at once is 10.2 GTID events can not be handled by 5.6. So at least some filtering should be devised.
10.2 does not send GTID to a slave that does not understand it (they are rewritten on-the-fly to BEGIN query events). So GTID events should not cause 5.6 slave to break. More generally, the code in MariaDB (at least the code that I wrote) detects what capabilities the slave has, and avoids sending stuff from the master that an old slave will not understand. See MARIA_SLAVE_CAPABILITY_* in log_event.h. So the intention is that replication to old slave should work. However, this still requires that applications restrict themselves from using any SQL not supported on the old slave. And it is only poorly tested, if at all. Hence the recommendation to avoid new master->old slave. Hope this helps, - Kristian.
Kristian,
andrei.elkin@pp.inet.fi writes:
Mike,
Hello,
I realize that in general replication from a newer master to an older slave is typically not recommended. This said, does anyone have an experience replicating from MariaDB 10.2 to MySQL 5.6?
A problem that is evident at once is 10.2 GTID events can not be handled by 5.6. So at least some filtering should be devised.
10.2 does not send GTID to a slave that does not understand it (they are rewritten on-the-fly to BEGIN query events). So GTID events should not cause 5.6 slave to break.
Thanks for correcting! The gtid filtering meant is therefore already in the server :-).
More generally, the code in MariaDB (at least the code that I wrote) detects what capabilities the slave has, and avoids sending stuff from the master that an old slave will not understand. See MARIA_SLAVE_CAPABILITY_* in log_event.h.
So the intention is that replication to old slave should work. However, this still requires that applications restrict themselves from using any SQL not supported on the old slave. And it is only poorly tested, if at all. Hence the recommendation to avoid new master->old slave.
To detail on that for the statement-based replication the old slave may ignore a part of execution context that the new master records into events, typically into Query-log-event. While ignorance is bliss it can lead to inconsistency in this case. Cheers, Andrei
Thanks everyone for the feedback. In sum, not worth the risk. :) Mike On 2018-04-06 03:54 AM, andrei.elkin@pp.inet.fi wrote:
Kristian,
andrei.elkin@pp.inet.fi writes:
Mike,
Hello,
I realize that in general replication from a newer master to an older slave is typically not recommended. This said, does anyone have an experience replicating from MariaDB 10.2 to MySQL 5.6? A problem that is evident at once is 10.2 GTID events can not be handled by 5.6. So at least some filtering should be devised. 10.2 does not send GTID to a slave that does not understand it (they are rewritten on-the-fly to BEGIN query events). So GTID events should not cause 5.6 slave to break. Thanks for correcting! The gtid filtering meant is therefore already in the server :-).
More generally, the code in MariaDB (at least the code that I wrote) detects what capabilities the slave has, and avoids sending stuff from the master that an old slave will not understand. See MARIA_SLAVE_CAPABILITY_* in log_event.h.
So the intention is that replication to old slave should work. However, this still requires that applications restrict themselves from using any SQL not supported on the old slave. And it is only poorly tested, if at all. Hence the recommendation to avoid new master->old slave. To detail on that for the statement-based replication the old slave may ignore a part of execution context that the new master records into events, typically into Query-log-event. While ignorance is bliss it can lead to inconsistency in this case.
Cheers,
Andrei
participants (5)
-
andrei.elkin＠pp.inet.fi -
Bruce Carlson -
Kristian Nielsen -
Michael Caplan -
Reindl Harald