MySQL数据库 主从同步的多种架构 数据一致性问题解决方案

主从复制的架构

方案一：主备架构，只有主库提供读写服务，备库仅留作备用

1. 高可用分析：高可用，主库挂了，keepalive（只是一种工具）会自动切换到备库。这个过程对业务层是透明的，无需修改代码或配置。

2. 高性能分析：读写都操作主库，很容易产生瓶颈。大部分互联网应用读多写少，读会先成为瓶颈，进而影响写性能。另外，备库只是单纯的备份，资源利用率50%，这点方案二可解决。

3. 一致性分析：读写都操作主库，不存在数据一致性问题。

4. 扩展性分析：无法通过加从库来扩展读性能，进而提高整体性能。

5. 可落地分析：两点影响落地使用。第一，性能一般，这点可以通过建立高效的索引和引入缓存来增加读性能，进而提高性能。这也是通用的方案。第二，扩展性差，这点可以通过分库分表来扩展。

方案二：双主架构，两个主库同时提供服务，负载均衡

1. 高可用分析：高可用，一个主库挂了，不影响另一台主库提供服务。这个过程对业务层是透明的，无需修改代码或配置。

2. 高性能分析：读写性能相比于方案一都得到提升，提升一倍。

3. 一致性分析：存在数据一致性问题。请看，一致性解决方案。

4. 扩展性分析：当然可以扩展成三主循环，但笔者不建议（会多一层数据同步，这样同步的时间会更长）。如果非得在数据库架构层面扩展的话，扩展为方案四。

5. 可落地分析：两点影响落地使用。第一，数据一致性问题，一致性解决方案可解决问题。第二，主键冲突问题，ID统一地由分布式ID生成服务来生成可解决问题。

方案三：主从架构，一主多从，读写分离

1. 高可用分析：主库单点，从库高可用。一旦主库挂了，写服务也就无法提供。

2. 高性能分析：大部分互联网应用读多写少，读会先成为瓶颈，进而影响整体性能。读的性能提高了，整体性能也提高了。另外，主库可以不用索引，线上从库和线下从库也可以建立不同的索引（线上从库如果有多个还是要建立相同的索引，不然得不偿失；线下从库是平时开发人员排查线上问题时查的库，可以建更多的索引）。

3. 一致性分析：存在数据一致性问题。请看，一致性解决方案。

4. 扩展性分析：可以通过加从库来扩展读性能，进而提高整体性能。（带来的问题是，从库越多需要从主库拉取bin log日志的端就越多，进而影响主库的性能，并且数据同步完成的时间也会更长）

5. 可落地分析：两点影响落地使用。第一，数据一致性问题，一致性解决方案可解决问题。第二，主库单点问题，笔者暂时没想到很好的解决方案。

注：思考一个问题，一台从库挂了会怎样？读写分离之读的负载均衡策略怎么容错？

级联复制架构（Master –Slaves - Slaves）

• 因为每个从库在主库上都会有一个独立的Binlog Dump线程来推送binlog日志，所以随着从库数量的增加，主库的IO压力和网络压力也会随之增加，这时，多级复制架构应运而生。
• 多级复制架构只是在一主多从的基础上，再主库和各个从库之间增加了一层二级主库Master2，这层二级主库仅仅用来将一级主库推送给它的BInlog日志再推送给各个从库，以此来减轻一级主库的推送压力。
• 但它的缺点就是Binlog日志要经过两次复制才能到达从库，增加了复制的延时。
• 我们可以通过在二级从库上应用blackhole存储引擎（黑洞引擎）来解决这一问题，降低多级复制的延时。
• “黑洞引擎”就是写入blackhole表中数据并不会写到磁盘上，所以这个Blackhole表永远是个空表，对数据的插入/更新/删除操作仅在Binlog中记录，并复制到从库中去。

方案四：双主+主从架构

1. 高可用分析：高可用。

2. 高性能分析：高性能。

3. 一致性分析：存在数据一致性问题。请看，一致性解决方案 。

4. 扩展性分析：可以通过加从库来扩展读性能，进而提高整体性能。（带来的问题同方案二）

5. 可落地分析：同方案二，但数据同步又多了一层，数据延迟更严重。

主从同步 数据一致性问题解决方案

查看主从延迟

延时指标1：查看从库获取到主库binlog的时间
mysql> show slave status\G
# 查看延时时间
Seconds_Behind_Master: 0

延时指标2：查看从库回放的日志量与主库日量的差
主库：show master status;
从库：show slave status\G

# 查看从库已经拿到的主库日志量
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 1120

# 查看从库已经执行的主库日志量
Relay_Master_Log_File: mysql-bin.000002
Exec_Master_Log_Pos: 1120

既然知道了数据不一致性产生的原因，那如何解决呢?
首先如果业务允许延时存在，那么就不去管它，如果对一致性确实有要求，那么可以围绕以下角度去优化。

1. 硬件方面

1. 采用好服务器，比如4u比2u性能明显好，2u比1u性能明显好。
2. 存储用ssd或者盘阵或者san，提升随机写的性能。
3. 主从间保证处在同一个交换机下面，并且是万兆环境。 总结，硬件强劲，延迟自然会变小。一句话，缩小延迟的解决方案就是花钱和花时间。

2. 文件系统方面

• master端修改linux、Unix文件系统中文件的etime属性， 由于每当读文件时OS都会将读取操作发生的时间回写到磁盘上，对于读操作频繁的数据库文件来说这是没必要的，只会增加磁盘系统的负担影响I/O性能。
• 可以通过设置文件系统的mount属性，组织操作系统写atime信息，在linux上的操作为：
  打开/etc/fstab文件，加上noatime参数 /dev/sdb1 /data reiserfs noatime 1 2，然后重新mount文件系统，mount -o remount /data

3. 优化mysql参数

1. logs-slave-updates从服务器从主服务器接收到的更新不记入它的二进制日志。

2. sync_binlog在slave端设置为0或禁用slave端的binlog

3. slave端，如果使用的存储引擎是innodb，innodb_flush_log_at_trx_commit =2

对数据安全性较高，需要设置
sync_binlog=1
innodb_flush_log_at_trx_commit = 1
而对于slave则不需要这么高的数据安全，完全可以设置为
sync_binlog=0或者关闭binlog
innodb_flush_log_at_trx_commit = 0或2

4. 主从都开启GTID复制模式

GTID即全局事务ID (global transaction identifier)
5.6版本加入GTID复制模式，DUMP在传输日志时可以并发，需要手工配置。
开启GTID后，可以有多个SQL线程，只能针对不同的库的事务进行并行SQL恢复

5.7版本GTID做了增强，不手工开启也自动维护匿名的GTID信息

5.7 版本的从库并发配置方法
gtid_mode=ON 		# 开启GTID复制模式
enforce_gtid_consistency=ON 		# 强制GTID一致性
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master_info_repository=TABLE 		# 将master-info信息记录到表中
relay_log_info_repository=TABLE 		# 将relay-info信息记录到表中
relay_log_recovery=ON

5. 架构方面