[MDEV-10163] mysqldump hard to work and dangerous using multi master Created: 2016-06-01  Updated: 2017-05-29

Status: Open
Project: MariaDB Server
Component/s: Replication, Scripts & Clients
Fix Version/s: None

Type: Task Priority: Minor
Reporter: VAROQUI Stephane Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None


 Description   

MariaDB does not provide an easy way to restore a node in multi master

What DBA should do for M1<->M2

echo "STOP SLAVE; set sql_log_bin=0;" ; mysqldump .... ; echo "START SLAVE;" > backup.sql

This situation is not good as by lack of knowledge many users report active master database corruption caused by binlog reexecution of the restore of the peer node

To simplify restoring of a slave MySQL 5.7 introduced
--apply-slave-statements
Include STOP SLAVE prior to CHANGE MASTER statement and START SLAVE at end of output

Not documented and implemented yet in MariaDB

We could implement a --multi-master that is combination of --apply-slave-statements
and --skip-binlog disable binlog on restore .

--skip-binlog is still at this time a long awaited option requested 10 years ago

Extra workload protection :
At the time of dump we could get a way to store the replication slave server_id in the dump , restoring the dump can check that current server id is the same as in the dump and break the restore by introducing an SQL error :ERR xxx - "the restore will be replay on the master it is originated" : please use --force to ignore this error


Generated at Thu Feb 08 07:40:08 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.