Crash-resistant replication breaks due to non-syncing of slave status logs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS |
Invalid
|
Undecided
|
Unassigned | ||
5.1 |
Won't Fix
|
High
|
Unassigned | ||
5.5 |
Triaged
|
High
|
Unassigned | ||
5.6 |
Invalid
|
Undecided
|
Unassigned |
Bug Description
The crash-resistant replication depends on slave-relay.info being present and parsable on the server startup. However, updates to this file (and to master.info) are not synced by default. If a crash leaves an old version of slave-relay.info, then the crash-resistant replication works by overwriting that file. But a crash might also leave slave-relay.info truncated to zero bytes, and then crash-resistant replication will not overwrite it, breaking the replication. And truncated master.info file leaves the slave without master connection information.
I see two possible ways to fix this:
1) Sync the slave status logs after each update. This functionality is present in MySQL 5.5 but not enabled by default due to performance implications, see sync_master_info and sync_relay_log variables. The fix would require 5.1 backport and documenting/
2) Store the entirety of slave status logs in the InnoDB transaction system header and re-create the logs on each startup, also ignoring the non-presence or non-parsability of any existing ones.
tags: | added: crash-resistant-slave-5.5 |
This is another spin-off of bug 937852. bugs.mysql. com/bug. php?id= 35542
MySQL 5.5 sync_master_info and sync_relay_log vars were implemented to fix http://