Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-26307

multi-source-replication support mysql syntax(for channel)

Details

    Description

      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

      new syntax for MariaDB

      CHANGE MASTER

      CHANGE MASTER ['connection_name'] TO master_def [, master_def] ... [FOR CHANNEL 'connection_name'] 
      

      FLUSH RELAY LOG

      FLUSH RELAY LOGS ['connection_name' | FOR CHANNEL 'connection_name']
      

      RESET SLAVE

      RESET SLAVE ['connection_name'] [ALL] [FOR CHANNEL 'connection_name'] 
      

      SHOW RELAY LOG EVENT

      SHOW RELAYLOG ['connection_name'] EVENTS [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count] [ FOR CHANNEL 'connection_name']
      

      SHOW SLAVE STATUS

      SHOW SLAVE ['connection_name'] STATUS [FOR CHANNEL 'connection_name'] 
      

      START SLAVE

      START SLAVE ['connection_name'] [thread_type [, thread_type] ... ] [FOR CHANNEL 'connection_name']
      

      STOP SLAVE

      STOP SLAVE ['connection_name'] [thread_type [, thread_type] ... ] [FOR CHANNEL 'connection_name']
      

      Attachments

        Issue Links

          Activity

            I have pushed a fix to bb-10.7-monty. Waiting for Alice to verify it fixed the problem

            monty Michael Widenius added a comment - I have pushed a fix to bb-10.7-monty. Waiting for Alice to verify it fixed the problem

            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?

            monty 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.

            elenst 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.
            woqutech.com 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.

            woqutech.com 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.
            woqutech.com woqutech.com added a comment - for_channel_test_210915.diff

            People

              monty Michael Widenius
              woqutech.com woqutech.com
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.