MySQL从库维护经验分享
前言：
MySQL主从架构应该是最常用的一组架构了。从库会实时同步主库传输来的数据，一般从库可以作为备用节点或作查询使用。其实不只是主库需要多关注，从库有时候也要经常维护，本篇文章将会分享几点从库维护经验，一起来学习吧。
1.主从复制建议采用GTID模式
GTID即全局事务ID（GlobalTransactionID），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.注意从库监控及主从延迟
从库虽然不如主库那么重要，但平时也要多关注从库监控状态，不要等到需要使用从库时才发现从库早已和主库不一致了。除去一些基础监控，从库端要特别关注复制状态及延迟状态。
我们可以在从库端执行showslavestatus;来查询从库状态，其中主要关注的值有三个，分别为SlaveSQLRunning，SlaveIORunning和SecondsBehindMaster。这三个值分别代表SQL线程运行状态、IO线程运行状态、从库延迟秒数。只有当SlaveSQLRunning，SlaveIORunning为yes，然后SecondsBehindMaster为0的时候，我们认为从库运行正常。
总结：
本篇文章主要分享了个人关于从库维护的几点经验，若有错误，还请指正。其他同学若有相关经验或建议，也可以留言分享讨论哦。
以上就是MySQL从库维护经验分享的详细内容，更多关于MySQL从库维护经验的资料请关注毛票票其它相关文章！