Mysql Replication运维与实施（三）

lomg

1、配置部分　　1）binlog_format：replication时使用的格式，为了数据一致性和性能，我们选用“MIXED”模式，让mysql在合适的时机选用“row”、“statement”模式。在后续的版本中，我们已经不建议使用“statement”模式。
　　2）log_slave_updates：slave是否将变更操作也写入自己的binlog，如果此slave后端没有slave跟进，则建议关闭。
　　3）gtid_mode，enforce_gtid_consistency：这两个参数需要配合，同时开启“ON”，在replicaiton模式中GTID特性强烈建议开启。
　　4）report_port，report_host，report_user：需要在slave上配置，主要在master上使用“SHOW SLAVE HOSTS”查看slaves列表时展示。
　　5）slave_parallel_workers：是否开启并发replication，默认为“0”表示不开启，此时slave只有一个SQL线程，用于读取relay log并执行statements；如果此值大于0，表示开启worker线程的个数，此时SQL线程只负责从relay log读取statements，然后转发给workers线程，有worker线程负责执行。通常workers线程的个数与database的个数一样，或者简单设置为2。
　　6）binlog_checksum，master_verify_checksum，slave_sql_verify_checksum：建议开启，对binlog开启校验和验证。
　　7）server_id：这个配置项必备，每个节点都不同，数字类型。
　　8）sync_binlog=1、innodb_flush_log_at_trx_commit=1，这两个参数配合用于控制binlog刷新磁盘的时机，“1”表示每次事务提交都立即刷新磁盘，效率较低但是可以尽可能的保证数据完整性；如果你的数据库是一些社交内容的数据（而非订单数据），可以为了考虑并发能力，而稍微降低binlog刷新频率。
　　2、数据与replication：首先“mysql”这个特殊的系统数据库是不能被replication的，我们需要在配置文件中通过“replicate_ignore_db=mysql”来忽略；然后在master上授权一个具有“REPLICATION SLAVE”权限的用户，比如本文中的“rpl_sys”用户，slaves可以使用此用户与master建立链接并进行数据同步；如果你希望Failover的话，需要在所有的节点上都添加此用户，而且所有的节点上的配置把包括root用户都应该一样，因为任何节点都有可能被提升为master。
　　3、GTID是一个新的特性，它保证了master事务在replication的一致性、有序性，可以有效的简化replication的复杂度和人工干预，我们应该开启此特性。（无论是修改MyISAM，还是InnoDB，无论是否手动开始事务还是自动提交的事务，均会生成GTID，每个事务一个ID，自动提交模式下每个操作一个GTID）
　　4、多线程replication，即“slave_parallel_workers”控制，这个是个需要权衡的配置项，如果你的系统中writes操作比较密集、databases个数较多、大事务较多，那么你应该考虑开启此参数来提高relay log的执行效率，线程数不建议特别多，通常设置为“2”或者根据和databases的个数一致。
　　5、semisync特性，即“半同步”也是新特性，官方推荐使用特性以降低数据丢失的可能性，半同步的核心就是在master与slaves之间有一次同步 + 消息确认的过程，会降低master事务并发提交，但是它保证master与slave之间binlog复制的同步能力。通常，我们将集群中“大多数”slaves开启半同步，部分slaves仍然采用异步同步，这是在数据完整性和性能上做权衡。
　　6、在从master上dump数据时，一定要首先对master实例进行LOCK，我们期望dump的数据是完整的（而非变动、增量的），即使用“FLUSH TABLES WITH READ LOCK;”，此指令将导致binlog、数据文件立即刷新磁盘，且阻止writes操作提交，在dump结束后，我们通过“UNLOCK TABLES”释放锁。上文中已经提到“mysql”这个系统数据通常不能参与replicaiton，所以我们也不能将“mysql”数据dump到其他slaves中。
　　7、关于是否在slave上开启read_only参数，存在一些权衡，按照规范，我们应该在slave上开启read_only，以避免slave上的数据被客户端意外变更，而导致replication集群中数据无法对齐的问题。即slave上的数据是可以直接修改的。
　　此外slave原则上，仍然可以创建其他databases，这些databases与replication master没有关系，application可以直接操作slaves并修改数据。为了避免这种纠缠不清的问题，我们建议slaves统一开启“read_only”。read_only并不会影响replication进程对数据的变更，也不会影响SUPER用户对“系统”状态的变更（比如SET GLOBAL ...）
　　8、在普通的replication模式下，通常master失效后，优先恢复master，而不是failover到其他slaves上。
　　如果master无法恢复：
　　1）将某个slave提升为master，这种方式下可能需要调整客户端Connector的URL配置（因为jdbc没有角色感知的功能，需要开发额外的代码）。
　　2）将slave提升为master，且此slave也使用master的IP（VIP方式，或者硬性路由），此后再重新搭建一个slave即可（可以使用原slave的IP），此种方式需要修改客户端Connector URL配置。