MySQL-5.7.7复制功能的默认设置改进

Posted 2020-10-03

• 1． 默认开启简化的GTID 恢复

      Binlog_gtid_simple_recovery=TURE(默认值)
      这个参数控制了当mysql启动或重启时，mysql在搜寻GTIDs时是如何迭代使用binlog文件的。

      这个选项设置为真，会提升mysql执行恢复的性能。因为这样mysql-server启动和binlog日志清理更快。该参数为真时，mysql-server只需打开最老的和最新的这2个binlog文件，gtid_purged参数的值和gtid_executed参数的值可以根据这些文件中的Previous_gtids_log_event 或者 Gtid_log_event计算得出。这确保了当mysql-server重启或清理binlog时，只需打开2个binlog文件。
       在MySQL-5.6中，调整这个选项设置也同样会提升性能，但是在一些特殊场景下，计算gtids值可能会出错。而保持这个选项值为false，能确保计算总是正确。
       在MySQL-5.7.7中，几乎不需要在速度和安全性之间做权限。设置该选项为TRUE总能得到正确的结果，除了以下2个极端场景：
       a． 最新的binlog是MySQL-5.7.5(或更老版本)产生的，并且gtid_mode对一些binlog设置为ON，但是对最新的binlog设置为OFF.
       b． GTID_PURGED的状态是MySQL-5.7.7之前的版本发布的，并且在当时激活清理的binlog在当前仍然没有清理完成。
       因此，开启这个选项几乎总是更好一些，所以这个选项默认开启。
       如果这个参数设置为off，在mysql恢复期间为了初始化gtid_executed，所有以最新文件开始的binlog都要被检查。并且为了初始化gtid_purged，所有的binlog都要被检查。这可能需要非常长的时间。

• 2. 默认binlog格式调整为ROW格式

       Binlog-format=ROW(默认值)
       当开启binlog并且binlog格式设置为ROW模式时，每张表的行变动被写到binlog文件中，然后这些变动在从库端应用。这和使用statement格式binlog是不同的。在STATEMENT格式下，binlog会在从库端重新执行。
       所有的数据库变动都能被复制并且这是最安全的复制方式。同基于statement的复制相比，基于row的复制需要的行级锁定更少。在先前的默认statement格式下，不确定的状态可能会造成主从不一致的问题。

• 3. 默认binlog错误后的操作调整为ABORT_SERVER

      Binlog_error_action=ABORT_SERVER
      Binlog_error_action参数控制当不能写binlog时，mysql-server将会采取什么行动。
      设置binlog_error_action=ABORT_SERVER会使mysql-server在写binlog遇到严重错误时退出，比如磁盘满了，文件系统不可写入了等。在ABORT_SERVER选项下，binlog和从库都是安全的，这是官方修改此默认值的原因。
      在先前的选项下（binlog_error_action=IGNORE_ERROR），如果一个错误发生，导致无法写入binlog，mysql-server会在错误日志中记录错误并强制关闭binlog功能。这会使mysql-server在不记录binlog的模式下继续运行，导致从库无法继续获取到主库的binlog。

• 4. 默认开启mysql崩溃时的binlog安全

       MySQL崩溃时的binlog安全是sync_binlog参数控制的，这个参数的值代表了在把binlog刷新到磁盘前，提交的组的数量。
       当sync_binlog=1时，所有的事务都在提交前写入binlog。因此即使binlog事件遇到意外重启，一些在prepared状态的binlog会丢失。这导致服务器在恢复数据时自动回滚这些事务。这确保了从binlog不丢失事务，因此是最安全的选项。事实上，这增加了同步到磁盘的总次数。但是从MySQL5.6开始，已经支持组提交和合并同步了，这使得出现性能问题的可能性最小化了。
       当sync_binlog=0时，mysql-server并不把binlog同步到磁盘，而是依赖操作系统把binlog的内容同步到磁盘。因此，当出现掉电或操作系统崩溃时，很可能出现已经提交的事务没有被同步到磁盘的情况。因此mysql在自动恢复时无法恢复这些事务，他们从binlog中丢失了。

• 5. 默认调低slave_net_timeout

      Slave_net_timeout定义了从库从主库获取数据等待的秒数，超过这个时间从库会主动退出读取，中断连接，并尝试重连。这个参数还影响了主从库之间心跳测试的频率，这个频率的默认值是slave_net_timeout除以2.
      Slave_net_timeout新的默认值是60，此前的默认值是3600秒。在老值下，长时间的复制延迟很可能是网络瞬断造成的。

• 6. 取消会话级gtid_executed参数（@@session.gtid_executed）

    ‘@@global.gtid_executed’ 变量包括了所有记录在binlog中的事务的集合。
       当使用这个变量的会话级值时，他代表了写入事务缓存中的值。Session.gtid_executed只有在gtid_next是UUID：NUMBER并且至少一个DML语句已经被执行却没有提交时才同UUID:NUMBER的值相等。当GTID_NEXT 被设置为其他值是，session . GTID_EXECUTED包含一个空字符串。在MySQL5.7.7中如果使用这个会话级的变量会触发一个警告。对这个变量的全局级（@@global.gtid_executed）没有任何变化,因为这个参数使用频率更高并且当用户忘记提及global关键词时，他们会得到这个变量的会话级值，这个值很可能是不正确的。为了避免这个问题，我们取消了这个变量的会话级设置，同时也因为这个参数在应用中没有任何已知的价值。因此我们把他取消掉了。