【科普】简述常见数据库高可用方案
一. 大纲
本篇介绍常见数据库的高可用方案，侧重于架构及功能介绍，不涉及详细原理，主要为了帮助大家对于常见数据库的高可用方案做个汇总性的了解。
首先我们先了解下高可用方案的常见类型，下面主要从两个方面来划分。
按底层存储架构主要划分为两种：
-
Shared Storage：多个数据库实例之间共享一份数据存储，常见分案有Oracle RAC，SQL故障转移群集 -
Shared Nothing: 每个数据库实例各自维护一份数据副本，常见分案有MySQL MHA，Oracle ADG，SQL镜像
按功能实现主要划分为三种：
-
Load balancing(负载均衡)：常见实现方式为读写分离，典型方案有读写分离中间件，数据源拆分 -
Auto Failover(自动故障转移)：典型方案有MySQL MHA，SQL镜像(带见证服务器)，AlwaysON -
Load balancing & Auto Failover(两者兼具)：典型方案为Oracle RAC
PS：我目前所在的公司由于项目众多，环境参差不齐，且性能上基本单实例可以满足，因此侧重于故障转移，很少有用到负载均衡的方案。
二. MySQL篇
MySQL作为当今最流行的开源数据库之一，高可用方案可谓五花八门，下面依次介绍！
PS：下述MySQL常见架构中的从库，一般都可以进行只读操作，程序上如果进行
数据源拆分基本都可以达到分担压力的效果，所以下述中所涉及到的负载更多是意味着该方案能否在不拆分数据源的情况下，依靠方案本身达到负载均衡的目的！同理的话，故障转移也是，最简单的主从复制其实就可以实现
手动故障转移，再配合keepalived(中间件)也可以达到自动故障转移的功能，所以下述中所涉及到的故障转移均意味着方案在不借助中间件的情况下可以实现自动故障转移，且对业务程序透明！
2.1. 主从复制
主从复制是MySQL数据库使用率非常高的一种技术，它使用某个数据库服务器为主库（Master），然后实时在其他数据库服务器上进行数据复制，后面复制的数据库也称从库（Slave），架构上可以根据业务需求而进行多种变化组合，因此引申出了主主复制，一主多从，多主一从，联级复制等高可用架构。
主从复制方案主要是通过复制数据达到数据冗余的效果，其本身并不能实现负载，亦或是故障转移的功能，只能作为最基础的容灾手段！
2.2. MySQL MHA
MHA(Master High Availability)是MySQL高可用方案中是一个相对成熟的解决方案。在主从复制的基础上，通过Perl脚本实现了一整套MySQL故障切换方案，保障了数据库的高可用性。
MHA 可以实现故障转移功能，但并不具备负载的功能。另外需要注意的是，MHA在故障切换后，由于主从架构的变动，需要人工修复确认后，才可再次具备自动故障转移功能，自身并不具备故障恢复（挂掉的主库无法自动重新加入集群）功能！
MHA的自动故障转移主要通过VIP漂浮实现，我们常用的是通过ifconfig命令+脚本实现，当然也可以通过keepalived中间件实现。
2.3. MySQL MGR
MGR(MySQL Group Replication)是MySQL官方于2016年12月（MySQL5.7.17 GA版）推出的一个全新的高可用与高扩展的解决方案。
MGR提供了single-primary和multi-primary两种模式：
-
single-primary mode(单主模式)即组内只有一个节点负责写入，读可以从任意节点读取，组内数据保持最终一致。
-
multi-primary mode(多主模式)即组内所有节点均可以进行读写，同时保证组内数据最终一致性。
MGR方案本身并不具备故障转移和负载均衡的能力，只有搭配其他第三方中间件后，才可以实现故障转移及负载均衡。
MGR具有故障恢复的能力，所谓故障恢复指的是主库挂掉后，拥有重新选举主库的能力，并且当老的主库恢复后，可以自动重新加入集群，而不需要人工修复。
PS：由于MGR目前功能并不完整，主要是官方尚未推出故障转移和负载均衡的对应解决方案，导致还需要其他第三方中间件配合实现，比较繁琐且复杂，所以公司目前主要还是采用MHA作为MySQL高可用方案，相信MGR会是今后MySQL最主流的高可用方案！
2.4. MySQL NDB Cluster
MNC(MySQL NDB Cluster)是MySQL官方从5.0 版本开始推出的一个分布式集群方案，主要通过使用NDB存储引擎实时备份冗余数据，实现数据库的高可用性和数据一致性。
NDB Cluster仅支持NDB存储引擎，与MySQL常规引擎(InnoDB)存在一定差异，且配置较复杂，基本很少使用，这里仅作介绍了解。
2.5. MySQL Galera Cluster
这部分主要介绍两款基于
Galera Cluster的集群方案，其一是MariaDB Galera Cluster，其二是Percona XtraDB Cluster，这2个集群方案均由MySQL分支实现，非官方实现。
Galera Cluster 是Codership公司开发的一套免费开源的MySQL多主同步集群方案，而MariaDB与Percona是MySQL的2个分支。
MGC(MariaDB Galera Cluster)是MariaDB在Galera基础上推出的高可用集群方案。
PXC(Percona XtraDB Cluster)是Percona在Galera基础上推出的高可用集群方案。
MGR其实也是MySQL官方借鉴Galera后重新实现的一套集群方案，所以这3个集群方案架构与功能上都比较类似。
由于PXC和MGC均是由MySQL分支实现，与MGR一样需要配合中间件才可以实现透明切换与负载均衡，并且依赖于其他开源组件版本的稳定性与功能，因此个人不推荐使用，这里仅作介绍了解。
2.6. MySQL InnoDB Cluster
MIC(MySQL InnoDB Cluster) 是MySQL官方在2017年4月推出了一套完整的、高可用的解决方案，。
MIC主要由三部分组成，分别是：MySQL Shell、MySQL Router、MySQL Group Replication(MGR)。
-
MySQL Shell：通过内置的管理API创建及管理Innodb集群。
-
MySQL Router：路由转发中间件，提供透明切换与读写分离能力。
-
MySQL Group Replication：底层的数据同步集群(MGR)，提供容错、故障恢复与弹性扩展。
这里需要说明的是MySQL Router的读写分离并非对应用透明，而是通过划分读写端口(6446)与 只读端口(6447)来转发不同的请求实现读写分离，本质还是需要程序端根据业务类型重新定义数据源才可以实现。
MIC是MySQL官方尝试在不依赖于第三方中间件的情况下，推出的一个功能比较完整的高可用方案，个人感觉还是不错的，起码官方开始尝试了，期待未来进一步的改进完善！
2.7. MySQL 中间件
除了上述这些常见高可用架构外，MySQL中还存在大量中间件产品，常用于实现
读写分离、故障转移、数据分片等功能，下面简单介绍下常见的中间件。
常见的MySQL中间件实现读写分离的原理如下图所示，通过在Web与DB之间架设代理，将读写流量区分后，路由至不同的后端数据库处理，以此达到读写分离的效果，实现负载均衡。
中间件代理识别读写流量的工作原理常分为以下几类：
-
事务区分：显式事务（start transaction或autocommit=0）识别为读写请求，转发到主库；隐式事务识别为只读请求，转发到从库。 -
HINT区分：通过自定义的HINT语法区分SQL类型，代理会根据SQL中是否含有该HINT来进行转发，如DRDS中的读写分离HINT语法为/!TDDL:MASTER|SLAVE*/。 -
端口区分：通过端口定义读写请求与只读请求，需要改造数据源配置，如MySQL Router。 -
账号区分：读写账号识别为读写请求，只读账号识别为只读请求，本质上和端口区别一样，都需要改造数据源配置。
PS：读写分离在实现上很少会以SQL为界限区分读SQL与写SQL，更多的是以事务为界限区分读写事务与只读事务！道理很简单，如果一个事务中的读写SQL也进行区分的话，那么就会变成分布式事务，性能上会大打折扣，且需要一系列手段来保证分布式事务的ACID特性！
官方中间件
-
MySQL Proxy (不再维护)
-
MySQL Proxy是官方最早提供的中间件，现已被MySQL Router更迭取代。
-
-
MySQL Router
-
MySQL官方提供的一个轻量级中间件，用于替代MySQL Proxy。
-
第三方开源中间件
-
Atlas (停止更新)
-
Atlas是由Qihoo360 基于
MySQL-Proxy开发维护的一个MySQL开源中间件。
-
-
MyCAT
-
MyCAT是社区基于
阿里Cobar二次开发的开源中间件。
-
-
DBLE-
DBLE是上海爱可生公司在
MyCAT的基础上进一步优化开发的分布式开源中间件。
-
-
Cetus-
Cetus是网易基于C语言开发的MySQL开源中间件，分为读写分离和分库分表两个版本。
-
-
MaxScale-
MariaDB官方研发的中间件产品，支持读写分离与分库分表。
-
-
Sharding-Proxy
-
Sharding-Proxy是Apache ShardingSphere的第二个产品， 定位为透明化的数据库代理端，可以实现读写分离与数据分片。
-
-
ProxySQL
-
ProxySQL是一个基于C++开发的高性能轻量级的MySQL中间件。
-
个人比较倾向于MaxScale、Cetus与DBLE三款中间件产品。
2.8. 云数据库
所谓云数据库就是一种稳定可靠的
在线数据库服务，常见的公有云数据库产品有以下几种。
-
阿里云：DRDS
-
DRDS 是一款基于 MySQL 存储、采用分库分表技术进行水平扩展的分布式 OLTP 数据库服务产品，支持
RDS for MySQL以及POLARDB for MySQL。
-
-
腾讯云：TDSQL
-
TDSQL是部署在腾讯公有云上的一种支持自动水平拆分的share nothing架构的分布式数据库。
-
-
华为云：TaurusDB
-
TaurusDB是华为基于
新一代DFV存储与计算存储分离架构自研的新一代企业级高扩展海量存储分布式数据库。
-
-
UCloud：UDDB
-
UDDB是基于公有云构建的新一代分布式数据库，为用户提供稳定、可靠、容量和服务能力可弹性伸缩的关系型数据库服务。
-
上述几类云数据库是不同厂商基于MySQL改造或是自研的分布式数据库，完全兼容MySQL，并且在架构上实现了故障转移、读写分离、数据分片、水平扩展等配套功能。
云数据库优势：不需要关心后端的数据库架构及存储，可以专注于业务开发。
云数据库劣势：隐私安全问题、数据意外丢失风险、定制化服务不足。
2.9. NewSQL
最后
拓展介绍下NewSQL，NewSQL是一种新型的分布式数据库，其最大的特点就是融合了RDBMS与NoSQL的特长，兼具OLTP与OLAP场景，且拥有高度可扩展性及可用性，但是对硬件与网络环境要求非常高。
-
TiDB
-
国内 PingCAP 团队开发的一个分布式 NewSQL 数据库，PingCAP是国内一家专注于开源NewSQL领域的团队。
-
-
OceanBase
-
OceanBase 是蚂蚁金服自研的金融级分布式关系数据库。
-
-
SequoiaDB（巨杉数据库）
-
广州巨杉软件开发有限公司开发的新一代分布式NewSQL数据库 。
-
上述三款是国内比较火的NewSQL开源项目，都是国内团队开发的，且已在金融级领域应用实践，效果非常牛。
三. Oracle篇
众所周知，Oracle是全世界RDBMS数据库的龙头老大，长期占据
DB-Engines天梯榜top 1，可见其受欢迎程度。Oracle提供了多种数据库部署架构，其中RAC以及ADG是OLTP应用厂商使用最广泛的方案，因为其开发早，软件成熟、用户使用广，文档资料齐全，深受广大DBA工程师的青睐。
3.1. Oracle RAC
Oracle RAC全称Oracle Real Application Cluster，是一种具有共享缓存架构的数据库集群，它克服了多实例之间同时读写共享存储的限制，为业务应用提供了一种具有高度可扩展性和可用性的数据库解决方案，常用于Oracle9i、10g、11g，12C及以上。
ORACLE RAC通过在每个节点安装集群软件grid infrastructure以及心跳网络互连之后，可将多台物理服务器组成数据库集群，多个数据库实例之间可以同时读写数据库，避免节点单点故障造成业务中断。
ORACLE RAC的特点：
-
实现自动故障转移
-
当有故障节点出现时，业务会自动切换到剩余存活节点上，保证业务对外服务不间断，这对于终端用户来说是无感知的。
-
-
实现负载均衡
-
RAC集群通常由2到3台甚至多台物理服务器组成，在集群软件的管理之下，可以自动将客户端请求平均分担到各个节点上。
-
-
具有良好的扩展性
-
RAC集群可以通过增加节点个数，提高集群的整体性能，满足日益增长的数据访问需求。
-
ORACLE RAC唯一的缺陷就是缺少冗余副本，存在磁盘单点故障的隐患，除此之外，Oracle RAC基本无懈可击！
3.2. Oracle ADG
ADG(Oracle Active Data Guard)是Oracle下的主从复制，同样由主库和备库组成，两者通过日志同步机制保证数据同步。
ADG架构上可以实现1：1或是1：N的主备架构，所有备库均可以是只读副本，且拥有独立数据副本。
与RAC相比，ADG自身无法实现自动故障转移与自动负载均衡，其唯一的优势就是拥有多个数据副本，可以有效避免磁盘单点故障，并且其副本可读，也可以配合拆分数据源起到分担主库压力的效果！
3.3. Oracle OGG
OGG(Oracle GoldenGateOGG)是Oracle下一个实现异构 IT 环境间数据实时集成和复制的工具，类似于公司的数据交换平台，主要用于数据实时同步，并且支持各类常见数据库之间的数据转换复制。
OGG其实并不算一种HA方案，这里只是正好顺带介绍下，需要注意的是，OGG要在购买Oracle企业版授权后额外付费才可以使用，而RAC与ADG是购买企业版授权后就可以免费使用，这也是OGG正式项目上用的很少的原因。
3.4. Oracle RAC+ADG
RAC+ADG是Oracle下的经典架构，其中RAC提供了高可用，ADG提供了高可靠，两者结合在一起，取长补短，坚若磐石，适用于对业务需要7x24H不宕机的项目环境。
RAC+ADG兼顾了自动故障转移与负载均衡，且由于其有多份数据副本，也规避了磁盘单点故障的隐患，堪称无敌。
这种架构常用于Oracle异地容灾的高可用解决方案中，其中Secondary Site可以只是单实例即可，并不需要同样也是RAC。
3.5. 其他高可用方案
除了上述几种高可用架构之外，还有其他非常规的架构部署，下面仅做简单介绍。
-
Oracle HA+Keepalived
使用Keepalived实现集群，正常情况下由主服务器提供服务，备服务器处于待机备用，当主服务器故障时无法对外提供服务，备用服务器会替代主服务器对外继续提供服务，原本指向主服务器上的服务资源包括网络、存储等服务就会转移到备机接管，从而提供不间断的服务，通俗来讲可视为“低配版RAC”。
-
Oracle MAA
MAA(Oracle Maximum Availability Architecture)是Oracle最高可用的技术集合，是将RAC、DataGuard、flashback、RMAN、ASM、GoldenGate等一系列打包，完全利用Oracle各项”黑科技“，数据库宕机，数据删除都不怕，使数据库无坚不摧，堪称数据库的金钟罩。
四. SQL Server篇
自从SQL Server 2005以来，微软就提供了多种高可用性技术来减少宕机时间和增加对业务数据的保护，而随着SQL Server 2008，SQL Server 2008 R2，SQL Server 2012等新版本的不断发布，SQL Server中已经存在了满足不同场景的多种高可用性技术，下面依次介绍。
3.1. 镜像
镜像(Mirroring)是
SQL Server 下最常用的高可用解决方案，是一种数据库级的高可用方案。
镜像中我们将生产库称为主体库(读写能力)，而备用库称之为镜像库(无法打开)，两者通过日志流保持实时数据同步。
镜像在配置了见证服务器+failoverPartner的情况下，可以实现自动故障转移。原理与之前的VIP漂浮不同，而是在驱动层实现故障转移，当连接数据库时，会检测连接是否正常，从而自动切换到镜像库IP。
由于镜像库默认是无法打开的，除非在故障切换后才可以打开，所以无法通过镜像库来实现读写分离。
另外镜像具有故障恢复功能，宕掉的主体库在起来后，可以自动转换为镜像库，自动故障转移再次可用！这点在我看来，是非常实用的，和MHA形成了鲜明的对比！
3.2. 复制
复制(Replication)是将一组数据从一个数据源拷贝到多个数据源的技术，提供了数据库对象级别的保护。
复制使用的是发布-分发-订阅模式，即由发布服务器向分发服务器发布数据，再由分发服务器向订阅服务器分发数据完成同步。
复制常用于实现表级的数据同步或数据容灾，与其他实例级或数据库级的高可用方案相比，更加灵活多变！
复制无法实现自动故障转移，但是其订阅副本可以进行只读查询，因此可以配合拆分数据源达到分担压力的效果，或是作为数据副本共享给第三方使用！
3.3. 日志传送
日志传送(Log
Shipping)与镜像类似，同样是一种数据库级的高可用方案。
日志传送通过不间断地备份主数据库中的事务日志，然后将它们复制并还原到辅助数据库，使辅助数据库与主数据库基本保持同步。
日志传送无法实现自动故障转移，只能进行手动故障转移，而且由于数据同步方式并非完全同步，所以容易出现数据丢失！
日志传送与复制一样可以实现多副本且副本可读(间接性)，却无法像复制一样可以具体到表级同步；与镜像一样是数据库级的高可用方案，却无法实现数据完全同步与自动故障转移。
日志传送更像是一种介于复制与镜像之间的替代方案，目前很少有场景会用到它。
3.4. 快照
快照(snapshot)是SQL
Server 2005中发布的一个新技术，可以创建某数据库在某一时间点的只读副本，并且源库可以通过快照快速还原至该时间点，与虚拟机快照的功能类似！
与备份数据库不同，快照并不需要复制源库的所有数据页，仅需要复制在快照建立之后所更新的数据页，还原数据库时也仅需要将快照建立之后更新的数据页恢复至源库，因此快照的速度会远快于备份与还原！
快照技术常用于实现维护历史数据以生成报表，数据比对，数据快速恢复。
快照技术的缺点也非常明显，由于每次更新原始页时都会对快照执行写入复制操作，导致源数据库上的
I/O 增加，影响数据库性能！
严格来说，快照只能作为一种技术，而非高可用解决方案，仔细想想，这玩意不就是加强版的备份还原么！目前很少有场景会用到它。
3.5. 故障转移群集
故障转移群集(FCI)是利用Windows
Server故障转移群集(WSFC)功能实现自动故障转移的一种实例级高可用方案，其特点是各实例节点之间共享存储。
WSFC是Windows
Server自带的一种底层的故障转移方案，包括健康检查、资源管理、分布式元数据通知维护以及故障转移，FCI与AlwaysOn都依赖其实现高可用，但是需要额外配置AD(域控)作为基础。
故障转移群集是一种配置较为复杂且维护有一定难度的高可用方案，可以实现自动故障转移，但是无法提供可读副本。
故障转移群集更像是AlwaysOn可用组的前身，在过去很长时间都是SQL
Server的常用高可用技术，但在AlwaysOn可用组出现后，就基本替代了这种高可用方案！
3.6. AlwaysOn可用组
SQL
Server 2012 开始引入了AlwaysOn可用组(AlwaysOn
Availability Groups 简称AG)作为代替数据库镜像的新型高可用方案，其集中了故障转移群集、数据库镜像和日志传送三者的优点，但又不相同。
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公司的产品，架构和功能上基本与RoseHA如出一辙，可以当作是RoseHA的翻版。
五. MongoDB篇
MongoDB作为
非关系型数据库(NoSQL)的典型，广泛应用于分布式文件存储，其复制集和分片的功能，可以作为WEB应用提高可扩展性的高性能数据存储解决方案之一。
5.1. 复制集
复制集是由一组mongod实例组成的集群，其中一个节点为主节点(Primary)，其余节点都是从节点(Secondary)，主从节点之间通过oplog保持数据同步。
复制集可以同时实现自动故障转移与负载均衡功能。
其自动故障转移的原理与SQL镜像类似，都是在驱动层实现，只要保证半数以上节点存活，整个复制集就可以对外提供服务。
负载均衡的原理是实现了读写分离，其读写分离也是通过驱动层实现，简而言之，就是在驱动层识别SQL为写SQL或是读SQL，然后选择转发到主节点或是从节点。
之所以MongoDB选择在SQL层实现读写分离，是因为NoSQL里没有事务的概念，也就不会有分布式事务的概念。
5.2. 分片
分片(sharding)是MongoDB下通过分片技术从而进行水平扩展，用以支撑海量数据集和高吞吐量的方案。
分片技术指按照某个维度将存放在单一数据库中的数据分散存放至多个数据库或数据表中以达到提升性能与可用性的一种优化技术，该技术常应用在分布式数据库架构中。
5.3. 分片集群
如Oracle下RAC+DG一样，多个方案之间互补，形成更强的数据库架构一样，分片集群即是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节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控。
Redis
Sentinel可以实现自动故障转移，但不能实现负载，其实现原理类似于MySQL
MHA，但是比MHA好的地方在于存在多个监控节点(Sentinel)，可以有效防止单点故障。
6.3. Redis Cluster
Redis
Cluster是Redis官方推出的分布式集群解决方案，其主要通过分布式架构解决了单节点Redis性能瓶颈的问题，可以理解为Redis下分片技术的实现。
Redis
Cluster中数据以哈希槽(slot)的形式，分布在不同的节点上，每个节点又采用了主从模式，防止单节点故障。
Redis Cluster中的一个重要概念便是去中心化，即每个节点都可以提供读写服务，类似于MySQL MGR中的多主模式。
Redis
Cluster可以实现自动故障转移与负载均衡，均是在驱动层实现。
七. 写在最后
【科普】系列文章目前已发布2篇文章，主要内容为总结整理数据库方面的常用知识，面向群体为公司开发与实施，希望以此来增加公司人员对于数据库的知识网络，更好的在项目上使用与管理好数据库。
如果你有什么好的课题的话，欢迎留言，我们会考虑加入到此系列中！
