keeps both the master and slave binlog position info in mysqldump log
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
Though the --master-data and --dump-slave could provide the MASTER(connected node to be dumping) and SLAVE(the dumping node's master, if exists), it's still not enough for DBA to use when try to use the restored node as a slave for the MASTER or SLAVE, for some urgent situation, as these two parameters conflict, only one CHANGE MASTER is allowed.
For the urgent case, take an example from our DBA's daily work, when dumped with --dump-slave but later want to use the backup to catch up the dumping node as a slave, because the master is crashed. It's hard to handle such case.
We could provide both MASTER and SLAVE binlog position info, when --dump-slave both provided:
--
-- Position to start replication or point-in-time recovery from (the master of this slave)
--
CHANGE MASTER TO MASTER_
--
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_
Note that, the dumping node's binlog info is provided, and it's commented, once DBA decide to restore a new slave as the dumping node, it's possible.
Changed in percona-server: | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
tags: | added: contribution |
if we dumped the data from slave with --dump-slave and the master server was crashed later , and then the role of slave may be upgraded to be a new master, we can't set up a slave server that point to new master because we lack the information of "master status"