Crash-resistant replication breaks due to non-syncing of slave status logs

[Laurynas Biveinis]

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/ensuring in the code that these variables are set for crash-resistant replication.

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.

[Laurynas Biveinis (laurynas-biveinis)]

This is another spin-off of bug 937852.
MySQL 5.5 sync_master_info and sync_relay_log vars were implemented to fix http://bugs.mysql.com/bug.php?id=35542

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-2767