[adg数据库同步机制]简述常见数据库高可用方案

　　【科普】常见数据库高可用方案汇总

　　一. 大纲

　　二. MySQL篇

　　2.1. 主从复制

　　2.2. MySQL MHA

　　2.3. MySQL MGR

　　2.4. MySQL NDB Cluster

　　2.5. MySQL Galera Cluster

　　2.6. MySQL InnoDB Cluster

　　2.7. MySQL 中间件

　　2.8. 云数据库

　　2.9. NewSQL

　　三. Oracle篇

　　3.1. Oracle RAC

　　3.2. Oracle ADG

　　3.3. Oracle OGG

　　3.4. Oracle RAC+ADG

　　3.5. 其他高可用方案

　　四. SQL Server篇

　　3.1. 镜像

　　3.2. 复制

　　3.3. 日志传送

　　3.4. 快照

　　3.5. 故障转移群集

　　3.6. AlwaysOn可用组

　　3.7. 第三方双机热备软件

　　五. MongoDB篇

　　5.1. 复制集

　　5.2. 分片

　　5.3. 分片集群

　　六. Redis篇

　　6.1. Redis 多副本

　　6.2. Redis Sentinel

　　6.3. Redis Cluster

　　七. 写在最后

　　附录：

　　一. 大纲

　　本篇介绍常见数据库的，侧重于，不涉及详细原理，主要为了帮助大家对于常见数据库的高可用方案做个汇总性的了解。

　　首先我们先了解下高可用方案的常见类型，下面主要从两个方面来划分。

　　按主要划分为两种：

　　：多个数据库实例之间一份数据存储，常见分案有，

　　: 每个数据库实例一份数据副本，常见分案有，，

　　按主要划分为三种：

　　：常见实现方式为读写分离，典型方案有，

　　：典型方案有，，

　　：典型方案为

　　PS：公司目前由于项目众多，环境参差不齐，且性能上基本单实例可以满足，因此侧重于故障转移，鲜有用到负载均衡的方案。

　　二. MySQL篇

　　MySQL作为当今最流行的开源数据库之一，高可用方案可谓五花八门，下面依次介绍！

　　PS：下述MySQL常见架构中的从库，一般都可以进行只读操作，程序上如果进行基本都可以达到的效果，所以下述中所涉及到的更多是意味着该方案能否在的情况下，依靠方案本身达到的目的！

　　同理的话，故障转移也是，最简单的主从复制其实就可以实现，再配合也可以达到的功能，所以下述中所涉及到的均意味着方案在不借助中间件的情况下可以实现，且对业务程序透明！

　　2.1. 主从复制

　　是MySQL数据库使用率非常高的一种技术，它使用某个数据库服务器为主库（Master），然后实时在其他数据库服务器上进行数据复制，后面复制的数据库也称从库（Slave），架构上可以根据业务需求而进行多种变化组合，因此引申出了，，，等高可用架构。

　　主要是通过复制数据达到数据冗余的效果，其本身并不能实现负载，亦或是故障转移的功能，只能作为最基础的容灾手段！

　　2.2. MySQL MHA

　　是MySQL高可用方案中是一个相对成熟的解决方案。在主从复制的基础上，通过实现了一整套MySQL故障切换方案，保障了数据库的高可用性。

　　MHA 可以实现功能，但并不具备的功能。另外需要注意的是，MHA在故障切换后，由于主从架构的变动，需要人工修复确认后，才可再次具备自动故障转移功能，自身并不具备功能！

　　MHA的自动故障转移主要通过实现，我们常用的是通过实现，当然也可以通过中间件实现。

　　2.3. MySQL MGR

　　是MySQL官方于2016年12月（MySQL5.7.17 GA版）推出的一个全新的高可用与高扩展的解决方案。

　　MGR提供了和两种模式：

　　即组内只有一个节点负责写入，读可以从任意节点读取，组内数据保持最终一致。

　　即组内所有节点均可以进行读写，同时保证组内数据最终一致性。

　　MGR方案本身并不具备和的能力，只有搭配其他第三方中间件后，才可以实现。

　　MGR具有的能力，所谓指的是主库挂掉后，拥有重新选举主库的能力，并且当老的主库恢复后，可以自动重新加入集群，而不需要人工修复。

　　PS：由于MGR目前功能并不完整，主要是官方尚未推出和的对应解决方案，导致还需要其他第三方中间件配合实现，比较繁琐且复杂，所以公司目前主要还是采用MHA作为MySQL高可用方案，相信MGR会是今后MySQL最主流的高可用方案！

　　2.4. MySQL NDB Cluster

　　是MySQL官方从5.0 版本开始推出的一个分布式集群方案，主要通过使用实时备份冗余数据，实现数据库的高可用性和数据一致性。

　　NDB Cluster仅支持，与MySQL常规引擎(InnoDB)存在一定差异，且配置较复杂，基本，这里仅作介绍了解。

　　2.5. MySQL Galera Cluster

　　这部分主要介绍两款基于的集群方案，其一是，其二是，这2个集群方案均由MySQL分支实现，非官方实现。

　　Galera Cluster 是Codership公司开发的一套免费开源的，而与是MySQL的2个分支。

　　是在Galera基础上推出的高可用集群方案。

　　是在Galera基础上推出的高可用集群方案。

　　其实也是MySQL官方借鉴Galera后重新实现的一套集群方案，所以这3个集群方案架构与功能上都比较类似。

　　由于和均是由MySQL分支实现，与MGR一样需要配合中间件才可以实现透明切换与负载均衡，并且依赖于其他开源组件版本的稳定性与功能，因此个人不推荐使用，这里仅作介绍了解。

　　2.6. MySQL InnoDB Cluster

　　是MySQL官方在2017年4月推出了一套完整的、高可用的解决方案，。

　　MIC主要由三部分组成，分别是：、、。

　　MySQL Shell：通过内置的管理API创建及管理Innodb集群。

　　MySQL Router：路由转发中间件，提供透明切换与读写分离能力。

　　MySQL Group Replication：底层的数据同步集群(MGR)，提供容错、故障恢复与弹性扩展。

　　这里需要说明的是MySQL Router的读写分离并，而是通过划分与 来转发不同的请求实现读写分离，本质还是需要程序端才可以实现。

　　MIC是MySQL官方尝试在的情况下，推出的一个的高可用方案，个人感觉还是不错的，起码官方开始尝试了，期待未来进一步的改进完善！

　　2.7. MySQL 中间件

　　除了上述这些常见高可用架构外，MySQL中还存在大量中间件产品，常用于实现、、等功能，下面简单介绍下常见的中间件。

　　常见的MySQL中间件实现的原理如下图所示，通过在与之间架设代理，将后，路由至不同的后端数据库处理，以此达到读写分离的效果，实现负载均衡。

　　中间件代理的常分为以下几类：

　　：显式事务（或）识别为读写请求，转发到主库；隐式事务识别为只读请求，转发到从库。

　　：通过自定义的HINT语法区分SQL类型，代理会根据SQL中是否含有该HINT来进行转发，如DRDS中的读写分离HINT语法为。

　　：通过端口定义读写请求与只读请求，需要改造数据源配置，如MySQL Router。

　　：读写账号识别为读写请求，只读账号识别为只读请求，本质上和端口区别一样，都需要改造数据源配置。

　　PS：读写分离在实现上很少会以区分与，更多的是以区分与！道理很简单，如果一个事务中的读写SQL也进行区分的话，那么就会变成分布式事务，性能上会大打折扣，且需要一系列手段来保证分布式事务的ACID特性！

　　MySQL Proxy (不再维护)

　　MySQL Proxy是官方最早提供的中间件，现已被MySQL Router更迭取代。

　　MySQL Router

　　MySQL官方提供的一个轻量级中间件，用于替代MySQL Proxy。

　　Atlas (停止更新)

　　Atlas是由Qihoo360 基于开发维护的一个MySQL开源中间件。

　　MyCAT

　　MyCAT是社区基于二次开发的开源中间件。

　　DBLE是上海爱可生公司在的基础上进一步优化开发的分布式开源中间件。

　　Cetus是网易基于C语言开发的MySQL开源中间件，分为读写分离和分库分表两个版本。

　　MariaDB官方研发的中间件产品，支持读写分离与分库分表。

　　Sharding-Proxy

　　Sharding-Proxy是Apache ShardingSphere的第二个产品， 定位为透明化的数据库代理端，可以实现读写分离与数据分片。

　　ProxySQL

　　ProxySQL是一个基于C++开发的高性能轻量级的MySQL中间件。

　　个人比较倾向于、与三款中间件产品。

　　2.8. 云数据库

　　所谓云数据库就是一种稳定可靠的，常见的公有云数据库产品有以下几种。

　　阿里云：DRDS

　　DRDS 是一款基于 MySQL 存储、采用分库分表技术进行水平扩展的分布式 OLTP 数据库服务产品，支持 以及 。

　　腾讯云：TDSQL

　　TDSQL是部署在腾讯公有云上的一种支持自动水平拆分的share nothing架构的分布式数据库。

　　华为云：TaurusDB

　　TaurusDB是华为基于与自研的新一代企业级高扩展海量存储分布式数据库。

　　UCloud：UDDB

　　UDDB是基于公有云构建的新一代分布式数据库，为用户提供稳定、可靠、容量和服务能力可弹性伸缩的关系型数据库服务。

　　上述几类云数据库是不同厂商基于MySQL改造或是自研的，完全兼容MySQL，并且在架构上实现了故障转移、读写分离、数据分片、水平扩展等配套功能。

　　云数据库：不需要关心后端的数据库架构及存储，可以专注于业务开发。

　　云数据库：隐私安全问题、数据意外丢失风险、定制化服务不足。

　　2.9. NewSQL

　　最后下NewSQL，NewSQL是一种新型的分布式数据库，其最大的特点就是融合了与的特长，兼具与场景，且拥有高度及，但是对硬件与网络环境要求非常高。

　　TiDB

　　国内 PingCAP 团队开发的一个分布式 NewSQL 数据库，PingCAP是国内一家专注于开源NewSQL领域的团队。

　　OceanBase

　　OceanBase 是蚂蚁金服自研的金融级分布式关系数据库。

　　SequoiaDB（巨杉数据库）

　　广州巨杉软件开发有限公司开发的新一代分布式NewSQL数据库 。

　　上述三款是国内比较火的NewSQL开源项目，都是国内团队开发的，且已在金融级领域应用实践，效果非常牛。

　　三. Oracle篇

　　众所周知，Oracle是全世界RDBMS数据库的龙头老大，长期占据天梯榜top 1，可见其受欢迎程度。Oracle提供了多种数据库部署架构，其中以及是OLTP应用厂商使用最广泛的方案，因为其开发早，软件成熟、用户使用广，文档资料齐全，深受广大DBA工程师的青睐。

　　3.1. Oracle RAC

　　全称，是一种具有的数据库集群，它克服了多实例之间同时读写共享存储的限制，为业务应用提供了一种具有和的数据库解决方案，常用于Oracle9i、10g、11g，12C及以上。

　　ORACLE RAC通过在每个节点安装集群软件以及互连之后，可将多台物理服务器组成数据库集群，多个数据库实例之间可以数据库，避免节点单点故障造成业务中断。

　　ORACLE RAC的特点：

　　实现自动故障转移

　　当有故障节点出现时，业务会自动切换到剩余存活节点上，保证业务对外服务不间断，这对于终端用户来说是无感知的。

　　实现负载均衡

　　RAC集群通常由2到3台甚至多台物理服务器组成，在集群软件的管理之下，可以自动将客户端请求平均分担到各个节点上。

　　具有良好的扩展性

　　RAC集群可以通过增加节点个数，提高集群的整体性能，满足日益增长的数据访问需求。

　　ORACLE RAC唯一的缺陷就是，存在磁盘单点故障的隐患，除此之外，Oracle RAC基本无懈可击！

　　3.2. Oracle ADG

　　是Oracle下的，同样由主库和备库组成，两者通过保证数据同步。

　　ADG架构上可以实现或是的主备架构，所有备库均可以是，且拥有。

　　与RAC相比，ADG自身无法实现与，其唯一的优势就是拥有，可以有效避免磁盘单点故障，并且其副本可读，也可以配合起到分担主库压力的效果！

　　3.3. Oracle OGG

　　是Oracle下一个实现异构 IT 环境间数据实时集成和复制的工具，类似于公司的数据交换平台，主要用于数据实时同步，并且支持各类常见数据库之间的数据转换复制。

　　OGG其实并不算一种HA方案，这里只是正好顺带介绍下，需要注意的是，OGG要在购买Oracle企业版授权后额外付费才可以使用，而RAC与ADG是购买企业版授权后就可以免费使用，这也是OGG正式项目上用的很少的原因。

　　3.4. Oracle RAC+ADG

　　是Oracle下的经典架构，其中RAC提供了，ADG提供了，两者结合在一起，取长补短，坚若磐石，适用于对业务需要不宕机的项目环境。

　　RAC+ADG兼顾了与，且由于其有多份数据副本，也规避了磁盘单点故障的隐患，堪称无敌。

　　这种架构常用于Oracle异地容灾的高可用解决方案中，其中可以只是单实例即可，并不需要同样也是RAC。

　　3.5. 其他高可用方案

　　除了上述几种高可用架构之外，还有其他非常规的架构部署，下面仅做简单介绍。

　　Oracle HA+Keepalived

　　使用Keepalived实现集群，正常情况下由主服务器提供服务，备服务器处于待机备用，当主服务器故障时无法对外提供服务，备用服务器会替代主服务器对外继续提供服务，原本指向主服务器上的服务资源包括网络、存储等服务就会转移到备机接管，从而提供不间断的服务，通俗来讲可视为“低配版RAC”。

　　Oracle

　　MAA

　　MAA(Oracle

　　Maximum Availability Architecture)是Oracle最高可用的技术集合，是将、、、、、等一系列打包，完全利用Oracle各项”黑科技“，数据库宕机，数据删除都不怕，使数据库无坚不摧，堪称数据库的。

　　四.

　　SQL Server篇

　　自从SQL

　　Server 2005以来，微软就提供了多种高可用性技术来减少宕机时间和增加对业务数据的保护，而随着SQL Server 2008，SQL Server

　　2008 R2，SQL Server 2012等新版本的不断发布，SQL

　　Server中已经存在了满足不同场景的多种高可用性技术，下面依次介绍。

　　3.1.

　　镜像

　　是

　　SQL Server 下最常用的高可用解决方案，是一种的高可用方案。

　　镜像中我们将生产库称为，而备用库称之为，两者通过日志流保持实时数据同步。

　　在配置了的情况下，可以实现。原理与之前的VIP漂浮不同，而是在实现故障转移，当连接数据库时，会检测连接是否正常，从而自动切换到镜像库IP。

　　jdbc://192.168.212.243;databaseName=test;failoverPartner=192.168.212.244

　　由于默认是无法打开的，除非在故障切换后才可以打开，所以无法通过镜像库来实现读写分离。

　　另外镜像具有功能，宕掉的主体库在起来后，可以自动转换为镜像库，再次可用！这点在我看来，是非常实用的，和MHA形成了鲜明的对比！

　　3.2. 复制

　　是将从一个数据源拷贝到多个数据源的技术，提供了的保护。

　　复制使用的是，即由向发布数据，再由向分发数据完成同步。

　　复制常用于实现的数据同步或数据容灾，与其他或的高可用方案相比，更加灵活多变！

　　复制无法实现自动故障转移，但是其订阅副本可以进行只读查询，因此可以配合达到的效果，或是作为数据副本共享给第三方使用！

　　3.3.

　　日志传送

　　与镜像类似，同样是一种的高可用方案。

　　通过不间断地备份中的，然后将它们复制并还原到，使辅助数据库与主数据库基本保持同步。

　　日志传送无法实现自动故障转移，只能进行手动故障转移，而且由于数据同步方式并非完全同步，所以容易出现数据丢失！

　　日志传送与复制一样可以实现且，却无法像复制一样可以；与镜像一样是的高可用方案，却无法实现与。

　　日志传送更像是一种介于复制与镜像之间的替代方案，目前很少有场景会用到它。

　　3.4.

　　快照

　　是SQL

　　Server 2005中发布的一个新技术，可以创建某数据库在某一时间点的，并且源库可以通过快照快速还原至该时间点，与虚拟机快照的功能类似！

　　与备份数据库不同，快照并不需要复制源库的所有数据页，仅需要复制在快照建立之后所更新的数据页，还原数据库时也仅需要将快照建立之后更新的数据页恢复至源库，因此快照的速度会远快于备份与还原！

　　快照技术常用于实现，，。

　　快照技术的缺点也非常明显，由于每次更新原始页时都会对快照执行操作，导致源数据库上的

　　I/O 增加，影响数据库性能！

　　严格来说，快照只能作为一种技术，而非高可用解决方案，仔细想想，这玩意不就是加强版的备份还原么！目前很少有场景会用到它。

　　3.5.

　　故障转移群集

　　是利用功能实现的一种高可用方案，其特点是各实例节点之间。

　　是Windows

　　Server自带的一种底层的故障转移方案，包括健康检查、资源管理、分布式元数据通知维护以及故障转移，与都依赖其实现高可用，但是需要额外配置作为基础。

　　故障转移群集是一种且的高可用方案，可以实现自动故障转移，但是无法提供可读副本。

　　故障转移群集更像是的前身，在过去很长时间都是SQL

　　Server的常用高可用技术，但在出现后，就基本替代了这种高可用方案！

　　3.6.

　　AlwaysOn可用组

　　SQL

　　Server 2012 开始引入了作为代替数据库镜像的新型高可用方案，其集中了、和三者的优点，但又不相同。

　　AG支持的单位是，每个组中可以包括一个或者是多个，一旦发生切换，则可用性组中的所有数据库会作为一个整体进行故障切换。

　　AG底层依然采用WSFC进行监测和转移，从Windows

　　server 2016之后开始支持无域控，因此搭建简便很多。

　　vs ：不再是共享存储，可以有效防止磁盘单点故障。

　　vs ：可以拥有多个副本，且副本可读。

　　vs ：可以实现自动故障转移，且可以实现数据完全同步，做到数据0丢失。

　　AlwaysOn可用组作为SQL

　　Server新一代的高可用方案，各方面都有很大的改进，因此个人还是很推荐使用的！

　　最后上一张SQL

　　Server 下各的对比图，大家可以参考下！

　　3.7.

　　第三方双机热备软件

　　除了上述这些官方发布的高可用方案之外，SQL

　　Server下还存在一些第三方的高可用产品，也就是我们俗称的！

　　这些双机热备产品大多是山寨了官方的、等高可用解决方案，功能都是以实现为主，而未实现，且都是需要的，所以个人并不是很推荐。

　　SQL

　　Server常见双机热备软件如下：

　　RoseHA

　　美国Rose数据公司的产品，基于与RoseHA软件系统实现了，与非常相像！

　　RoseMirrorHA

　　美国Rose数据公司的另一种产品，基于文件系统，通过同步主备之间的差异数据，同样可以实现，与非常类似！

　　Lifekeeper

　　美国SteelEye公司的产品，架构和功能上基本与如出一辙，可以当作是的翻版。

　　五.

　　MongoDB篇

　　MongoDB作为的典型，广泛应用于分布式文件存储，其和的功能，可以作为WEB应用提高可扩展性的高性能数据存储解决方案之一。

　　5.1.

　　复制集

　　是由一组mongod实例组成的集群，其中一个节点为，其余节点都是，主从节点之间通过保持数据同步。

　　复制集可以同时实现与功能。

　　其自动故障转移的原理与SQL镜像类似，都是在实现，只要保证半数以上节点存活，整个复制集就可以对外提供服务。

　　01:27017,mongodb03:27017?replicaSet=rs0

　　负载均衡的原理是实现了，其读写分离也是通过实现，简而言之，就是在驱动层识别SQL为或是，然后选择转发到或是。

　　之所以MongoDB选择在SQL层实现读写分离，是因为NoSQL里没有事务的概念，也就不会有的概念。

　　5.2. 分片

　　是MongoDB下通过从而进行，用以支撑海量数据集和高吞吐量的方案。

　　指按照某个维度将存放在的分散存放至或中以达到提升性能与可用性的一种优化技术，该技术常应用在架构中。

　　5.3.

　　分片集群

　　如Oracle下一样，多个方案之间互补，形成更强的数据库架构一样，即是MongoDB下组合而成的一种高可用方案。

　　mongos：数据库集群请求的入口，路由转发的作用。

　　shard：将表数据拆分后形成的分片，同一分片冗余在不同节点中。

　　config

　　server：存储所有数据库元信息（路由、分片）的配置。

　　仲裁：充当一个MongoDB实例，但不保存数据，主要用于集群投票。

　　分片集群同样可实现透明切换与负载均衡，其中复制集可以提供，而分片可以提供与。

　　六.

　　Redis篇

　　Redis是一个开源的高性能key-value数据库，是NoSQL的典型代表之一。

　　6.1.

　　Redis 多副本

　　Redis多副本，采用主从(replication)

　　部署结构，与MySQL主从复制如出一辙。

　　Redis多副本不支持自动故障转移与负载功能，其从库只读，可以承担只读流量。

　　RedisHA过程可以自己开发对应的切换功能，或是由keepalived替代实现透明切换。

　　6.2.

　　Redis Sentinel

　　是Redis官方推出的高可用性解决方案，包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控。

　　Redis

　　Sentinel可以实现自动故障转移，但不能实现负载，其实现原理类似于，但是比MHA好的地方在于存在，可以有效防止单点故障。

　　6.3.

　　Redis Cluster

　　是Redis官方推出的分布式集群解决方案，其主要通过分布式架构解决了单节点Redis性能瓶颈的问题，可以理解为Redis下分片技术的实现。

　　Redis

　　Cluster中数据以的形式，分布在不同的节点上，每个节点又采用了主从模式，防止单节点故障。

　　Redis

　　Cluster中的一个重要概念便是去中心化，即每个节点都可以提供读写服务，类似于MySQL MGR中的多主模式。

　　Redis

　　Cluster可以实现与，均是在驱动层实现。

　　七.

　　写在最后

　　【科普】系列文章目前已发布2篇文章，主要内容为，面向群体为，希望以此来增加公司人员对于数据库的知识网络，更好的在项目上使用与管理好数据库。

　　如果你有什么好的课题的话，欢迎留言，我们会考虑加入到此系列中！

　　《【科普】三大数据库内存分配简介

　　》

　　《【科普】常见数据库高可用方案汇总

　　》

　　附录：

　　https://www.itdks.com/dakalive/detail/703

　　https://www.infoq.cn/article/zYyUb0-QtpQmXfv5H9Ch

　　https://www.infoq.cn/article/y3yNfWZzPUZ0hulawcmh

　　http://1987.name/1744.html

　　http://www.spring4all.com/article/17235

　　https://news.aotu.io/a/5bab51aa0b61600066e30e8e?utm_medium=lite02_web&utm_source=aotu_io