共计 1521 个字符，预计需要花费 4 分钟才能阅读完成。
前言：
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 的时候，咱们认为从库运行失常。
总结：
本篇文章次要分享了集体对于从库保护的几点教训，若有谬误，还请斧正。其他同学若有相干教训或倡议，也能够留言分享探讨哦。
