2010 年刚到上海， 在 HP 谋了一份商务智能的开发工作。做的是世界五百强的 ITIL 数据仓库项目。在这里见识到了书上讲的一些工具和应用，比如 Kimball《维度建模》中提到的各种维度模型，数据仓库之父 Inmon 对于数据集市原型的理论，开发工具更是类目纷繁，SQL Server , Oracle, SSIS, SSAS, SSRS, SAP BusinessObjects, BIEE, Hyperion, ProClarity, Performance Point Server, SharePoint Server, Excel Service, Crystal Reports(当时已被 BO 收购），ERWin 等等。要迁移 500 强集团各自的工具，需要的技术栈不是小团队能接手的，所以 HP 容纳了我们近 200 多号人。
随着项目的尾声，我们也陆陆续续有些人奔赴了其他岗位，而我收到了一份 Offer, 是当时乃至现在的存储业大佬开出的 SQL Server DBA 一职，薪资是 25K/M。 2008 年之前我看的书最多还是在 DBA 技巧上面，不论是 SQL Server 还是 Oracle ,只要是文档，拿来不拒。而 2010年参加完 ITIL 这份项目之后，我将重心移到了 BIDW 领域，甚至已经有心看 Hadoop 等分布式的数据系统，所以自然也就没接收。
如今项目中需要 SQL Server 的一些高可用属性，才想起当时 SQL Server DBA 一职面试的时候，问道过 SQL Server 的一些高级属性，比如复制，灾备以及高并发处理等等。然已经不看文档好久，趁此机会做个总结，也好下回应用有个参照。所以这会是个系列文档，慢慢写来。
高可用 （High Availability ）可以保障 应用 7*24 小时在线。实现 SQL Server 高可用的方案有很多，不同版本提供的方案也不同。从完整的历史角度来整理，会有这些：
备份机制
Failover集群
Replication – Log：shipping, publish/subscribe, CDC, database mirroring
Alwayson Availability Group
有些已经退出历史舞台了，时下 Alwayson Availability Group 是头等公民。
Alwayson Availability Group 的实现，从架构上来看，是得益于主从模式(Master-Slave,Primary – Secondary). 在主库上支持读写，而在从库上只支持读操作。一旦主库不能访问了，就切换到从库，将从库提升为主库角色。
要确保应用数据可用，维护其一致性，首先要做到主从库之间的数据，实时同步。只要有一点延迟，主从切换就会导致数据丢失。《Design Data-Intensive Applications》主从库的同步机制讲得更细，应用分布式的设计方案。
Alwayson Availability Group，其从库可以达到 8 个之多，如果都从主库读取数据，可想，对主业务库会产生不可预知的负载，因此从库之间的复制就变得十分必要了。这是我一开始猜测的想法，结果和MSDN文档描述的大不一样。
AAG 从概念上分类，主要分为 Primary Replica 和 Secondary Replica. Primary Replica 负责管理所有的数据库主本，这些数据库是指定需要 Alwayson Availability Group 特性的一个或者多个数据库，Primary Replica 将监控这些数据库主本的日志，将其实时送到 Secondary Replica ， 再由 Secondary Replica 将日志应用到本地的服务器上，还原主库的数据，以达到数据一致。在 Secondary Replica 副本数( 存储副本的服务器)大于 3 个的时候，其中两个服务器的日志需要和主库保持实时同步。这和《Data-Intensiv》讲述的是一致的。整个集群中，至少有3 台机器的数据，始终保持一致。
在同步主从库日志的过程中，MSDN强调 Primary Replica 负责了将日志从主库上同步到其他从库，而不是用从库上读取日志，同步到其他从库，那么在从库数量很多的配置中，主业务库将成在不可预知的查询量。为了降低这份查询量，我们需要设计 primary replica 从日至文件中读取增量日志来同步，存储在单独的 primary replica 的机器上，然后再分发。类似于kafka 分流的架构。
上述结构是将 primay replica 节点单独拿出来，作为中转服务器，与CDC的distributor起到一样的功用。如果不单独拎出来，与数据库服务器共存，共享服务器资源也能很好的工作。与CDC不同的是，CDC 可以控制延迟，而 AlwaysOn Availability Group 副本之间，是要严格保持同步的，有了 Primary Replica 这一层中间节点，怎么保证同步呢？
主从库同步机制以及从库的升级竞争机制 是隐藏在 Alwayson Availability Groups 操作背后的机理。无论我们的 AAG 是为了 failover 还是 read loadbalance 而设计，都需要对这两个原理着重理解。
主从库的同步，分为两阶段。第一阶段是全量同步，也就是从库的初始化。在实现初始化的阶段，运用的是备份恢复机制。对主库进行全备份，将备份文件在从库服务器上还原 ( restore with no recovery) ，并保持不恢复的状态，此时将这些从库加入到 Alwayson Availablity Groups，接着进行恢复。恢复的过程中，从库开始接受主库的日志，进行数据同步。为了减少同步的时间，越早进行从库的还原，恢复时候使用的时间越少；第二阶段是增量同步。增量同步是Primary Replica 进行的数据同步操作。这一阶段同步的成本高在事务等待时间，主库需要等待从库的写入安全的完成，才写入主库日志。显然写操作的延时会巨大。
主从库的同步，需要配置主从库的 Availability Mode. Mode 分为 Asynchronous-commit mode 和 Synchronous-commit mode. 当availability replica 设置为asynchronous-commit mode, replica 中配置的database， 不需要和主库实时同步；当设置为 synchronous-commit mode, 则replica 中配置的database,需要和主库保持实时同步，主库必须等待secondary replica 中的database 写入完成，才完成自己的写入。
主从库的设计主要就是了防范数据库失效故障事件，所以详细了解故障事件发生后主从库会有哪些操作，才会让我们在处理故障时游刃有余。AlwaysOn Availability Group 在处理失效故障事件时，一般都有三种切换主从库的 方式：手工切，自动切，强制切。设置了synchronous-commit mode的 availability replica，可以实现自动切和手工切，但是如果配置了 SQL Server Failover Cluster Instances( FCIs)的实例，就只能手工切了。也好理解，因为 primary database 如果有了FCI, 本身就带着 HA 特性来的，不需要自动切到 Secondary database 上去；如果设置的是 asynchronous-commit mode , 那么只能支持强制切，因为在 asynchronous-commit mode 下，主从库数据不会实时保持同步，会导致数据不一致，因此强制切是在了解了切换可能带来的风险下作的有效决定。
