sqlserver关于always on的总结

官方文档https://docs.microsoft.com/zh-cn/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-2017

Alwayson相对于数据库镜像最大的优势就是可读副本，带来可读副本的同时还添加了一个新的功能就是配置只读路由实现读写分离
AlwaysOn技术集中了故障转移群集、数据库镜像和日志传送三者的优点，但又不相同。故障转移群集的单位是SQL实例，数据库镜像和日志传送的单位是单个用户数据库，而AlwaysOn支持的单位是可用性组，每个组中可以包括一个或者是多个用户数据库。也就是说，一旦发生切换，则可用性组中的所有数据组会作为一个整体进行切换。
AlwaysOn底层依然采用Windows故障转移群集的机制进行监测和转移，因此也需要先建立Windows Cluster，只不过可用性组中的数据库不一定非要再存放在共享存储上了。可以是存储在本地磁盘上。
各副本推荐使用单机模式的SQL Server，那么数据库副本就存放在该运行该实例节点的本地磁盘上；如果可用性副本是个群集实例，那么数据库副本就存放在共享磁盘上。
可用性组从Windows群集角度来看，就是一个SQL级别的群集资源，其中的所有数据库作为一个整体在节点间进行故障转移，当然这不包括系统数据库，系统数据库是不能加入高可用性组中的。

因为需要借助Windos群集实现监控和转移，所以AlwaysOn会受到一些限制：
一个可用性组中的所有可用性副本必须运行在单一的Windows群集上，跨不同Windows群集的SQL Server实例不能配置成一个AlwaysOn可用性组。
一个可用性组中的所有可用性副本必须运行在Windows群集的不同节点上。运行在同一个节点上的两个不同实例不能用作同一个可用性组的副本。
一个数据库只能属于一个可用性组。
AlwaysOn最多可以支持五个副本，但只有一个可用性副本上运行的数据库是处于可读写状态。这个可读写的数据库被称为主数据库（PrimaryDatabase），同时这个可用性副本被称为主副本（primaryreplica）。其余的副本都被称为辅助副本（secondaryreplica），辅助副本上的数据库可能是不可访问的，或者是只能接受只读操作（取决于可用性组的配置），这些数据库被称为辅助数据库。一但发生故障转移，任何一个辅助副本都可以成为新的主副本实例。主副本会不断地将主数据库上的数据变化发送到辅助副本，来实现副本间的数据库同步。

一些基本概念

FCI：Failover Cluster Instance故障集群实例，FCI是实例层面的而always on是数据库层面的，FCI的概念有点类似ORACLE的RAC，但是实际FCI只有一个实例具备读写的功能
FCI在实例层面运作，而AlwaysOn是在库层面运作。
FCI是迁移服务器硬件，不提供单个或多个数据库的迁移。需要搭配数据库镜像，但是镜像是“单库”、不可读，AlwaysOn可用组是可以以多个库为一个单位迁移，备库可读。
FCI在过去很长时间都是SQL Server的常用高可用技术。它可以在集群的任何可用节点之间进行故障转移。其唯一缺点就是存储。由于需要使用共享存储，所以存储子系统就成了单点故障的风险点。FCI是一个安装在WSFC上的SQL Server 实例，不管是默认实例还是命名实例。这个实例最少需要这几个资源：IP地址、网络名、共享硬盘（N个）、SQL Server服务、SQL Server代理服务。当然这些资源对于单独的实例而言也一样，只是IP地址和网络名是来自于本机，硬盘也属于本机，而FCI则不同。一个两节点的FCI中，SQL Server实例会使用WSFC节点都能可用的共享存储作为SQL Server的存储。通常这次存储是在SAN中划出来的LUN，FCI的部署粗略分为两步
1、在FCI的第一个节点上运行SQL Server安装向导，并选择“新的SQL Server 故障转移群集安装”。完成第一步之后，就可以开始第二步。
2、在WSFC的其他参与节点上运行SQL Server安装向导并选择“向SQL Server故障转移群集添加节点”并完成安装。

WSFC：Windows Server Failover Cluster windows服务故障转移群集，纯粹的OS层面的东西
它是微软高可用技术（HA）的核心组成部分。WSFC跟FCI、AlwaysOn相比，它更多的是Windows Server的一个功能，而后面两个则是SQL Server的功能，同时，WSFC更加底层，在创建SQL Server Failover Cluster Instance、SQL Server AlwaysOn等高可用技术之前，都需要部署和配置WSFC。
WSFC可以把多台计算机节点（纯物理机、纯虚拟机、物理机混合虚拟机）组合在一起并对外部应用程序提供高可用服务。服务器上的一个应用如SQL Server，可以运行在cluster的任何一个节点上，这种运行方式是通过cluster提供一个虚拟访问点（由一个唯一IP地址和一个唯一机器名组成，或者“虚拟网络名”）给客户端程序作为链接方式。地址和虚拟名作为一个应用程序的“资源组”，在多个参与节点之间像令牌形式地被传输。当活动节点出现严重故障时，会使得活动节点停止对外服务。这时候集群服务会自动尝试重启当前节点或伙伴节点的资源组。从高层次的角度来说，客户端的访问点是沿着故障转移伙伴节点中的所有硬盘和服务起源传输的。一个已集群的实例在发生故障转移时，会引发客户端连接的断开，然后在其他节点可用之后马上重连。

可用性组：就是指的DB级别的集群的组名称
每个可用性组定义一个包含两个或更多故障转移伙伴（称为可用性副本）的集合。 “可用性副本”是可用性组的组件。 每个可用性副本都承载可用性组中的可用性数据库的一个副本。 对于某个给定可用性组，可用性副本必须位于某一WSFC群集的不同节点上的单独SQL Server实例上。

可用性副本：就是DB级别的集群中的成员，包含主副本，辅助副本，每个副本由一些数据库组成
对于每个可用性组，一个给定实例只能承载一个可用性副本。 但是，每个实例可用于多个可用性组。 给定的实例可以是独立实例或 SQL Server 故障转移群集实例 (FCI)。
每个可用性副本都被分配一个初始角色（“主角色”或“辅助角色”），角色由该副本的可用性数据库继承。 给定副本的角色确定它承载的是读写数据库还是只读数据库。 其中一个副本（称为“主副本”）被分配主角色，它承载读写数据库（称为“主数据库”）。 至少一个其他副本（称为“辅助副本”）被分配辅助角色。 辅助副本承载只读数据库（称为辅助数据库）。

侦听器
AlwaysOn创建后，客户端就需要进行连接，为了让应用程序能够透明地连接到主副本而不受故障故障转移的影响，我们需要创建一个侦听器，侦听器就是一个虚拟的网络名称，可以通过这个虚拟网络名称访问可用性组，而不用关心连接的是哪一个节点，它会自动将请求转发到主节点，当主节点发生故障后，辅助节点会变为主节点，侦听器也会自动去侦听主节点。
一个侦听器包括虚拟IP地址、虚拟网络名称、端口号三个元素，一旦创建成功，虚拟网络名称会注册到DNS中，同时为可用性组资源添加IP地址资源和网络名称资源。用户就可以使用此名称来连接到可用性组中。与故障转移群集不同，除了使用虚拟网络名称之外，主副本的真实实例名还可以被用来连接。

WSFC名称和listener监听名称都可以当成服务器的别名
1、WSFC名称的ip落在AG哪个节点，通过WSFC就只能连WSFC名称ip落在的那个节点，如果AG节点Sqlserver实例是namedinstance命名实例，WSFC连接的话，还必须写成WSFC\namedinstance模式
比如：WSFC名称EXCHANGEDBCLS，AG主节点EXCHANGEDBALIAS\EXCHANGE端口5170和从节点EXCHANGEDBALIASR\EXCHANGE端口5172的情况下，WSFC名称EXCHANGEDBCLS ip落在哪个节点，则通过WSFC名称EXCHANGEDBCLS\EXCHANGE可以连到哪个节点
WSFC名称EXCHANGEDBCLS，AG主节点EXCHANGEDBALIAS\EXCHANGE端口5170和从节点EXCHANGEDBALIASR端口1433的情况下，WSFC名称EXCHANGEDBCLS落在了从节点，则通过WSFC名称EXCHANGEDBCLS\EXCHANGE无法连接，只能通过WSFC名称EXCHANGEDBCLS连接到从节点(因为从节点没有命名实例)
2、listener名称只能连AG主主节点，listener名称可以直接连因为建立listener时需要指定端口，这个端口会直接映射到AG主节点的Sqlserver实例，AG节点Sqlserver实例是namedinstance命名实例的话，listener连接的话，可以有两种方式，listener和listener\namedinstance模式
比如：AG主节点EXCHANGEDBALIAS\EXCHANGE端口5170和从节点EXCHANGEDBALIASR\EXCHANGE端口5172的情况下，创建了监听EXCHANGEDBLS端口1433，通过监听名称EXCHANGEDBLS只能连到主节点，通过监听名称EXCHANGEDBLS\EXCHANGE也只能连到主节点
AG主节点EXCHANGEDBALIAS\EXCHANGE端口5170和从节点EXCHANGEDBALIASR端口1433的情况下，创建了监听EXCHANGEDBLS端口1433，通过监听名称EXCHANGEDBLS只能连到主节点，通过监听名称EXCHANGEDBLS\EXCHANGE也只能连到主节点

Always on的原理
1、任何一个SQL Server里都有个叫Log Writer的线程，当任何一个SQL用户提交一个数据修改事务时，它会负责把记录本次修改的日志信息先记入一段内存中的日志缓冲区，然后再写入物理日志文件（日志固化）,所以对于任何一个数据库，日志文件里都会有所有数据变化的记录。
2、对于配置为AlwaysOn主副本的数据库，SQL Server会为它建立一个叫Log Scanner的工作线程,这个线程专门负责将日志记录从日志缓冲区或者日志文件里中读出，打包成日志块，发送给各个辅助副本。由于它的不间断工作，才使主副本上的数据变化，可以不断地向辅助副本上传播。
3、在辅助副本上，同样会有两个线程，完成相应的数据更新动作，它们是固化（Harden）和重做（Redo）。固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本的磁盘上的日志文件里（这个过程被称为"固化"）。而重做线程，则负责从磁盘上读取日志块，将日志记录翻译成数据修改操作，在辅助副本的数据库上完成。当重做线程完成其工作以后，辅助副本上的数据库就会跟主副本一致了。AlwaysOn就是通过这种机制，保持副本之间的同步。重做线程每隔固定的时间点，会跟主副本通信，告知它自己的工作进度。主副本就能够知道两边数据的差距有多远。这些线程在工作上各自独立，以达到更高的效率。Log Scanner负责传送日志块，而无须等待Log Writer完成日志固化；辅助副本完成日志固化以后就会发送消息到主副本，告知数据已经传递完毕，而无须等待重做完成。其设计目标，是尽可能地减少AlwaysOn所带来的额外操作对正常数据库操作的性能影响。
4、同步提交模式的维护方式：从客户端收到事务后，主副本会将事务的日志写入事务日志，同时将该日志记录发送到辅助副本。日志记录写入主数据库的事务日志后，事务将不能撤消，除非在此时故障转移到尚未收到该日志的辅助副本。主副本将等待来自同步提交辅助副本的确认。辅助副本将强制写入日志（固化），并将确认消息返回给主副本。收到来自辅助副本的确认后，主副本将完成提交处理并向客户端发送一条确认消息。在同步提交可用性模式下，副本联接到某个可用性组后，辅助数据库就会与对应的主数据库求得一致并进入 SYNCHRONIZED（已同步）状态。 只要一直在进行数据同步，辅助数据库就会保持 SYNCHRONIZED 状态。 这可确保对主数据库提交的每个事务也应用到对应的辅助数据库。在同步辅助副本上的每个辅助数据库之后，辅助副本的同步运行状态总体上将为 HEALTHY。
5、异步提交模式的维护方式：如果每个辅助副本都在异步提交模式下运行，则主副本不会等待任何辅助副本强制写入日志， 而会在将日志记录写入本地日志文件后，立即将事务确认发送到客户端。由于主副本不会等待来自辅助副本的确认，因而辅助副本上的问题从不会影响主副本，辅助数据库就会保持 SYNCHRONIZING 状态。对于主副本和辅助副本相隔很远而且您不希望小错误影响主副本的灾难恢复方案的情况，或性能比同步数据保护更重要的情况，异步提交模式将会很有用。异步提交辅助副本会尝试与接收自主副本的日志记录保持一致，但异步提交辅助数据库往往会保持未同步状态，通常异步提交辅助数据库和相应的主数据库之间的这个时间差会很小。但是，如果承载辅助副本的服务器的工作负荷过高或网络速度很慢，则这个时间差会变得较大。
6、会话超时机制：由于软错误不能由服务器实例直接检测到，因此，软错误可能导致一个可用性副本无限期等待会话中另一个可用性副本的响应。 为了防止发生这种情况， Always On 可用性组实施了会话超时机制，此机制基于以下条件：所连接的可用性副本会在每个打开的连接上按固定间隔发送 ping。 在超时期限内收到 ping 指示连接仍是开放的且服务器实例正在通过此连接进行通信。 收到 ping后副本将重置此连接上的超时计数器。主副本和辅助副本相互 ping 以指示它们仍处于活动状态， 会话超时限制是用户可配置的副本属性，默认值为 10 秒。如果在会话超时期限内没有收到来自另一个副本的ping，该连接将超时、连接将关闭；超时的副本进入 DISCONNECTED 状态。 即使为同步提交模式的副本，事务也将不等待该副本重新连接暂时将该辅助副本切换到异步提交模式。在该辅助副本重新与主副本连接后，它们将恢复同步提交模式。

仲裁配置的三种方式：
1、不配置仲裁见证：就是少数服从多数，正常节点数量占多数的情况下，集群才会提供服务，否则就停止服务。例如5个节点的集群，其正常节点数量必须至少3个，集群才会提供服务
2、配置磁盘见证：适用于偶数节点的集群，他在计算法定数量时会将仲裁磁盘计算进来，例如，4个节点+1个仲裁磁盘节点的集群，可以将其视为5个节点的集群，这时正常节点数量必须至少3个，集群才会提供服务
3、配置共享文件见证：它和配置磁盘见证类似，不过磁盘改为共享文件夹内的文件

创建WSFC
Server Manager—Manage–Add Roles and Features Wizard–Features–Failover Clustering
Failover Clustering安装后，节点上的service.msc界面出现了Cluster Service服务且是Disabled状态和Stop状态,Cluster Service服务指向C:\Windows\Cluster\clussvc.exe -s，此时还没有操作系统用户CLIUSR

Failover Cluster Manager–Validate Configuration
Failover Cluster Manager–Create Cluster
Create Cluster的过程中需要指定Cluster Name和IP(woncntestdbcls和172.22.136.143)，如果创建Create Cluster时使用的账户有DNS管理员权限，那么可以直接在Create Cluster创建的界面中指定Cluster Name和IP(比如woncntestdbcls和172.22.136.143)，这个Cluster Name和IP(比如woncntestdbcls和172.22.136.143)会自动在DNS中建立。如果创建Create Cluster时使用的账户没有DNS管理员权限，则需要先在DNS创建一条DNS记录(比如woncntestdbcls和172.22.136.143)，再在Create Cluster创建的界面中指定Cluster Name和IP(woncntestdbcls和172.22.136.143)，WSFC名称比如为woncntestdbcls的Cluster建立好后，节点上的service.msc界面中的Cluster Service服务是Automatic状态和Running状态且自动创建了一个操作系统用户CLIUSR

创建共享文件认证
Failover Cluster Manager–woncntestdbcls–More Actions–Configure Cluster Quorum Settings–Advanced quorum configuration–Configure a file share witnesss

Always on的搭建
1、primary、secondary节点实例的所有服务器都必须先在os上安装好故障转移集群Failover clustering功能，一旦其中某台服务器没有安装，则创建故障转移集群时会报错the server ‘XX’ does not have the failover clustering feature installed。OS安装了故障转移集群功能的话Server Manager–Manage–add roles and feature–feature–failover clustering，才会出现server manager–tools–Failover cluster manager
2、primary、secondary节点实例的服务器需要加入同一个域中
3、创建Windows服务器故障转移集群(Windows Server Failover Cluster)时，只在其中某台服务器比如只在primary节点实例的服务器创建即可，给集群起个名字和分配一个ip，并把所有的节点服务器加入故障转移集群中即可(这些加入的服务器需要加上域名后缀)，此时千万不要勾选“将所有符合条件的存储添加到群集”，否则primary、secondary节点实例的服务器原来挂载的存储目录会消失。
4、配置集群仲裁选择共享文件仲裁时，不能使用任意节点服务器本地的目录（File share associated with file share witness resource cannot be hosted by this cluster or any of its nodes）
5、每个节点的sqlserver服务都要启用always on的功能，这个功能开启后需要重启sqlserver服务以便生效
Sql Server Configuration Manager–SQL Server Serivces–SQL Server(MSSQLSERVER)–右键选择Properties–Awayson High Availability–Enable AlwaysOn Availability Groups
6、在主节点数据库实例上配置always on，实例–Always On High Availability–右键选择New Availablity Group Wizard新建可用性组
备注：不要选择New Availability Group(SQL实例–AlwaysOn High Availability–New Availability Group)，这样建立的AG没有连接和验证的步骤，导致AG中的主节点online从节点offline，重启从节点这个故障依旧
7、数据库加入always on可用性组时，右键高可用组名称–add database即可，但是必须对primary节点的实例的数据库进行full备份和log备份，并把full备份和log备份以norecovery模式恢复到secondary节点的实例
备注：需要留意主副本机器和各个辅助副本机器的扇区是否一致，如果扇区不一致有可能导致同步慢，那么最好不要搭建AlwaysOn

Always on 的手工故障转移的操作步骤
实例–AlwaysOn High Availablility–Availability Groups–命名的AG–右键–Failover
如果是AG的availablity mode是sync，则转移过程中不会出现丢数据的提升
如果是AG的availablity mode是async，则转移过程中会出现丢数据的提升

AG主节点因为操作系统故障而挂掉，数据盘没有问题的情况下，如何恢复？
1、主节点重新安装操作系统并挂载之前主节点的磁盘(含系统数据库和用户数据库的文件)，重新安装实例名称一样的新装实例，关闭新装实例，备份当前新装实例的系统数据库，重新使用旧实例的系统数据库来启动，旧实例可以启动但是所有的在AG里面的用户数据库都不正常显示recovery pending，error日志中的报错信息是AG配置不对，重新使用新装实例的系统数据库，把旧实例AG里面的的用户数据库一个个加载上来，这些用户数据库也都不正常显示recovery pending
–所以方法1是不可行的，也就是没法把因为操作系统故障场景下的存在AG里面的用户数据库附加到单节点实例上。
2、从节点，移除WSFC和AG，这样之前AG里面的的用户数据库都会显示restoring状态，再restore db with recovery，然后更改从节点的服务器名和sqlserver servername和原来的主节点一样(或把主节点的dns名称映射成从节点的服务器名称)，把它当成单节点来使用，这样开发团队不用更改数据库连接字符串，后面再搭建AG
–方法2可行

AG的sqlserver在WSFC集群2节点的情况下，一个节点故障再也起不来，且这个节点是主节点，客户端连接数据库的时候没有使用监听器而是直接使用了主节点的服务器名，这个时候我们只能AG拆掉并把从节点的服务器名和ip改成主节点，这样客户端的配置不用改的情况下还能继续连接数据集。但是后面我们想重建一台新的从节点，并把新的从节点和现在所谓的主节点(之前的从节点)重建WSFC和AG，怎么操作呢？
实验步骤
1、woncntestdb3 172.22.136.135和woncntestdb4 172.22.136.137已经是一个WSFC集群了，cluser名称为woncntestdbcls
2、关闭woncntestdb3 172.22.136.135并彻底废弃
3、把woncntestdb4 172.22.136.137修改成woncntestdb3 172.22.136.135
4、新装操作系统woncntestdb4 172.22.136.137，并安装Failover Clustering功能，暂时不做任何操作
5、在新的woncntestdb3 172.22.136.135上面看到woncntestdbcls正常但是有故障(左小角显示红色X叉)，里面有两个节点，节点woncntestdb3 172.22.136.135正常，woncntestdb4 172.22.136.135不正常(woncntestdb4显示的ip不是172.22.136.137而是172.22.136.135)
6、在新的woncntestdb4 172.22.136.137上可以连到woncntestdbcls，看到woncntestdbcls正常但是有故障(左小角显示红色X叉)，里面有两个节点，节点woncntestdb3 172.22.136.135正常，woncntestdb4 172.22.136.135不正常
7、在新的woncntestdb3 172.22.136.135上面的Failover Cluster Manager上执行shutdown cluster(其实就是启动各个节点services.msc上的Cluster Service服务)，start cluster报错：Cannot start service Clussvc on computer’woncntestdb4’.The service cannot be started,either because it is disabled or because it has no enabled devices associated with it。woncntestdbcls完成不正常(左小角显示红色向下的箭头)，看不到任何节点
8、新的woncntestdb3 172.22.136.135上面MSDTC异常，报错DCOM was unable to communicate with the computer woncntestdbcls.dai.netdai.com using any of the configured protocols。
dcomcnfg–Component Services–Computers–My Computer–Distributed Transaction Coordinator看到一个Local DTC，一个Clusterd DTCs，dcomcnfg–Component Services–Computers–My Computer右键刷新的时候报错
9、重启woncntestdb3， woncntestdb3172.22.136.135上面MSDTC还是无法恢复
10、woncntestdb3 172.22.136.135移除"Failover Clustering"功能后，操作系统用户CLIUSR还在，services.msc中Cluster Service服务已经不存在了，重新在woncntestdb3上添加"Failover Clustering"功能，woncntestdb3和 woncntestdb4可以重新创建WSFC，并且可以重新创建名称为woncntestdbcls的WSFC集群

Always on的总结
1、primary节点数据库创建的表、索引，会自动同步到secondary节点的数据库
2、always on要求各个节点对应的操作系统版本必须一致，但是数据库版本可以不一致，比如数据库一个是sqlserver2014 sp2，一个是sqlserver2014 sp3
3、搭建always on时，各个节点的实例名称@@servername不需要一致
4、关于IP，一个是windows故障转移集群ip，OS级别的IP，外部可以通过这个ip登录故障转移集群中中的任意一台服务器。一个是alwayson侦听IP，是数据库实例级别的IP，外部可以通过这个ip连上always on的任意一个数据库实例，类似oracle的scan ip.这两个ip对应的dns记录都不需要预先在dns服务器中创建，而是在建立windows故障转移集群ip(这个过程需要输入WFC名称和ip)和alwayson侦听IP(这个过程需要输入监听名称和ip)时会自动在dns服务器中创建
5、primary或secondary节点的数据库都不能执行脱机操作，执行脱机操作会报错：The operation cannot be performed on database ‘XX’ because it is involved in a database mirroring session or an availability group
6、primary或secondary节点的数据库都不能执行分离操作，执行分离操作会报错：The database ‘XX’ is currently joined to an availability group，before you can drop the database，you need to remove it from the availability group
7、同步提交即AG的属性Availability Mode选择Synchronous commit时，primary节点的数据库后面状态显示(Synchronized)，secondary节点的数据库后面状态显示(Synchronized)，异步提交即AG的属性Availability Mode选择Asynchronous commit时，primary节点的数据库后面状态显示(Synchronized)，secondary节点的数据库后面状态显示(Synchronizing)
8、primary节点的数据库新增一个数据文件，secondary节点的数据库也会新增一个数据文件，且路径和primary节点的数据库的一模一样，就算secondary节点的数据库设置了默认路径也会忽略，比如secondary节点的数据库的默认路径是G:\DEFAULT.DATA，primary节点的数据库新增文件的路径是L:\data1.dbf，secondary节点的数据库该文件路径也是L:\data1.dbf，而非G:\DEFAULT.DATA\data1.dbf，所以primary节点的数据库新增一个数据文件，secondary节点的数据库服务器没有一样的路径，secondary节点的数据库会报错，always on的同步会中断
9、always on没有正常同步，具体的处理思路是先查看primary、secondary节点的实例sqlserver log日志，看具体是什么问题
10、Always on的可用性组中移除某个数据库的操作
以下两条都在primary组里面操作
1、先在可用性组里面找到该数据库右键点击暂停数据传输
2、再在可用性组里面找到该数据库右键点击移除出AG
或
ALTER DATABASE database_name SET HADR OFF
11、主节点把数据库从AG移除了，辅助节点的AG里面也看不到该数据库，但是辅助节点该数据库还存在且状态显示(Not Synchronzing)，这种情况说明辅助节点该数据库还是在AG中，主节点执行ALTER DATABASE dbname SET HADR OFF报错说该数据库不存在，辅助节点执行ALTER DATABASE dbname SET HADR OFF不报错但是一直等待，等待一个后台进程。
引发原因1：主节点的日志磁盘比辅助节点的日志磁盘空间大，导致主节点的日志没有完全同步到辅助节点，辅助节点的磁盘空间就爆掉了，而且此时主节点也没有办法收缩日志，所以只能从AG中取消该数据库，主节点在AG中移除该数据库后辅助节点AG里面也看不该数据库了，但是辅助节点该数据库还存在且状态是显示(not synchronizing未同步)
引发原因2：有需求要把某个数据库移除出AG，再在主库备份，再拿到从库还原，继续添加到AG，这时这个数据库已经不在可用性组里面了，主库上这个数据库后面没有了(Synchonized)，但是从库这个数据库后面还显示(Not Synchonizing)，导致从库无法删除这个数据库也没有对这个数据库进行restore，从库报错信息：unable to accesss availability database ‘XXX’ because the database replica is not in the primary or secondary role.
处理方法1：没有好方法，只能一直等待，等待辅助节点该数据库状态变成(restoring恢复中)，如果嫌等待时间太长考虑方法2
处理方法2：重启从库，从库这个数据库状态显示 (Not Synchonizing/In Recovery)，再在从库执行ALTER DATABASE database_name SET HADR OFF，此时从库这个数据库状态显示 (restoring)，可以删除了
12、辅助节点某个数据库显示Not Synchonizing，辅助节点的AG里面数据库显示异常，出现红色标记，右键无法显示resume，解决方法：直接在主节点上移除，然后再添加就行
主节点实例上该数据库显示synchronized
副节点实例上该数据库显示not synchronizing，副节点-Always On High Availability-Availability Groups-AG名称(Secondary)-Availability Databases-数据库名称-数据库右下角显示红色，右键这个数据库无法显示resume，只有suspend、remove这几个
13、always on主本或副本的所有数据库的状态都是Not Synchonizing，可用性组显示resolving，它下面的某个副本也显示resolving，解决方法就是重启这个状态为resolving的服务器
14、辅助节点某个数据库显示Not Synchronizing In Recovery，辅助节点的AG下这个数据库显示蓝色标记的处理方法：在该辅助节点Always On High Availability–Availability Groups–Availability Databases下面找到报错的数据库显示为蓝色标记，右键选择Resume Data Movement,这个时候报错的数据库显示为红色标记，过一会就开始同步了
15、辅助节点某个数据库显示Not Synchronizing的处理总思路，只要主副本没有传输到辅助副本的日志没有丢失，主副本还保留了这份日志，这个问题就很简单，要么在辅助节点上选择Resume Data Movement如上14，要么就在主节点上移除该数据库，再把主节点数据库的日志拿到辅助节点去restore，restore完后，再重新添加即可
16、选项readable secondary可读取辅助副本的问题：虽然主节点也选择了no表示不可执行select语句，但是主节点依然可以执行select，因为这个选项只对辅助副本生效，对主副本无效
17、always on的主库做增量备份的时候，居然会使主库的日志无法重用导致日志无法截断，日志暴涨，原因就是select name,log_reuse_wait_desc from sys.databases第二个字段log_reuse_wait_desc值出现"活动备份或还原"就会影响日志截断，和always on本身没有任何关系
18、always on 取消后，windows的MDSTC服务出故障:MSDTC on server ‘XX’ is unavailable的案例，故障一般是无法通过linked server访问该节点，报错为The current transaction cannot be committed and cannot support operations that write to the log file. Roll back the transaction. [SQLSTATE 42000] (Error 3930) OLE DB provider “SQLNCLI11” for linked server “marketdata” returned message “No transaction is active.”
因为创建WSFC后，dcomcnfg–Component Services–Computers–My Computer–Distributed Transaction Coordinator看到一个Local DTC，一个Clusterd DTCs
组件服务 -> 计算机 -> 我的电脑，显示红色箭头的处理流程
18.1、在主节点取消always on后，最好不要去动windows OS的配置，即不要关闭主节点在windows故障转移集群中状态
18.2、在主节点取消always on后，如果主节点在windows故障转移集群显示offline，但是副节点在windows故障转移集群显示online，尝试把主节点在windows故障转移集群显示为online，看红色箭头是否消失
18.3、如果上面2不行，则在主节点关闭整个windows故障转移集群，看两个节点是否都显示offline，看红色箭头是否消失
18.4、如果上面3不行，再在主节点把windows故障转移集群启动，看两个节点是否都显示online，看红色箭头是否消失
18.5、如果上面4不行，则尝试重启主节点服务器，重启后，看红色箭头是否消失
18.6、如果是因为本节点升级操作系统导致本节点上的WSFC无法正常使用或其他节点宕机再也无法启动从而导致本节点上的WSFC无法正常使用，从而引发MSDTC故障，这个时候无法启动WSFC也无法重启解决，只能卸载Failover Clustering功能来保住MSDTC功能，解决方法：在该节点移除"Failover Clustering"功能，Server Manager–Manage–Remove Roles and Features Wizard
19、AG的辅助副本正在执行logshipping的backup log时，主副本手工执行backup log会被堵塞，被堵塞的原因是在等待事件类型是HADR_BACKUP_QUEUE的进程，其实就是AG的主副本不同同时备份日志
20、AG的辅助副本实例，配置了logshipping到其他服务器，这个辅助副本实例上的backup log job报错
The backup operation on database ‘TESTDB’ was skipped because it is part of an availability group and not its preferred backup replica.
解决方法
20.1、确保辅助副本的实例名和机器名一致
20.2、在always on可用性组中的备份首选项中设置为任意副本，且辅助副本的备份优先级高于主副本，比如设置辅助副本为51，主副本为50
21、always on的主副本节点A1搭建logshipping到C服务器，报错The backup operation on database ‘DB’ was skipped because it is part of an availability group and not its preferred backup replica.(因为它是一个可用性组和不其首选的备份副本的一部分，跳过了数据库’数据库名称’’ 上的备份操作)
报错原因：A1是主副本节点，而AG设置的备份首选项是prefer secondary，所以A1是没有办法备份日志的，需要在A2这个辅助副本上搭建logshipping到C服务器
继续出现的问题：现在A2开始logshipping备份日志了，但是A1也可以执行BACKUP LOG [DB] TO DISK = N’\log\DB_LOG_YYMMDDMi.bak’
继续出现的问题:C服务器有两个restore job了，但是来自A2的restore job有报错*** Error: Could not log history/error message.(Microsoft.SqlServer.Management.LogShipping) ***
*** Error: The specified agent_id 27A07B67-19A6-4BA1-A05D-52CC968B479C or agent_type 2 do not form a valid pair for log shipping monitoring processing.(.Net SqlClient Data Provider) ***
最后解决方法是
21.1、A1也搭建logshipping，但是A11本机所有的job都是disable，但是C服务器上的job是enable
21.2、A2也搭建logshipping，A2所有的job都enable，但是C服务器上的job是disable
21.3、A1实例开启backup log，但是备份脚本里面排除logshipping的数据库msdb.dbo.log_shipping_primary_databases
22、AG搭建的logshipping如上例21，辅助副本A2的logshipping的备份job报错First attempt to backup database ‘ECMDB’ to file ‘\YY\ZZ.trn’ failed because Log backup for database “ECMDB” on a secondary replica failed because the last backup LSN (0x000cb1e0:02c34336:0001) from the primary database is greater than the current local redo LSN (0x000cb1e0:02c342e1:0155). No log records need to be backed up at this time. Retry the log-backup operation later. 检查了AG两个节点之间的日志传输是正常的，没有延迟，重启辅助副本节点A2的sqlserver服务，发现辅助副本节点A2的logshipping的备份job也报和主副本节点A1一样的错误The backup operation on database ‘ECMDB’ was skipped because it is part of an availability group and not its preferred backup replica.
至此找到原因，是因为AG主副本节点辅助副本节点之间传输可能出现问题，导致辅助副本节点A2一直跟不上主副本节点A1，解决方法
22.1、把ECMDB数据库从AG中移除，对主副本节点A1的日志进行备份
22.2、把主副本节点A1备份的日志拿到辅助副本节点A2去恢复，也拿到logshipping的服务器C上去恢复
22.3、重新把ECMDB数据库加入AG，至此辅助副本节点A2的logshipping的备份job正常了
24、AG创建AG listener报错Access is denied的处理方法：
WFC的名称是IBDMMDBCLS，创建好了名称为IBDMMDBAG的AG后，在AG里面创建名称为IBDMMDBLS的AG listener出现报错，报错信息在WFC的error日志中如下
Cluster network name resource ‘IBDMMDBAG_IBDMMDBLS’ failed to create its associated computer object in domain ‘dai.netdai.com’ during: Resource online.
The text for the associated error code is: Access is denied.
Please work with your domain administrator to ensure that:
The cluster identity ‘IBDMMDBCLS${}^{\prime }hasCreateComputerObjectspermissions.Bydefaultallcomputerobjectsarecreatedinthesamecontainerastheclusteridentit{y}^{\prime }IBDMMDBCLS$’.
The quota for computer objects has not been reached.
If there is an existing computer object, verify the Cluster Identity ‘IBDMMDBCLS$’ has ‘Full Control’ permission to that computer object using the Active Directory Users and Computers tool.
官方文档的解释https://docs.microsoft.com/en-us/archive/blogs/psssql/error-during-installation-of-an-sql-server-failover-cluster-instance
The common cause of the Network Name resource failure is insufficient permissions. More specifically, the permission “Create Computer Objects” has not been granted to the Cluster Name Object(CNO).
When the SQL Server Network Name is first brought online during the FCI installation process, the CNO identity is used to create the VCO(as long as the VCO doesn’t already exist). If the required permissions are not granted to the CNO, the creation of the VCO will fail and so will your SQL Server FCI installation.

翻译：Network Name资源失败的常见原因是权限不足。更具体地说，“创建计算机对象”的权限还没有授予集群名称对象(CNO)。
在FCI安装过程中，当SQL Server Network Name首次上线时，使用CNO标识创建VCO(只要VCO还不存在)。如果没有将所需的权限授予CNO, VCO的创建将失败，SQL Server FCI安装也将失败。
Cluster Name object (CNO) 即WFC的名称IBDMMDBCLS
Virtual Computer Object (VCO)，即AG listener的名称IBDMMDBLS
解决方法：在域控环境找到IBDMMDBCLS用户(非报错信息中的IBDMMDBCLS$，其实这个$在域控中是不存在的)，给他授权full control或把它添加到有full control的组，之后再在AG里面创建AG listener不再报错，AG listener创建成功后，可以在域控移除IBDMMDBCLS用户用户的权限，不影响已经已有的WFC和AG listener
25、如果可用性组显示resolving，它下面的某个副本也显示resolving，重启服务器也无法解决这个问题时，使用Get-ClusterResource命令查看WFC下面哪个资源failed，也右键WFC选择validate cluster再选择view validation report查看WFC故障明细，如果短时间内实在无法解决，如下两种方法都可以让数据库可用
25.1、禁用cluster，右键WFC选择shut down cluster把cluster禁用，这样数据库的AG就中断了，就可以把数据库AG的主节点当成单节点来使用，不过这样做的话AG从节点就无法做任何用途，最后还得重建AG才能用上AG的从节点
25.2、重建AG，首先在数据库实例层面删除AG，然后在操作系统的WFC中cluster可以看到role AG已经消失了，AG中的所有节点中的数据库都变成单节点了，主节点数据库是读写状态后面没有syncrihzoned状态，从节点数据库后面状态从syncrihzoning变成restoring了
26、AG两个节点同时升级操作系统到Windows2019后看到数据库Recovery Pending，Stop cluser后看到AG消失不见了，数据库还是有问题Recovery Pending，然后发现启用clster后，AG还是不见，数据库还是有问题。解决方法：只能通过移除AG(虽然过程会报错但是还是可以移除)再对数据库offline在对数据库online来实现

Always on的备份

问题：关于日志备份，我们都知道事物日志备份会截断日志链，假如我在任意副本上执行了日志备份，那么其他副本的日志是否也会一起截断？
答案：是的，一个副本执行日志备份，其他副本会自动截断，只要主节点和辅助节点直接正常通信，不管怎么设置，日志都是可以备份的，可以在主节点备份，也可以在辅助节点备份，只是不能同时备份，不管在哪个节点备份，都会截断所有节点的日志
其实只要在“备份首选项”（可用性组，右键，属性，）指定的数据库实例上“备份事务日志”即可将事务日志备份并截断

AG的主副本备份执行如下，都正常
backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db1_alwayson1_full.bak’
backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db1_alwayson1_diff.bak’ WITH DIFFERENTIAL
backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\db1_alwayson1_log2.bak’

AG辅助副本上支持的备份类型
1、BACKUP DATABASE ：在辅助副仅支持数据库、文件或文件组的仅复制完整备份。请注意，仅复制备份不影响日志链，也不清除差异位图。
2、辅助副本不支持差异备份(不过实验发现加了with differential,copy_only的话也可以备份)
3、BACKUP LOG 仅支持常规日志备份（辅助副本上的日志备份不支持 COPY_ONLY 选项）。
4、若要备份辅助数据库，辅助副本必须能够与主副本进行通信，并且状态必须为 SYNCHRONIZED 或 SYNCHRONIZING。否则会报错Cannot backup from a HADRON secondary because it is not in Synchronizing or Synchronized state.
注意:在分布式可用性组中，可以对与活动主要副本相同的可用性组中的次要副本执行备份，或对任何次要可用性组的主要副本执行备份。 无法对次要可用性组中的次要副本执行备份，因为次要副本仅与其可用性组中的主要副本通信。 仅直接与全局主要副本通信的副本才能执行备份操作。

AG的辅助副本备份执行如下，报错(无法备份数据库)
backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_full.bak’
backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_diff.bak’ WITH DIFFERENTIAL
出现如下报错：
This BACKUP or RESTORE command is not supported on a database mirror or secondary replica.

AG的辅助副本备份执行如下，正常备份(可以备份日志)
backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_log.bak’

AG的辅助副本备份执行如下，报错(日志备份不支持COPY_ONLY)
backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_log.bak’ with copy_only

AG的辅助副本备份执行如下，都正常(数据库备份只支持copy_only)
backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_full.bak’ with copy_only
backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_diff.bak’ WITH DIFFERENTIAL ,copy_only
backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_log2.bak’

实例–Always On 高可用性–可用性组–可用性组名–右键–属性—备份首选项

优先辅助副本(默认选项)
指定备份应在辅助副本上发生，没有联机可用的辅助副本时，备份应在主副本上发生。

仅辅助副本
指定备份只发生在辅助副本，没有联机可用的辅助副本时，则备份不会发生。

主副本
指定备份应该始终在主副本上发生。

任意副本
指定您希望在选择要执行备份的副本时备份作业将忽略可用性副本的角色。此选项下面还有一个副本备份优先级的设置，1位最低，100为最高，默认是情况下主副本和辅助副本都是50。

以上，四种选项的结果，也可以通过sys.fn_hadr_backup_is_preferred_replica函数查询出来，如果当前数据库是首选备份副本，则返回 1。
比如SELECT sys.fn_hadr_backup_is_preferred_replica (‘testdb’)结果为1，则此实例的testdb是可用性组中的首选备份副本