Multi-source replication (MDEV-253)

[MDEV-548] Multi-source: Behavior of "RESET SLAVE 'name'" is inconsistent with the normal RESET SLAVE Created: 2012-09-26  Updated: 2012-09-27  Resolved: 2012-09-27

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Technical task Priority: Major
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates

 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
 



 Comments   
Comment by Michael Widenius [ 2012-09-27 ]

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.

Comment by Michael Widenius [ 2012-09-27 ]

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

Generated at Thu Feb 08 06:29:34 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.