第3章 新一代的高可用技术alwayson 101
·
AlwaysOn在开发初期代号叫做HADRon。AlwaysOn是一种集合了高可用性（HA）和灾难恢复（DR）两种功能于一身的技术。
·
AlwaysOn所支持的高可用单位，既不像Cluster一样，是整个SQL实例；也不像数据库镜像和日志传送一样，只能是单个用户数据库。而是一个“可用性组”（AvailabilityGroup）。可用性组里的所有数据库作为一个整体发生故障转移。
·
AlwaysOn利用了Windows故障转移群集的健康监测和自动故障转移的特性，因此它必须建立在Windows故障转移群集之上。但可用性组里的数据库并不是一定要求存放在共享存储（SharedDisk）上。
·
像群集一样，AlwaysOn支持故障转移，但是它具有其独特的特点：
o
多个用户数据库可以一同进行故障转移。这对要同时使用多个用户数据库的应用，例如Microsoft SharePoint，会很有帮助。
o
提供一个虚拟的服务器网络名，无论哪个服务器是当前的主服务器，客户端都可以使用统一的虚拟服务器名进行连接。(这一点与普通的群集如何区分？)
在Windows群集中,一个群集内的所有节点共同组成一个“虚拟”的服务器(Virtual Server)。也就是说，从这个群集的外部来看，只能看到一个服务器，而不是它背后的一堆节点服务器。虚拟服务器具有自己的机器名和IP地址，而这个名称和IP与群集内的任何节点都不同。由于服务器是虚拟的，因此人们称呼它的IP是“虚拟IP”，而它的机器名是“虚拟网络名”（virtual network name）。但事实上“虚拟IP”和“虚拟网络名”都是在DNS服务器上登记在册的，它们本身和一台真实的物理机器的IP和机器名没有任何区别，只是它们对应的服务器是一个虚拟的机器。虚拟IP一定要和公共网络配置在同一个网段里，因为这个IP需要在网络上可以被其它机器访问到。在Windows群集中，虚拟IP，虚拟网络名，共享磁盘，SQL Server等等，被统称为“资源”。在任意时刻，只有群集中的一个节点能提供用户所需的服务和资源，而其它节点都处于空闲状态。所以，Windows群集无法提供负载均衡的能力。这个技术和NLB是有本质区别的。
o
具有三种故障转移模式：自动，手动和强制，用户可以选择发生故障切换的条件。
o
一个主服务器可以对应最多达4个辅助服务器（总共5个服务器）。发生故障时可以切换到任意一个辅助服务器上。
o
有Dashboard可用于监视AlwaysOn的运行状态。有丰富的信息可用于故障诊断（DMV,性能计数器，扩展事件日志等）
o
得益于Windows Server 2008群集，可以实现多站点的部署。主服务器和辅助服务器之间可以在物理上相隔很远。
·
像镜像和日志传递一样，AlwaysOn在辅助服务器上有数据库的另外一份拷贝。所不同的是，这份拷贝可以支持更多的只读功能。
o
每个辅助服务器上都有一份数据的拷贝，可以使服务器上的数据拷贝和主服务器上的数据完全同步。
o
辅助服务器可用于只读的访问请求。
o
辅助服务器可以执行备份和DBCC命令。
o
在某些配置情况下，客户端的只读请求可以被自动定向到辅助服务器。
o
可以自动修复某些类型的数据页面损坏问题。
o
主服务器和辅助服务器之间的数据会被加密和压缩，提高了安全性又降低了网络流量。
3.1. Alwayson的基本架构 102
3.1.1. 安装Windows Cluster -
首先要部署一套Windows2008或者Windows2008 R2的群集环境
3.1.2. 安装SQL Server实例
- 在Windows群集的节点上，安装SQL Server单机实例，也可以使用群集中的多个节点安装SQL Server群集实例。
3.1.3. 部署Availability
Group - 无论是单机实例，还是群集实例，只要这些实例上都配置了同一个AlwaysOn可用性组，这些实例就被称为该可用性组的可用性副本（Availability
Replica）。在多个可用性副本间，只有一个可用性副本上运行的数据库是处于可读写状态。这个可读写的数据库被称为主数据库（Primary Database），而这个可用性副本被称为主副本（primary replica [instance]）。其余的副本都被称为辅助副本（secondary
replica），辅助副本上的数据库可能是不可访问的，或者是只能接受只读操作（取决于可用性组的配置），这些数据库被称为辅助数据库。一但发生故障转移，任何一个辅助副本都可以成为新的主副本实例。主副本会不断地将主数据库上的数据变化发送到辅助副本，来实现副本间的数据库同步。
3.1.4. 创建Listener - 为了可以让应用程序能够透明的连接到主副本而不会受到故障转移的影响，你需要创建一个Listener。一个Listener包含虚拟IP地址，虚拟网络名（DNS名）和端口号三个要素。创建了Listener之后，就会为可用性组资源添加虚拟IP地址和虚拟网络名资源。应用程序通过连接虚拟网络名而非主副本的实例名来访问到主副本实例和其上面运行的数据库，这点和故障转移群集很像。和故障转移群集不同的是，除了虚拟网络名可以使用之外，主副本本身的真实实例名依旧可以被用来连接到这个实例。你可以在创建可用性组的时候就为这个可用性组配置一个Listener。你也可以在可用性组创建完毕之后再动态的添加或删除listener。
3.2. Alwayson的数据同步原理 106
3.2.1.
主副本使用2个线程
·
LogWriter线程 - 记录修改，记入日志缓冲区，然后再写入物理日志文件（日志固化）。
·
LogScanner工作线程 - 将日志记录从日志缓冲区或者日志文件里中读出，打包成日志块，发送给各个辅助副本。由于它的不停工作，主副本上的数据变化，可以不断地向辅助副本上传播。
3.2.2.
在辅助副本上，同样会有两个线程，完成相应的数据更新动作，它们是固化(Harden)和重做(Redo)。
·
固化线程会将主副本LogScanner所发过来的日志块写入辅助副本的磁盘上的日志文件里（这个过程被称为“固化”）。
·
重做线程，则负责从磁盘上读取日志块，将日志记录翻译成数据修改操作，在辅助副本的数据库上完成。
3.3. Alwayson的可用性模式 107
3.3.1.
异步提交模式 -
Asynchronous-commit mode is a disaster-recovery solution that works well when the
availability replicas are distributed over considerable distances.
3.3.2. 同步提交模式 -
Synchronous-commit mode emphasizes high availability over performance, at the cost of
increased transaction latency.
3.4. Alwayson的故障转移形式 111- 自动、手动和强制
3.4.1.
AlwaysOn是如何发现可用性组出现问题的? - AlwaysOn可用性组也是使用resourceDLL来连接Windows群集和SQLServer实例。该资源类型使用的resourceDLL的叫做hadrres.dll，在hadrres.exe中定义了如何对AlwaysOn可用性组经行Isalive检查的方法。
3.4.2.
那么AlwaysOn可用性组是如何执行Isalive检查来判断它的健康状况的呢？ AlwaysOn也是使用了sp_server_diagnostics来检查可用性组的健康状况。Hadrres.dll会建立并保持一个连接到SQLServer，并通过这个连接运行sp_server_diagnostics，然后不断的获得诊断信息。
3.4.3.
AlwaysOn发现故障之后，是否会立刻触发故障转移呢？这取决于可用性副本的可用性模式和故障转移模式。
如前所述，the availability mode is a replica property that determines
whether a given availability replica can run in synchronous-commit mode. 它有2个模式： Synchronous-commit availability mode and Asynchronous-commit
availability mode. Failover
mode also has two modes: automatic and manual - AUTOMATIC is supported only if you
also specify SYNCHRONOUS_COMMIT AVAILABILITY_MODE. MANUAL - Enables manual failover or
forced manual failover (forced
failover)。
2者的结合产生了three
forms of failover: （1）Automatic failover (without data loss), (2) planned Manual
failover (without data loss), and forced manual failover (with possible data
loss), typically called forced failover.
·
自动故障转移形式
o
Conditions required for an automatic failover
ü 当前主副本和一个辅助副本都设置为同步提交模式以及自动故障转移模式。
ü 辅助副本必须与主副本同步。即辅助数据库处于SYNCHRONIZED状态 (The automatic failover target has a healthy
synchronization state - this indicates that every secondary database on the
failover target is synchronized with its corresponding primary database).
ü The
Windows Server Failover Clustering (WSFC) cluster has quorum.
ü 主副本变得不可用，此时将发生自动故障转移（The primary replica has
become unavailable）.
o
How automatic failover works?
ü 如果运行当前主副本的副本实例仍在运行，则它会将主副本和辅助副本的连接状态更改为 DISCONNECTED 并断开所有客户端的连接。
ü 如果在故障转移目标副本上还有任何日志记录处于重做队列中，辅助副本会继续执行重做，以完成对辅助数据库的前滚操作。
ü 完成前滚操作后，辅助副本就转换为了主副本，其数据库成为了主数据库。新的主副本将尽快回滚任何未提交的事务。
ü 新的主副本在连接到一个辅助副本形成新的对话之前，会把自己置为 NOT SYNCHRONIZED状态。无论回滚操作是否已经结束，只要有辅助副本可以连接到新的主副本，主数据库就会转换为 SYNCHRONIZED 状态。
o
当原来的主副本解决了故障重新开始运行后，它会发现其它某个可用性副本现在变成了主副本，于是它就把自己转换为辅助副本，将其数据库将成为辅助数据库。当新的辅助数据库连接上新的主数据库后，辅助数据库就开始进行同步来赶上主数据库的日志末尾。
·
手动故障转移形式
o
Conditions required for manual failover
ü The
current primary replica must be set to synchronous-commit mode
ü The
secondary replica must be:
Ø Configured
for synchronous-commit mode.
Ø Currently
synchronized with the primary replica.
Ø To
manually fail over an availability group, you must be connected to the
secondary replica that is to become the new primary replica.
o
How automatic failover works? – 与自动基本一致，区别在于从Secondary上开始。
ü A
manual failover causes a synchronized secondary replica to transition to the
primary role after a database administrator issues a manual-failover command on
the server instance that hosts the target secondary replica.
ü To
ensure that no new user transactions occur on the original primary databases,
the WSFC cluster sends a request to the primary replica to go offline.
ü If
any log is waiting in the recovery queue of any secondary database, the
secondary replica finishes rolling forward that secondary database.
ü The
secondary replica becomes the new primary replica, and the former primary
replica becomes the new secondary replica.
ü The
new primary replica rolls back any uncommitted transactions and brings its
databases online as the primary databases. All secondary databases are briefly
marked as NOT SYNCHRONIZED until they connect and resynchronize to the new
primary databases. This process does not roll back any committed transactions.
ü When
the former primary replica comes back online, it takes on the secondary role,
and the former primary database becomes the secondary database. The new
secondary replica quickly resynchronizes the new secondary databases with the
corresponding primary databases (Because this is a planned failover, the former
primary replica switches to the secondary role during the failover and brings
its databases online as secondary databases immediately).
ü After
failover, clients must reconnect to the current primary database.
·
手动故障转移形式
o
从数据安全的角度来讲，强制故障转移是一个风险很大的操作。一旦执行了强制故障转移，主副本尚未发送到原来的辅助副本的任何事务日志都会丢失。这意味着，新的主数据库可能会缺少一些最近提交的数据。需要特别注意的是，强制故障转移后，剩余的所有辅助副本上的辅助数据库都处于挂起状态。在最坏的情况下，你可能需要重新初始化所有的辅助副本才能重新恢复可用性组。It is
recommended forcing failover only if you must restore service to your
availability databases immediately and are willing to risk losing data.
3.5. 创建一个alwayson可用性组 118
3.5.1. SSMS
3.5.2. T-SQL
3.5.3. PowerShell
3.6. 可读的辅助数据库 127
3.6.1. 相对数据库镜像，AlwaysOn的一个重要优势就是可以将辅助数据库配置成可读模式。同时，通过AlwaysOn的“只读路由”功能，只读操作可以动态地被转向辅助副本。在一定程度上，可以实现对终端用户透明。
3.6.2. 要让只读操作能“透明”地被自动转向辅助副本，必须解决下面三个问题：
·
客户端要标明自己发来的操作是“只读”操作。这个判定是程序开发员在编写程序的时候，通过ApplicationIntent关键字指定的。而不是SQL Server端来判定的。Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly;MultiSubnetFailover=True
·
辅助数据库要被配成可读模式。
·
客户端的连接，要能够被重定向到可读辅助副本。AlwaysOn是用“只读路由”机制来实现的。你有两种方法来连接可读的辅助数据库。
o
客户端应用可以指定辅助副本的真实实例名，直接连接到该实例上。
o
AlwaysOn有一个叫做的只读路由（Read-Only Routing）的功能。当客户端连接使用Listener的名字来访问SQL Server实例时，只读路由功能可以将来自客户端的只读请求从主副本上自动重定向到可读的辅助副本上去执行。
3.7. 监视Alwayson可用性组的运行状态 133
3.7.1. 系统视图和动态管理视图
·
可用性组所在的Windows故障转移群集：sys.dm_hadr_cluster
etc.
·
可用性组: sys.availability_groups etc.
·
可用性副本:sys.availability_replicas
etc.
·
可用性数据库: sys.availability_databases_cluster
etc
·
可用性组的Listener: sys.availability_group_listeners
etc
3.7.2. 性能计数器
AlwaysOn引入了两个性能监视器的对象：SQLServer:Availability
Replica和 SQLServer:Database Replica。
3.7.3. Dashboard - 用来监视可用性组、副本和数据库的健康状况。
3.7.4. AlwaysOn_health Sessions - AlwaysOn_health会话是SQL Server 2012自带的Extended Events，
3.7.5. SQLDIAG扩展事件日志
sp_server_diagnostics也负责AlwaysOn可用性组的健康状况检查。同样的，sp_server_diagnostics返回的信息依旧会被记录到SQLDIAG日志中。因而我们也可以通过检查SQLDIAG文件中记录的信息来对可用性发生的异常状况进行排查。
3.8. 小结 138 
