MySQL 从站警告 : Configuration does not guarantee that the relay log info will be consistent after a crash

Question

我想为 MySQL 5.6 设置一个新的复制从站。在 CHANGE MASTER 并启动 slave 之后，我在错误日志中看到了这一行:

[Warning] Slave SQL: If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0

如果重要，这些设置包含在 my.ini 中:

skip-name-resolve
skip-host-cache

server-id = 111

report-host = myPC

relay-log-recovery

sync_master_info=1
sync_relay_log=1
sync_relay_log_info=1

replicate-do-db = myDB

skip-slave-start

复制似乎有效，但这个警告很可怕。知道是什么让 MySQL 发出此警告吗？

Answer 1

警告是关于 crash-safe replication ，一个添加到 MySQL 5.6 的特性。这并不意味着正在发生任何可怕的事情(基本上，复制工作与早期版本一样)，而是通知您可以使用 MySQL 5.6 中的新功能集做得更好。

A common request is to have replication crash-safe in the sense that the replication progress information always is in sync with what has actually been applied to the database, even in the event of a crash. Although transactions are not lost if the server crashes, it could require some tweaking to bring the slaves up again. [...]

Crash-safe masters

• If the master crashed when a binary log was rotated, it was possible that some orphan binlog files ended up in the binary log index file. This was fixed in 5.1 but is also a piece in the puzzle of having crash-safe replication.
• Writing to the binary log is not an atomic operation, and if a crash occured while writing to the binary log, there were a possibility of a partial event at the end of the binary log.

Crash-safe slaves

• If the replication information and data is stored in the same storage engine, it will allow both the data and the replication position to be updated as a single transaction, which means that it is crash-safe.
• If the replication information and data is stored in different storage engines, but both support XA, they can still be committed as a single transaction. The replication information is flushed to disk together with the transaction data. Hence writing the replication information directly to the InnoDB redo log does not offer a speed advantage, but does not prevent the user from reading the replication progress information easily.
• The tables can be read from a normal session using SQL commands, which also means that it can be incorporated into such things as stored procedures and stored functions.

请参阅引用博客文章和 MySQL documentation有关操作和设置说明的详细信息。