Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-253 Multi-source replication
  3. MDEV-548

Multi-source: Behavior of "RESET SLAVE 'name'" is inconsistent with the normal RESET SLAVE

Details

    • Technical task
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • None
    • None
    • None
    • None

    Description

      "RESET SLAVE 'masterX'" totally removes the masterX configuration.
      It's inconsistent with normal "RESET SLAVE" behavior, which clears the replication position, but keeps the configuration (while "RESET SLAVE ALL" removes everything). In our case, when the name is provided, "RESET SLAVE 'name'" and "RESET SLAVE 'name' ALL" seem to be identical.

      Below is a test case for RESET SLAVE (no result file yet, because the test case fails at line 35 with "1617: There is no master connection 'master1":

      cat suite/multi_source/reset_slave.test

      --enable_connect_log
       
      --connect (slave,127.0.0.1,root,,,$SERVER_MYPORT_3)
       
      --replace_result $SERVER_MYPORT_1 MYPORT_1
      eval change master 'master1' to
      master_port=$SERVER_MYPORT_1,
      master_host='127.0.0.1',
      master_user='root';
       
      start slave 'master1';
       
      set default_master_connection = 'master1';
      --source include/wait_for_slave_to_start.inc
       
      --connect (master1,127.0.0.1,root,,,$SERVER_MYPORT_1)
       
      --disable_warnings
      drop table if exists t1;
      --enable_warnings
       
      create table t1 (i int) engine=MyISAM;
      insert into t1 values (1),(2);
       
      --save_master_pos
       
      --connection slave
       
      --sync_with_master 0,'master1'
      stop slave 'master1';
       
      --wait_for_slave_to_stop
       
      --replace_result $SERVER_MYPORT_1 MYPORT_1
      show slave 'master1' status;
      reset slave 'master1';
      --replace_result $SERVER_MYPORT_1 MYPORT_1
      show slave 'master1' status;
      reset slave 'master1' all;
      --error WARN_NO_MASTER_INFO
      show slave 'master1' status;
       
      # Cleanup
       
      drop table t1;
       
      --connection master1
      drop table t1;
       
      --disconnect slave
      --disconnect master1
       

      Attachments

        Activity

          It's intentionally that RESET SLAVE removes the master configuration (this comes from the original patch).
          The reason this method was used, is probably that there was no other logical way to remove a connection.
          This does however create the problem of how to be able to remove the relay logs for a named connection.
          The suggestions I have regarding this are:

          • Let RESET SLAVE remove relay logs and the connection but FLUSH SLAVE would only remove relay logs.
          • Add a DROP SLAVE 'connection_name' command.

          I will go with the second option.

          monty Michael Widenius added a comment - It's intentionally that RESET SLAVE removes the master configuration (this comes from the original patch). The reason this method was used, is probably that there was no other logical way to remove a connection. This does however create the problem of how to be able to remove the relay logs for a named connection. The suggestions I have regarding this are: Let RESET SLAVE remove relay logs and the connection but FLUSH SLAVE would only remove relay logs. Add a DROP SLAVE 'connection_name' command. I will go with the second option.

          Decided to go with RESET SLAVE ALL to delete the connection data.

          monty Michael Widenius added a comment - Decided to go with RESET SLAVE ALL to delete the connection data.

          People

            monty Michael Widenius
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            2 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.