[MDEV-4551] mysqldump --dump-slave fails with multi-source replication Created: 2013-05-20  Updated: 2014-03-07  Resolved: 2014-03-07

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

Type: Bug Priority: Major
Reporter: Laurent Kolakofsky Assignee: Michael Widenius
Resolution: Fixed Votes: 3
Labels: replication
Environment:

Centos 6.2 (deployed via pre-compiled archive)

Issue Links:
PartOf
includes MDEV-4827 [PATCH] mysqldump --dump-slave=2 --ma... Closed

 Description   

mysqldump --dump-slave fails with multi-source replication because it tries to run stop/start slave statement.

[mysql@centos ~ ] $ mysqldump --dump-slave --all-databases > /dev/null
 
mysqldump: Couldn't execute 'START SLAVE': The server is not configured as slave; fix in config file or with CHANGE MASTER TO (1200)
 
[mysql@centos ~ ] $

I have replication setup from 4 masters but mysqldump thinks mysqld isn't a slave probably because SHOW SLAVE STATUS returns no row:

[mysql@centos ~ ] $ mysql -e 'show slave status' | wc -l
 
0
 
[mysql@centos ~ ] $ mysql -e 'show all slaves status' | wc -l
 
4
 
[mysql@centos ~ ] $



 Comments   
Comment by Elena Stepanova [ 2013-05-20 ]

That's right, SHOW SLAVE STATUS and START SLAVE in these forms operate with the default_master_connection, which, in turn, is an empty string by default; so if all connections are named, SHOW SLAVE STATUS will return nothing, and START SLAVE will fail.

Apparently, mysqldump will need to somehow figure out the list of configured master connections and apply the dump-slave logic to each of them in turn (to create proper CHANGE MASTER .. statements).
It should also be taken into account with apply-slave-statements option.

Comment by Michael Widenius [ 2014-02-11 ]

Fix pushed into 10.0-monty tree. Will be merged to 10.0 when Elena gives ok

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