master_info与relay_info对Mysql数据库有什么影响
发布时间：2022-01-12 13:06:57 所属栏目：MySql教程 来源：互联网
导读：master_info与relay_info对Mysql数据库有什么影响，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。 在MySQL 5.6.2之前，slave记录的master信息以及slave应用binlog的信息存放在文件中
|
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数据库有什么影响问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助。 （编辑：温州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
