[MDEV-4827] [PATCH] mysqldump --dump-slave=2 --master-data=2 doesn't record both Created: 2013-07-30  Updated: 2024-02-08  Resolved: 2024-02-08

Status: Closed
Project: MariaDB Server
Component/s: Scripts & Clients
Affects Version/s: 5.5.32, 5.5
Fix Version/s: 10.5.25, 10.6.18, 10.11.8, 11.0.6, 11.1.5, 11.2.4, 11.3.3

Type: Bug Priority: Minor
Reporter: Daniel Black Assignee: Daniel Black
Resolution: Fixed Votes: 1
Labels: beginner-friendly, patch, replication, upstream, verified

Issue Links:
PartOf
is part of MDEV-4551 mysqldump --dump-slave fails with mul... Closed
Relates
relates to MDEV-32611 Test suite is missing dump option del... Closed

 Description   

from

/usr/bin/mysqldump -u backup  --all-databases --extended-insert --dump-slave=2 --master-data=2 --include-master-host-port --single-transaction --no-data

only the following replication position was recorded.

-- CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=4041, MASTER_LOG_FILE='mariadb-bin.000047', MASTER_LOG_POS=31738774;

Its useful too have both since in a backup scenario its unknown whether the dump is going to be use used to replace the master or configured as the new slave.

 Comments   
Comment by Elena Stepanova [ 2013-07-30 ]

Hi Daniel,

I agree, nothing in documentation suggests that these options are mutually exclusive, and comments in the code also don't explain why it's done this way, they only mention preserving master logs, but it's irrelevant to master_data:

/* We don't delete master logs if slave data option */
if (opt_slave_data)

{ opt_lock_all_tables= !opt_single_transaction; opt_master_data= 0; opt_delete_master_logs= 0; }

if (opt_master_data)

{ opt_lock_all_tables= !opt_single_transaction; opt_slave_data= 0; }

The fix is primitive unless there is a secret reason why it was done this way:

=== modified file 'client/mysqldump.c'
— client/mysqldump.c 2013-04-12 08:48:21 +0000
+++ client/mysqldump.c 2013-07-30 11:17:22 +0000
@@ -950,7 +950,6 @@
if (opt_slave_data)

{ opt_lock_all_tables= !opt_single_transaction; - opt_master_data= 0; opt_delete_master_logs= 0; }

@@ -966,7 +965,6 @@
if (opt_master_data)

{ opt_lock_all_tables= !opt_single_transaction; - opt_slave_data= 0; }

if (opt_single_transaction || opt_lock_all_tables)
lock_tables= 0;

However, since it comes from upstream, it would be good to (try to) get it fixed there. Are you willing to file a bug at bugs.mysql.com? I can do it on your behalf, but yours might have a better chance, besides it will be easier for you to track.

Comment by Daniel Black [ 2013-07-31 ]

ok. Thanks for the analysis - logged http://bugs.mysql.com/bug.php?id=69875

Comment by kurt.ding [ 2022-09-21 ]

Ok, I check the mysql code in branch 8.0 , but slave data and master data is still exclusive. So this suggested patch is not included.

Comment by kurt.ding [ 2022-09-21 ]

In my opinion , when a user uses mysqldump, he need to know which role the machine is basiclly . And he still can manually STOP SLAVE SQL_THREAD or STOP SLAVE;

Comment by Daniel Black [ 2023-07-18 ]

Can I get a review on https://github.com/MariaDB/server/pull/2701 please?

Comment by Brandon Nesterenko [ 2023-10-27 ]

Hi Daniel! I left a comment on the PR for your consideration.

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