MySQL从库维护经验分享

原创
2020/11/19 10:41
阅读数 42
前言: 

MySQL 主从架构应该是最常用的一组架构了。从库会实时同步主库传输来的数据,一般从库可以作为备用节点或作查询使用。其实不只是主库需要多关注,从库有时候也要经常维护,本篇文章将会分享几点从库维护经验,一起来学习吧。


 1.主从复制建议采用 GTID 模式


GTID 即全局事务 ID(Global Transaction ID),GTID 实际上是由 server_uuid:transaction_id 组成的。其中 server_uuid 是一个 MySQL 实例的唯一标识, transaction_id 代表了该实例上已经提交的事务数量,并且随着事务提交单调递增,所以 GTID 能够保证每个 MySQL 实例事务的执行(不会重复执行同一个事务,并且会补全没有执行的事务)。


基于 GTID 的主从复制可以取代过去通过 binlog 文件偏移量定位复制位置的传统方式。特别是对于一主多从的架构,借助GTID,在发生主备切换的情况下,MySQL 的其它 Slave 可以自动在新主上找到正确的复制位置,这大大简化了复杂复制拓扑下集群的维护,也减少了人为设置复制位置发生误操作的风险。另外,基于 GTID 的复制可以忽略已经执行过的事务,减少了数据发生不一致的风险。

2.建议从库参数尽量和主库保持一致


为保证主从库数据一致性,建议从库版本与主库一致,相关参数尽量和主库保持一致。比如字符集、默认存储引擎、sql_mode 这类参数要设置一样。特别是一些不可动态修改的参数,建议提前写入配置文件并和主库一致。


 3.备份可在从库端进行


MySQL 全量备份会对服务器造成一定压力,有时也会短暂持有全局锁。特别是数据量大,业务繁忙的数据库,全量备份可能会对业务产生影响。建议将备份脚本部署在从库服务器上,全量备份可以放在从库端进行,这样能减少备份过程中对于主库业务的影响


4.从库建议设为只读


对于数据库读写状态,主要靠 read_only 全局参数来设定,默认情况下,数据库是用于读写操作的,所以 read_only 参数是 0 或 false 状态。这时候不论是本地用户还是远程访问数据库的用户,只要有权限都可以进行读写操作。


为避免从库发生手动更新操作,建议将从库设置为只读,即将 read_only 参数设置为1。read_only=1 只读模式,不会影响从库同步复制的功能,从库仍然会读取 master 上的日志,并且在 slave 端应用日志,保证主从数据库同步一致。从库设为只读会限制不具有 super 权限的用户进行数据修改操作,普通的应用用户进行 insert 、 update 、 delete 等会产生数据变化的 DML 操作时,都会报出数据库处于只读模式。这样能有效防止从库发生更新操作

此外,有条件的情况下,从库可以承担部分查询工作。比如一些报表聚合分析查询或者外部服务查询都可以配置从库查询,减少对主库的压力。


  5.注意从库监控及主从延迟


从库虽然不如主库那么重要,但平时也要多关注从库监控状态,不要等到需要使用从库时才发现从库早已和主库不一致了。除去一些基础监控,从库端要特别关注复制状态及延迟状态


我们可以在从库端执行 show slave status; 来查询从库状态,其中主要关注的值有三个,分别为 Slave SQL Running , Slave IO Running 和 Seconds Behind Master 。这三个值分别代表 SQL 线程运行状态、 IO 线程运行状态、从库延迟秒数。只有当 Slave SQL Running , Slave IO Running 为 yes ,然后 Seconds Behind Master 为0的时候,我们认为从库运行正常。


总结: 


本篇文章主要分享了个人关于从库维护的几点经验,若有错误,还请指正。其他同学若有相关经验或建议,也可以留言分享讨论哦。

推荐阅读


(点击标题可跳转阅读)

揭秘MySQL主从数据不一致

在线修改主从复制选项

MySQL主从复制详解

- End -

动动手指转发、在看
是对我最大的鼓励



本文分享自微信公众号 - MySQL技术(mysqljishu)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部