1.2.5　RDS for SQL Server高可用实现

通过前面的介绍，想必大家对SQL Server的内核结构已经有了一定的了解。SQL Server作为经典的商业数据库，在设计与实现上都具备高度的成熟性和艺术性，值得大家学习和使用。

作为RDS的一个引擎，我们也针对SQL Server的高可用特点进行了深度定制。

SQL Server随着版本的迭代，提供了多种高可用方案。为了避免赘述，这里就不展开介绍各个技术的结构了。简单来看，按时间顺序，早在SQL Server 2000版本中，就已经提供了Log Shipping的方案来实现复制。这是一种纯粹的外部实现方式，SQL Server通过配置几个Agent Job定时备份日志、传输日志、恢复日志，以实现容灾的目的，但实时性无法保证。

SQL Server 2005版本提供了多种模式的复制（Replication）技术，堪称ETL的经典典范。其中用得比较多的是事务复制（Transactional Replication）、点对点复制（Peer-to-Peer Replication）和合并复制（Merge Replication），其最大的特点是复制灵活和副本集可（双/多）写。在多活场景中，它们依然是典范。

SQL Server 2005版本还提供了第一个Share Everything方案，即Failover Cluster Instances（FCI）。这个方案需要使用Windows故障转移集群（Failover Cluster）底座，同时，在硬件上还需要共享存储（Shared Storage）来提供支持，当遇到问题时，IP、存储、Instance全部作为资源进行故障转移。

SQL Server 2008版本提供了一个Mirroring方案，即Share Nothing、Master和Standby均使用本地磁盘代替共享存储，通过日志传递的方式进行数据复制。

在SQL Server 2012版本中，微软基于上述两个版本的方案，做了一个新型的融合方案，即大名鼎鼎的AlwaysOn Availability Groups（AG）。该方案结合了FCI的集群故障转移优势，同时允许使用本地磁盘廉价存储，以日志复制代替共享存储。一经面世，它就成为SQL Server绝对主力的高可用方案。

SQL Server原生提供的高可用方案的基础属性如表1-3所示。

表1-3　SQL Server高可用方案的基础属性一览

注：

* FCI，如果要实现零数据丢失保护，则需要绑定AG或者底层SAN存储有实时同步副本。

** AG和Database Mirroring，需要配置自动切换的模式才会自动切换。

*** Database Mirroring，镜像节点本身不可读，但可以用快照方式打开只读。

**** Log Shipping，想要实现只读副本，需要打开“with standby option”。

在阿里云RDS for SQL Server 2008R2至2017高可用版本中，我们通过Mirroring实现了高可用方案，这也是非常成熟的方案。但我们没有使用Witness Server，而是依托RDS自身的HA组件进行探活和判断。关于HA的部分，可以参考本书5.2节的介绍。

而在RDS for SQL Server 2017集群版本中，我们首次使用了SQL Server AlwaysOn技术，并且采用了脱离Windows Server Cluster的技术，剥离了对Windows Server Cluster的依赖，而是依赖RDS自身的HA组件进行判断，帮助切换AG。