[MDEV-32058] MariaDB server crashes when replicating 10.6->10.5 Created: 2023-08-31  Updated: 2023-08-31

Status: Open
Project: MariaDB Server
Component/s: Replication
Affects Version/s: 10.5
Fix Version/s: 10.5

Type: Bug Priority: Major
Reporter: Michael Widenius Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None

Issue Links:
Relates
relates to MDEV-32053 New features requested by customer on... Open
relates to MDEV-32059 mariadb-binlog should work between (a... Open

 Description   

Replication from a server to another with a smaller major version numbers is not supported.
However, if one is trying to do that the slave should crash.
In case of any replication protocol incompatibility or not supported sql queries, the slave should give an error and stop replication gracefully.

In theory, as long as there is no new replication features used that has caused changes in the protocol and all queries are also supported in the older version, the replication 'should probably work', but no guarantees.

 Comments   
Comment by Kristian Nielsen [ 2023-08-31 ]

Is there some specific scenario where we get a crash?

While it's not officially "supported", there is actually a lot of code to try to make replication from new master to old slave work as much as possible. If the application uses a new feature on the master that's not available on the slave, then yes it will probably not work. But that is not the common scenario I think, usually it will be some time between upgrading the master and upgrading the application to use new features.

Look at the MARIADB_SLAVE_CAPABILITY_* constants in sql/log_event.h. And in send_event_to_slave() in sql/sql_repl.cc, it has logic to omit events or even replace them with dummy Query events if the slave does not understand them.

However, it looks like no MARIADB_SLAVE_CAPABILITY_* constants have been added since 10.0, I wonder if new replication features in 10.4+ have not properly implemented this? That would be quite bad, and should be fixed.

Generated at Thu Feb 08 10:28:30 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.