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的时候，我们认为从库运行正常。
总结：
本篇文章主要分享了个人关于从库维护的几点经验，若有错误，还请指正。其他同学若有相关经验或建议，也可以留言分享讨论哦。
