官方文档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，
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地址资源和网络名称资源。 侦听器包括虚拟IP地址、虚拟网络名称、端口号三个要素，一旦成功创建，虚拟网络名称将注册DNS同时添加可用组资源IP地址资源和网络名称资源。用户可以使用该名称连接到可用组。与故障转移集不同，主副本的真实例名除了使用虚拟网络名称外，还可以用来连接。 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、配置共享文件见证：它和配置磁盘见证类似，不过磁盘改为共享文件夹内的文件 Always on的搭建 网上手把手的教程网址https://www.linuxidc.com/Linux/2017-01/139766.htm 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新建可用性组 7、数据库加入always on可用性组时，右键高可用组名称–add database即可，但是必须对primary节点的实例的数据库进行full备份和log备份，并把full备份和log备份以norecovery模式恢复到secondary节点的实例 备注：需要留意主副本机器和各个辅助副本机器的扇区是否一致，如果扇区不一致有可能导致同步慢，那么最好不要搭建AlwaysOn 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的案例 组件服务 -> 计算机 -> 我的电脑，显示红色箭头的处理流程 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不行，则尝试重启主节点服务器，重启后，看红色箭头是否消失 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 ' has Create Computer Objects permissions. By default all computer objects are created in the same container as the cluster identity 'IBDMMDBCLS ′hasCreateComputerObjectspermissions.Bydefaultallcomputerobjectsarecreatedinthesamecontainerastheclusteridentity′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了 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是可用性组中的首选备份副本 ———————————————— 版权声明：本文为CSDN博主「lusklusklusk」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/lusklusklusk/article/details/115178580