master

共计 2077 个字符，预计需要花费 6 分钟才能阅读完成。

master_info 与 relay_info 对 Mysql 数据库有什么影响，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

在 MySQL 5.6.2 之前，slave 记录的 master 信息以及 slave 应用 binlog 的信息存放在文件中，即 master.info 与 relay-log.info。在 5.6.2 版本之后，允许记录到 table 中，参数设置如下：

master-info-repository  = TABLE    —FILE 表示以文件方式

relay-log-info-repository = TABLE  —FILE 表示以文件方式

对应的表分别为 mysql.slave_master_info 与 mysql.slave_relay_log_info，且这两个表均为 innodb 引擎表。

master info 与 relay info 还有 3 个参数控制刷新：

默认为 10000，即每 10000 次 sync_relay_log 事件会刷新到磁盘。

如果值 0, MySQL SERVER 同步它的 relay log 到磁盘(写入中继日志, 使用 fdatasync()) 在 every sync_relay_log events are written to the relay log.） 

当设置为 1 时，slave 的 I / O 线程每次接收到 master 发送过来的 binlog 日志都要写入系统缓冲区，然后刷入 relay log 中继日志里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成  

磁盘的大量 I /O。

当设置为 0 时，并不是马上就刷入中继日志里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘 I / O 操作。

sync_master_info: 控制 master_info 信息的更新操作
若 master-info-repository 为 FILE，当设置为 0，则每次 sync_master_info 事件都会刷新到磁盘，默认为 10000 次刷新到磁盘；
  若 master-info-repository 为 TABLE，当设置为 0，则表不做任何更新，设置为 1，则每次事件会更新表 #默认为 10000

sync_relay_log_info：控制 relay_log_info 信息的更新操作
若 relay_log_info_repository 为 FILE，当设置为 0，交由 OS 刷新磁盘，默认为 10000 次刷新到磁盘；
若 relay_log_info_repository 为 TABLE，且为 INNODB 存储，则无论为任何值，则都每次 evnet 都会更新表。

master 宕机后无法及时恢复造成的数据丢失

    当 master 出现故障后，binlog 未及时传到 slave，或者各个 slave 收到的 binlog 不一致。且 master 无法在第一时间恢复，这个时候怎么办？

    如果 master 不切换，则整个数据库只能只读，影响应用的运行。

    如果将别的 slave 提升为新的 master，那么原 master 未来得及传到 slave 的 binlog 的数据则会丢失，并且还涉及到下面 2 个问题。

      1. 各个 slave 之间接收到的 binlog 不一致，如果强制拉起一个 slave，则 slave 之间数据会不一致。

      2. 原 master 恢复正常后，由于新的 master 日志丢弃了部分原 master 的 binlog 日志，这些多出来的 binlog 日志怎么处理，重新搭建环境？

对于上面出现的问题，一种方法是确保 binlog 传到从库，或者说保证主库的 binlog 有多个拷贝。第二种方法就是允许数据丢失，制定一定的策略，保证最小化丢失数据。

1. 确保 binlog 全部传到从库

    方案一：使用 semi sync（半同步）方式，事务提交后，必须要传到 slave，事务才能算结束。对性能影响很大，依赖网络适合小 tps 系统。

    方案二：双写 binlog，通过 DBDR OS 层的文件系统复制到备机，或者使用共享盘保存 binlog 日志。

    方案三：在数据层做文章，比如保证数据库写成功后，再异步队列的方式写一份，部分业务可以借助设计和数据流解决。

2. 保证数据最小化丢失

    上面的方案设计及架构比较复杂，如果能容忍数据的丢失，可以考虑使用淘宝的 TMHA 复制管理工具。

        当 master 宕机后，TMHA 会选择一个 binlog 接收最大的 slave 作为 master。当原 master 宕机恢复后，通过 binlog 的逆向应用，把原 master 上多执行的事务回退掉。

3. 总结

      通过上面的总结分析，MySQL 丢数据的场景是五花八门，涉及到单库的丢数据场景、主从的丢数据场景以及 MySQL 内部 XA 事务原理等，相对还比较复杂，有点难以理解。

      只有当我们了解了这些丢数据的场景，才能更好的去学习，并解决这些问题。

关于 master_info 与 relay_info 对 Mysql 数据库有什么影响问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。