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

Posted 我的紫霞辣辣

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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. 架构方面

以上是关于MySQL数据库 主从同步的多种架构 数据一致性问题解决方案的主要内容,如果未能解决你的问题,请参考以下文章

mysql主从同步不一致解决方案

我C,MySQL双主架构,原来能这么玩

010.Redis 主从架构搭建及原理详解

主从复制:主从复制的概述一主一从架构搭建主从复制的原理同步数据一致性问题

redis 数据库主从不一致问题解决方案

如何解决主从数据库同步延迟问题