Description:
I'd like mysqldump to dump both --master-data and --dump-slave as the replication positions of master and slave at the time of the dump.
Using this currently the dump-slave is ignored when master-data is there.
I'd like both as I don't know up front if the dump is going to be used to restore the master or the slave.
How to repeat:
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;
Suggested fix:
=== 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;
(Credits for above to Elena Stepanova in https://mariadb.atlassian.net/browse/MDEV-4827)
Also:
A warning should also be emitted if opt_slave_data=1 and opt_master_data=1 and --apply-slave-statements is enabled as the START SLAVE in the dump will only continue from the latest CHANGE MASTER TO statement.
Having -apply-slave-statements and one of master-data or dump-slave=2 is also leading to a case where the the START SLAVE occurring during a restore making the recording of the other MASTER POSITION a little un-useful however a simple warning should suffice in this case.
Description: I'd like mysqldump to dump both --master-data and --dump-slave as the replication positions of master and slave at the time of the dump. Using this currently the dump-slave is ignored when master-data is there. I'd like both as I don't know up front if the dump is going to be used to restore the master or the slave. How to repeat: 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; Suggested fix: === 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; (Credits for above to Elena Stepanova in https://mariadb.atlassian.net/browse/MDEV-4827) Also: A warning should also be emitted if opt_slave_data=1 and opt_master_data=1 and --apply-slave-statements is enabled as the START SLAVE in the dump will only continue from the latest CHANGE MASTER TO statement. Having -apply-slave-statements and one of master-data or dump-slave=2 is also leading to a case where the the START SLAVE occurring during a restore making the recording of the other MASTER POSITION a little un-useful however a simple warning should suffice in this case.