MariaDB and MySQL both implement the multi-source replication, but their usage and internal implementation are different. In order to facilitate the migration of MySQL users to MariaDB, we want to support MySQL syntax
describe
For CHANGE MASTER/FLUSH RELAY LOG/RESET SLAVE/SHOW RELAY LOG EVENT/SHOW SLAVE STATUS/START SLAVE/STOP SLAVE commands support FOR CHANNEL syntax
"FOR CHANNEL" is just an alias for connection_name, does not change the original implementation, all behaviors are consistent with MariaDB, so some operations are not compatible with MySQL, For example:
(MySQL) When a replica has multiple channels and a FOR CHANNEL channel option is not specified, a valid statement generally acts on all available channels, with some specific exceptions.
(MariaDB) You specify which primary connection you want to work with by either specifying the connection name in the command or setting default_master_connection to the connection you want to work with
The channel name supports up to 64 bytes, and is not case sensitive
The connection name and for channel syntax cannot be used at the same time, otherwise an error will be reported
MariaDB syntax is highly compatible with MySQL, so there is no special SQL_MODE set like Oracle/SQL Server and other databases, FOR CHANNEL is not affected by SQL_MODE
Just about to push the final channel patch to 10.7, but there is one open question:
Why did the patch introduce an test file that only includes an .inc file (doing nothing else) and the inc file is only used in one test?
I think it would be better to remove the include file and put it directly in the test file.
Any comments?
Michael Widenius
added a comment - Just about to push the final channel patch to 10.7, but there is one open question:
Why did the patch introduce an test file that only includes an .inc file (doing nothing else) and the inc file is only used in one test?
I think it would be better to remove the include file and put it directly in the test file.
Any comments?
It looks like a copy-paste issue. The include file was clearly derived from multisource.inc. multisource.inc is a separate file because it's used in two suites – multisource and binlog_encryption. The comment in the new include file still refers to the same reason, only apparently there isn't actual multisource_channel.test in the binlog_encryption suite, neither do I think it's worth adding one. So, it should of course be fine to move the logic directly into the test, of course the comments related to the usage of the include file should be dropped then.
Elena Stepanova
added a comment - It looks like a copy-paste issue. The include file was clearly derived from multisource.inc .
multisource.inc is a separate file because it's used in two suites – multisource and binlog_encryption . The comment in the new include file still refers to the same reason, only apparently there isn't actual multisource_channel.test in the binlog_encryption suite, neither do I think it's worth adding one. So, it should of course be fine to move the logic directly into the test, of course the comments related to the usage of the include file should be dropped then.
I’m sorry, because of my negligence, this problem was left over.
Your idea is right, we can move the logic directly to the test, and delete the comments related to the use of the include file.
To make sure it’s correct, I move the logic to the test and test it again.
woqutech.com
added a comment - I’m sorry, because of my negligence, this problem was left over.
Your idea is right, we can move the logic directly to the test, and delete the comments related to the use of the include file.
To make sure it’s correct, I move the logic to the test and test it again.
I have pushed a fix to bb-10.7-monty. Waiting for Alice to verify it fixed the problem