| Bug #55432 | --start-xid option for mysqlbinlog | ||
|---|---|---|---|
| Submitted: | 21 Jul 2010 8:58 | ||
| Reporter: | Mikiya Okuno | Email Updates: | |
| Status: | Verified | Impact on me: | |
| Category: | MySQL Server: Command-line Clients | Severity: | S4 (Feature request) |
| Version: | OS: | Any | |
| Assigned to: | Assigned Account | CPU Architecture: | Any |
[21 Jul 2010 9:00]
MySQL Verification Team
The procedure in the bug description is useful especially when semi-sync is used.
[29 Mar 2013 8:42]
Daniël van Eeden
Isn't this fixed with the GTID feature in 5.6?
Description: When XA transactions are not used, the master records its query_id as Xid in the binary logs. Identical Xids to the master can be retrieved from the slave's relay logs. When a slave preserves its relay-log by specifying --relay-log-purge=0, it's very easy to determine the deference between slaves. So, people can sync slave data by applying such deferences retrieved from the most advanced slave by comparing the last Xid in relay-logs. In such case, --start-xid will come in handy. I assume the scenario like below: - 1:N replication setup. - The slaves preserves relay logs for a while by setting --relay-log-purge=0 - The master crashes and the positions where the slaves catch up are not same - Determine the most advanced slave by inspecting Xids in relay-logs - Wait until all relay-logs are applied - Sync slaves by using "mysqlbinlog --start-xid={#} {relay-log-name}" How to repeat: n/a Suggested fix: feature request