mysql5.7 slave意外停止配置参数

slave上的以下设置组合最能防止意外停止：

• 当使用基于GTID的复制（gtid_mode=on）时，请设置set MASTER_AUTO_POSITION=1，它会激活GTID自动定位以连接到源，从而自动识别和检索丢失的事务。使用change master to语句设置此选项。如果slave具有多个复制通道，则需要分别为每个通道设置此选项。使用基于文件位置的复制时， MASTER_AUTO_POSITION=1不使用它，而是使用二进制日志位置或中继日志位置来控制复制从何处开始。

• Setsync_relay_log=1，它指示复制I / O线程在将每个接收到的事务写入磁盘后将中继日志同步到磁盘。这意味着从源的二进制日志（在源元数据存储库中）读取的当前位置的slave记录永远不会超过中继日志中保存的事务记录。请注意，尽管此设置最安全，但由于涉及的磁盘写入数量，它也是最慢的。用sync_relay_log > 1或sync_relay_log=0（由操作系统处理同步）（如果副本意外停止），则可能存在尚未同步到磁盘的已提交事务。如果恢复的slave基于中继日志中最后一次同步到磁盘的信息，而试图恢复而不是跳过它们，则这些事务可能导致恢复过程失败。设置 sync_relay_log=1这对于多线程slave尤其重要，在多线程slave中，如果无法使用中继日志中的信息来填充事务序列中的间隙，则恢复过程将失败。对于单线程slave，如果相关信息在申请人元数据存储库中不可用，则恢复过程仅需要使用中继日志。

• Set innodb_flush_log_at_trx_commit=1，它在innodb提交每个事务之前将日志同步到磁盘。此设置是默认设置，可确保将innodb表和 innodb日志保存在磁盘上，从而不再需要中继日志中有关事务的信息。结合设置 sync_relay_log=1,此设置可以进一步确保innodb表和表 的内容 innodb 日志始终与中继日志的内容保持一致，因此，在意外中断的情况下，清除中继日志文件(relay_log_purge =on)不会在slave的事务历史记录中造成无法填补的空白。

• Set relay_log_info_repository=table，它将复制SQL线程位置存储在 innodb表中 mysql.slave_relay_log_info，并与事务提交一起对其进行更新以确保记录始终准确。该设置不是MySQL 5.7中的默认设置。如果使用默认 FILE设置，则信息将存储在数据目录中的文件中，该文件在应用事务后将更新。这会造成失去与源同步性的风险，这取决于副本停止在哪个事务处理阶段，甚至文件本身损坏。使用该设置 relay_log_info_repository=file，不能保证恢复。

• Set relay_log_recovery=on,它将在服务器启动后立即自动中继日志恢复。该全局变量在运行时默认为OFF， 并且是只读的，但是在slave意外停止后，您可以在slave启动时将该--relay-log-recovery选项设置为ON。请注意，如果它们已损坏或不一致，则此设置将忽略现有的中继日志文件。中继日志恢复过程将启动一个新的中继日志文件，并从源代码中获取事务，该事务从记录在应用程序元数据存储库中的复制SQL线程位置开始。随着时间的推移，slave的常规清除机制会删除以前的中继日志文件。

• 对于多线程slave,设置 relay_log_recovery=on 会自动处理已从中继日志执行的事务序列中的任何不一致和空白。使用基于文件位置的复制时，可能会出现这些差距。多线程还需要配置 slave_preserve_commit_order=1，此变量设置1确保事务在副本上的外部化顺序与slave中继日志中出现的顺序相同，并防止已从中继日志执行的事务序列出现间隙。slave_preserve_commit_order=1 要求--log-bin和--log-slave-update在slave服务器上启用，并将 slave_parallel_type其设置为LOGICAL_CLOCK。多线程具体在多线程参数进行描述。