崩溃后的复制安全

为了尽量降低复制中断的可能性，建议 MySQL 的部分参数按照如下示例进行配置：

--- Master ---
innodb_flush_log_at_trx_commit=1
sync_binlog=1

--- Slave ---
relay_log_info_repository=TABLE
relay_log_recovery=ON

innodb_flush_log_at_trx_commit=1

这个参数可以保障每个事务日志都被同步地写到磁盘。

这是一个符合 ACID 要求的配置，将最大限度地保护你的数据——即使是在复制中也是这样。这是因为二进制日志事件首先被提交，然后事务将被提交并写入磁盘。将此参数设置为 1 将增加磁盘写入操作的频次，同时确保数据的持久性。

sync_binlog=1

该变量控制 MySQL 将二进制日志数据同步到磁盘的频率。将此值设置为 1 意味着在每次事务执行的时候都会把二进制日志同步写入磁盘。这可以防止在服务器崩溃时丢失事务。就像之前的配置参数一样，它也会增加磁盘写入量。

MySQL 在事务（或 SQL 语句）提交但尚未释放锁的时候，在 Binlog 中记录事务（或 SQL 语句），也就是说对于支持事务的引擎来说，每个事务提交时都需要写 Binlog；对于不支持事务的引擎（例如MyISAM）来说，每个 SQL 语句执行完成时，也需要写 Binlog。

为了保证 Binlog 的安全，MySQ L引入 sync_binlog 参数来控制 Binlog 刷新到磁盘的频率。

• 在默认情况下，sync_binlog=0 表示 MySQL 不控制 Binlog 的刷新，由文件系统自己控制文件系统的缓存的刷新。

• 如果 sync_binlog>0，则表示每 sync_binlog 次事务提交，MySQL 调用文件系统的刷新操作将Binlog 刷到磁盘。比如，sync_binlog=1，表示每一次事务提交，MySQL 都需要把 binlog 刷新到磁盘，这样的话，数据库主机的操作系统崩溃或者主机突然掉电的情况下，系统最多损失最近的一个事务的数据；

设置 sync_binlog=1 能尽最大可能保证数据安全，但是在多个事务并发提交时，sync_binlog=1 使得 MySQL 不得不按顺序处理请求，同时高频率的刷新 binlog 对 I/O 的影响明显，很大的影响了 MySQL 的性能。

relay_log_info_repository=TABLE

以前，MySQL 的复制通常依赖磁盘上的文件来跟踪复制位置。这意味着，复制完成事务操作之后，还需要完成同步写入磁盘操作。如果在事务提交和同步之间发生了服务器崩溃，此时，磁盘上的文件将可能包含错误的文件和位置信息。

在该配置下，该信息将被转移到 MySQL 本身的 InnoDB 表中，允许复制更新同一事务中的事务和中继日志信息。这会在一个原子操作中完成，并有助于崩溃恢复。

relay_log_recovery=ON

该参数使得副本服务器在检测到崩溃时会丢弃所有本地中继日志，并从源服务器中获取丢失的数据。这确保了在崩溃中发生的磁盘上的任何损坏或不完整的中继日志都是可恢复的。

配置该参数后，不再需要配置 sync_relay_log，因为在发生崩溃时，中继日志将被删除，也就无须花费额外的操作将它们同步到磁盘。