Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.2.11
-
None
-
10.2.12, 10.0.34, 10.1.31, 10.2.13
Description
In a regular Master-Slave configuration the Slave sql erros out a dup key.
The slave has been set up via backup restore and is claimed not to have
any local updates. The backup restore procedure is standard to include
`set global gtid_slave_pos=$GTID_from_backup` where the gtid value is
extracted from `xtrabackup_info`. Barring a mistake of the slave gtid state setting,
the following
``change master to master_host='xx.xx.xxx', master_port=zzzz master_user='user', master_password='xxxxx', master_use_gtid=slave_pos;
start slave;```
should've worked out without any issue.
However the slave stopped. More details can be found on the customer issue page.
Attachments
Issue Links
- is duplicated by
-
MDEV-16001 parallel replication appears in deadlock
-
- Closed
-
When events of a big transaction are binlogged offsetting over 2GB from
the beginning of the log the semisync master's dump thread
lost such events.
The events were skipped by the Dump thread that found their skipping
status erroneously.
The current fixes make sure the skipping status is computed correctly.
The test verifies them simulating the 2GB offset.