Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
5.5.32, 5.5(EOL)
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.
Attachments
Issue Links
- is part of
-
-
- Closed
-
- relates to
-
-
- Closed
-
- links to
Activity
ok. Thanks for the analysis - logged http://bugs.mysql.com/bug.php?id=69875
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.
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;
Can I get a review on https://github.com/MariaDB/server/pull/2701 please?
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 */
{ opt_lock_all_tables= !opt_single_transaction; opt_master_data= 0; opt_delete_master_logs= 0; }if (opt_slave_data)
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'
{ opt_lock_all_tables= !opt_single_transaction; - opt_master_data= 0; opt_delete_master_logs= 0; }— 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)
@@ -966,7 +965,6 @@
{ opt_lock_all_tables= !opt_single_transaction; - opt_slave_data= 0; }if (opt_master_data)
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.