MySQL从库维护经验分享

时间:2021-05-02

前言:

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从库维护经验的资料请关注服务器之家其它相关文章!

原文链接:https://cloud.tencent.com/developer/article/1750398

声明:本页内容来源网络,仅供用户参考;我单位不保证亦不表示资料全面及准确无误,也不保证亦不表示这些资料为最新信息,如因任何原因,本网内容或者用户因倚赖本网内容造成任何损失或损害,我单位将不会负任何法律责任。如涉及版权问题,请提交至online#300.cn邮箱联系删除。

相关文章