为您推荐:
精华内容
最热下载
问答
  • 5星
    6.86MB guoruibin123 2021-08-09 09:46:03
  • 5星
    4.5MB GJZGRB 2021-04-13 10:37:48
  • alwayson 同步暂停的情况下,是否主节点和辅助节点都可以同时备份日志 主副本:正常备份 辅助副本:备份日志报错:Cannot backup from a HADRON secondary because it is not in Synchronizing or Synchronized ...

    alwayson 同步暂停的情况下,是否主节点和辅助节点都可以同时备份日志
    主副本:正常备份
    辅助副本:备份日志报错:Cannot backup from a HADRON secondary because it is not in Synchronizing or Synchronized state.
    备份数据库不加COPY_ONLY报错:This BACKUP or RESTORE command is not supported on a database mirror or secondary replica.

    always on各种备份首选项时,备份的总机
    1、不管怎么设置,正常的数据库备份(full backup、diff backup)只能在主节点进行
    2、辅助副本要支持数据库备份,必须在backup后面加上COPY_ONLY选项,也就是其实辅助副本不支持正常的数据库备份
    3、只要主节点和辅助节点直接正常通信,不管怎么设置,日志都是可以备份的,可以在主节点备份,也可以在辅助节点备份,只是不能同时备份,不管在哪个节点备份,都会截断所有节点的日志
    4、如果主节点和辅助节点之间的同步断了,辅助节点无法执行日志备份

    辅助副本上支持的备份类型
    1、BACKUP DATABASE 在次要副本上执行时仅支持数据库、文件或文件组的仅复制COPY_ONLY完整备份。 请注意,仅复制备份不影响日志链,也不清除差异位图。
    2、辅助副本不支持差异备份。
    3、BACKUP LOG 仅支持常规日志备份(次要副本上的日志备份不支持 COPY_ONLY 选项)。对于在任何副本(主副本或辅助副本)上进行的日志备份之间,确保一致的日志链,而与其可用性模式(同步提交或异步提交无关)。
    4、若要备份辅助数据库,辅助副本必须能够与主副本进行通信,并且状态必须为 SYNCHRONIZED 或 SYNCHRONIZING。

    应在何处进行备份?
    优先辅助
    指定备份应在辅助副本上发生,但在主副本是唯一联机的副本时除外。 在该情况下,备份应在主副本上发生。 这是默认选项。

    仅辅助
    指定备份应该永远不会在主副本上执行。 如果主副本是唯一的联机副本,则备份应不会发生。


    指定备份应该始终在主副本上发生。 如果您需要在对辅助副本运行备份时不支持的备份功能,例如创建差异备份,此选项将很有用。

    任何副本
    指定您希望在选择要执行备份的副本时备份作业将忽略可用性副本的角色。 请注意,备份作业可能评估其他因素,例如每个可用性副本的备份优先级及其操作状态和已连接状态。

    副本备份优先级
    此网格将显示每个承载可用性组的副本的服务器实例的当前备份优先级。 使用此网格可以更改一个或多个可用性副本的备份优先级。

    服务器实例
    承载可用性副本的 SQL Server 实例的名称。

    备份优先级(最低 = 1,最高 = 100)
    指定相对于同一可用性组中的其他副本,在此副本上执行备份的优先级。 该值是范围 0…100 中的整数。 1 表示最低优先级,100 表示最高优先级。 如果“备份优先级”= 1,则仅在当前没有更高优先级的可用性副本可用时,才选择此可用性副本来执行备份。

    排除副本
    如果从不希望选择此可用性副本来执行备份,请选择此选项。 例如,这对于您永远不希望备份故障转移到的远程可用性副本十分有用。

    辅助副本是readable secondary的情况下
    优先辅助(主、辅助副本优先级都是50)

    主副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\alwayson1_full_20190902_00001.bak’
    正常备份

    辅助副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_full_20190902_00001.bak’
    This BACKUP or RESTORE command is not supported on a database mirror or secondary replica.

    优先辅助(主副本优先级是100,辅助副本优先级是50)
    主副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\alwayson1_full_20190902_00002.bak’
    正常备份

    辅助副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_full_20190902_00002.bak’
    This BACKUP or RESTORE command is not supported on a database mirror or secondary replica.

    优先辅助(主副本优先级是50,辅助副本优先级是100)
    主副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\alwayson1_full_20190902_00003.bak’
    正常备份

    辅助副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_full_20190902_00003.bak’
    This BACKUP or RESTORE command is not supported on a database mirror or secondary replica.

    仅辅助(主副本优先级是100,辅助副本优先级是50)
    主副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\alwayson1_full_20190902_00004.bak’
    正常备份

    辅助副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_full_20190902_00004.bak’
    This BACKUP or RESTORE command is not supported on a database mirror or secondary replica.

    仅辅助(主副本优先级是50,辅助副本优先级是100)
    主副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\alwayson1_full_20190902_00005.bak’
    正常备份

    辅助副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_full_20190902_00005.bak’
    This BACKUP or RESTORE command is not supported on a database mirror or secondary replica.

    主(主副本优先级是50,辅助副本优先级是100)
    主副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\alwayson1_full_20190902_00006.bak’
    正常备份

    辅助副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_full_20190902_00006.bak’
    This BACKUP or RESTORE command is not supported on a database mirror or secondary replica.

    主(主副本优先级是100,辅助副本优先级是50)
    主副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\alwayson1_full_20190902_00007.bak’
    正常备份

    辅助副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_full_20190902_00007.bak’
    This BACKUP or RESTORE command is not supported on a database mirror or secondary replica.

    任何副本(主副本优先级是50,辅助副本优先级是100)
    主副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\alwayson1_full_20190902_00008.bak’
    正常备份

    辅助副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_full_20190902_00008.bak’
    This BACKUP or RESTORE command is not supported on a database mirror or secondary replica.

    任何副本(主副本优先级是100,辅助副本优先级是50)
    主副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\alwayson1_full_20190902_00009.bak’
    正常备份

    辅助副本
    backup database alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_full_20190902_00009.bak’
    This BACKUP or RESTORE command is not supported on a database mirror or secondary replica.

    辅助副本是readable secondary的情况下
    任何副本(主副本优先级是100,辅助副本优先级是50)
    主副本如下备份正常
    backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\alwayson1_log_20190902_0004.bak’

    辅助副本如下正常备份
    backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_log_20190902_00004.bak’

    任何副本(主副本优先级是50,辅助副本优先级是100)
    主副本如下备份正常
    backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\alwayson1_log_20190902_0004.bak’

    辅助副本如下正常备份
    backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_log_20190902_00004.bak’

    主(主副本优先级是50,辅助副本优先级是100)
    主副本如下备份正常
    backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\alwayson1_log_20190902_0004.bak’

    辅助副本如下正常备份
    backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_log_20190902_00004.bak’

    主(主副本优先级是100,辅助副本优先级是50)
    主副本如下备份正常
    backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\alwayson1_log_20190902_0004.bak’

    辅助副本如下正常备份
    backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_log_20190902_00004.bak’

    仅辅助(主副本优先级是100,辅助副本优先级是50)
    主副本如下备份正常
    backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\alwayson1_log_20190902_0004.bak’

    辅助副本如下正常备份
    backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_log_20190902_00004.bak’

    仅辅助(主副本优先级是50,辅助副本优先级是100)
    主副本如下备份正常
    backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\alwayson1_log_20190902_0004.bak’

    辅助副本如下正常备份
    backup log alwayson1 to disk = ‘\woncntestdb1\alwayson\db2_alwayson1_log_20190902_00004.bak’

    展开全文
    lusklusklusk 2021-03-24 15:36:41
  • (一)SQL Server-AlwaysOn 技术:SQL Server AlwaysOn 即“全面的高可用性和灾难恢复解决方案”1、数据库级可用性-只读副本:SQL Server 2012-4个,SQL Server 2014-8个a、每个节点都安装了本地的 SQL Server,可以不...

    (一)SQL Server-AlwaysOn 技术:SQL Server AlwaysOn 即“全面的高可用性和灾难恢复解决方案”

    1、数据库级可用性-只读副本:SQL Server 2012-4个,SQL Server 2014-8个

    a、每个节点都安装了本地的 SQL Server,可以不使用共享存储,但是数据库在每个节点上的磁盘文件夹必须是一致的。

    b、主节点可读可写,其它辅助节点只可读。

    c、全部节点都加入一个 Windows Fail-over Cluster 中。

    可以为AlwaysOn可用性组配置一个侦听器(虚拟计算机)。客户端如果访问这个侦听器则可以实现read/write;客户端如果访问指定的辅助节点,可能实现read/write(如果该节点是主节点),或者只能read-only。

    负载分离:

    a、可以将一部分的read only请求发送到辅助副本:

    1)第一种:修改应用程序,在客户端实现。例如,指定将read/write都指向AlwaysOn可用性组的侦听器(不赞成指向某个节点,因为无法确保某个节点可以write),将部分read only请求指向辅助副本。

    2)第二种:为AlwaysOn可用性组配置只读路由:

    脚本如下:

    ALTER AVAILABILITY GROUP [AG1]

    MODIFY REPLICA ON

    N‘COMPUTER01‘ WITH

    (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));

    ALTER AVAILABILITY GROUP [AG1]

    MODIFY REPLICA ON

    N‘COMPUTER01‘ WITH

    (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N‘TCP://COMPUTER01.contoso.com:1433‘));

    连接字符串中添加只读意向:

    Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly;MultiSubnetFailover=True

    2、群集:实例级可用性-AlwaysOn 故障转移群集实例可以在最多16个节点(企业版才支持16个节点,标准版只支持2个节点)间实现故障转移(Fail-over)。

    a、数据库必须位于共享存储。这可能是单一故障点。一旦共享存储崩溃了,SQL Server 服务将停止,数据将全部丢失。

    b、任何时刻只有主节点提供 SQL Server 服务,其它节点的 SQL Server 服务(实例)处于“冷备”状态。当主节点的SQL Server服务发生故障时,才自动转移,然后由另一个备用节点继续提供服务。

    (二)群集与侦听器

    一、群集

    1、 MSFC-Microsoft Failover Cluster:创建SQL Server群集之前,必须在Windows中实现一个MSFC,然后再将SQL Server安装成为MSFC中的一个“服务与应用程序”

    2、节点:同一时间只能在其中一个节点(主节点)运行这个SQL Server实例

    3、Fail-over:故障转移群集是用于获得高可用性的,而非用于实现负载平衡,只有在发生故障时才会转移,而不是负载平衡(Load Balance)

    4、仲裁-节点配置方式:仲裁需要使用投票机制,得票超过半数的节点才能成为主节点。

    Windows Server 2003-2个节点加1个仲裁磁盘。

    Windows Server 2008则推荐使用节点多数(奇数个节点),当节点数量为偶数时才推荐添加一个仲裁磁盘。也就是说,Windows Server 2008 创建 Microfost Windows Cluster 时,仲裁磁盘(共享存储)并不是必须的。

    二、侦听器

    侦听器在MSFC中被称为虚拟网络名称(Virtual Network Name)

    MSFC自身就有一个侦听器,客户端可以直接访问这个侦听器。对这个侦听器的访问被MSFC重定向到主节点。

    1、MSFC的侦听器

    2、SQL Server Cluster的侦听器

    3、AlwaysOn可用性组的侦听器

    a、访问AlwaysOn可用性组的侦听器

    b、直接访问指定的节点

    (三)共享磁盘

    1、共享磁盘-在群集技术中可能会用到共享磁盘。这类磁盘可以被多个节点同时访问,但任一时间只有主节点对共享磁盘享有使用权。

    2、使用共享磁盘的场景

    a、在搭建MSFC时,如果是偶数个节点,那么可以添加一个仲裁磁盘,从而使投票时可以形成“多数”

    b、SQL Server Cluster的数据磁盘

    SQL Server Cluster的本质,是将所有的SQL Server数据库放在一个所有节点共享的磁盘上,当主节点Fail时,下一个节点通过获得共享磁盘的使用权,从而顺利启动SQL Server实例(服务)。

    (四)故障转移

    1、SQL Server 故障转移群集

    实例级的故障转移—备用节点需要较长的时间启动SQL Server服务,然后读取共享磁盘上的数据,最后才接管旧节点上的客户端请求,有时候为了实现特定的目的,需要手动将服务从一个节点切换到另一个节点

    2、AlwaysOn可用性组的故障转移

    数据库级的故障转移—在故障转移之前,各节点的SQL Server服务已经开启,并且数据已经同步提交(节点之间实时同步)。因此数据库级的故障转移速度非常快(通常在10秒内完成)。也可以手动将主副本转移到新的节点。

    (五)数据库镜像

    数据库镜像是SQL Server 2005 sp1正式引入的一项数据库级的高可用性技术。

    1、镜像的实现-镜像是主体服务器、镜像服务器和见证服务器(见证服务器为可选项)之间通过TCP5022端口进行实时通信从而实现数据同步或监控。

    2、镜像的3种运行模式

    a、高性能(异步)-主体服务器上的更改被异步传送给镜像服务器。由于是异步执行,因此对性能的影响很小

    b、高安全(同步)-主体服务器上的更改被同步传送给镜像服务器,而且只有当这些更改同时主体和镜像服务器上完成之后主体服务器才可以继续下一个更改。

    c、高可用(同步)-数据的更改模式与高安全模式时相同。此模式必须存在一台见证服务器,监控主体与镜像服务器的运行状态。如果主体服务器变得不可用,则见证服务器会控制自动故障转移到镜像服务器。

    3、镜像的故障转移

    a、服务器端-如果有见证服务器,则由见证服务器控制自动故障转移。也可以手动控制。

    b、客户端-由于镜像技术没有采用MSFC作为底层,因此客户端直接连接在原来的主体服务器。

    可以在客户端的连接字符串中添加镜像服务器的IP地址,那么客户端在连接主体服务器失败时会自动尝试连接镜像服务器。

    添加连接字符器的方法,请参考 http://technet.microsoft.com/zh-cn/library/ms175484.aspx

    4、镜像技术的不足

    a、客户端不能连接到一个虚拟网络名称。

    b、对于标准版的用户,镜像只能使用高安全(同步)模式,通常都会对性能带来很大的影响。一般在实现镜像之前都需要对数据库做一次性能调整与优化。

    c、只能针对单个数据库。例如,SharePoint用户希望同时对一组数据库实现高可用,而镜像只能一个一个地对数据库实现。

    d、镜像服务器上的数据库一直处于“正在还原”状态,只能通过创建快照才能实现只读访问。

    (六)日志传送

    1、日志传送的实现

    日志传送依赖于传统的Windows技术与SQL Server代理。

    a、 为主数据库创建一个事务日志备份计划

    b、 为辅助数据库创建一个文件复制计划

    c、 为辅助数据库创建一个事务日志还原计划

    2、事务日志还原的选项

    a、无恢复模式—在这种模式时,辅助数据库在做事务日志还原时使用WITH NORECOVERY选项(未提交的事务没有被回滚),数据库一直处于“正在还原”状态,不可以访问。

    b、备用模式—在这种模式时,辅助数据库在做事务日志还原时使用WITH STANDBY选项(将未提交的事务在一个临时文件中回滚)。数据库处于“只读,备用”状态,可以提供只读访问。

    3、日志传送的优势:广泛地部署。辅助数据库可以提供只读访问,作为报表等应用程序的数据源。

    4、日志传送的不足:不支持自动的故障转移。数据同步被拆分成3个步骤实现,因此会有较大的延时

    (七)复制

    复制是一个开发范畴的技术,但是也可以像日志传送一样作为高可用技术的一个后备选项。

    1、复制的拓扑

    2、复制的冲突处理

    a、合并复制—合并复制允许存在冲突。当冲突发生时,合并复制将比较这些记录的时间戳,仅保留最新的记录(时间戳最后的那条记录)。

    b、专用的写入区—一种方式是将read请求随机发送给任意一个数据库,而将write指定只写入发布服务器。另一种方式是设置专用的写入区,所有写入被事先隔离,从而避免冲突。

    3、复制在负载均衡中的应用—在一些稍微容忍数据同步存在延迟的场合,复制可以作为负载均衡的手段。这种实现方法,其实质是通过复制实现分布式数据库。

    (八)负载平衡

    1、服务的类型

    a、 无状态的服务(stateless service):对单次请求的处理,不依赖其他请求。

    处理一次请求所需的全部信息都包含在这个请求里或者可以从外部获取(例如,数据库),服务本身不存储任何信息。

    IIS(Web服务)可以设计成无状态的服务,可以实现池化(负载均衡),从而横向扩展。

    b、 有状态的服务(stateful service):会在自身保存一些数据。先后的请求是有关联的,通常用于实现事务。数据库服务一般是有状态的服务。

    2、区别

    a、高可用—针对“有状态”的服务,其目标是为了减少硬件或软件故障造成的影响,保持业务的连续性,从而将用户可以察觉到的停机时间送到最少。

    b、 负载平衡—针对“无状态”的服务,其目标是通过对服务的“池化”(多个服务,形成一个“池”)使客户端的请求被分摊到多个服务

    3、联系

    a、高可用技术中兼具一部分的负载分摊功能。

    b、负载均衡给客户端的感觉就像高可用技术一样,保持了业务的连续性。

    4、SQL Server 负载分离示例

    生产环境通常在设计时就要考虑到未来的数据增长,并且预留负载分离的接口。

    展开全文
    weixin_33533854 2021-02-07 01:15:14
  • 官方文档...Alwayson相对于数据库镜像最大的优势就是可读副本,带来可读副本的同时还添加了一个新的功能就是配置只读路由实现读写分离 AlwaysOn技术集中了故障转移群集、数据库镜像和日志传送三者的优点

    官方文档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地址资源和网络名称资源。用户就可以使用此名称来连接到可用性组中。与故障转移群集不同,除了使用虚拟网络名称之外,主副本的真实实例名还可以被用来连接。

    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 ′ h a s C r e a t e C o m p u t e r O b j e c t s p e r m i s s i o n s . B y d e f a u l t a l l c o m p u t e r o b j e c t s a r e c r e a t e d i n t h e s a m e c o n t a i n e r a s t h e c l u s t e r i d e n t i t y ′ I B D M M D B C L S ' has Create Computer Objects permissions. By default all computer objects are created in the same container as the cluster identity 'IBDMMDBCLS hasCreateComputerObjectspermissions.BydefaultallcomputerobjectsarecreatedinthesamecontainerastheclusteridentityIBDMMDBCLS’.
    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是可用性组中的首选备份副本

    展开全文
    lusklusklusk 2021-03-24 15:36:09
  • 二:配置SQL Server AlwaysOn SQL Server的安装这里就不描述,直接从配置AlwaysOn开始操作。 1 ,这里配置AlwaysOn,我采用的是共享文件夹的方式,所以首先在DB1这个节点上创建一个??????????????????????????????...
    1. 引言

    基于windows2012 server和sql server2012的域控的设置方法在很多场景已经使用,不仅需要windows的域部署,故障转移部署,以及sql server的域部署以及仲裁机等操作,使用起来非常麻烦,现在sql server2016来了,听说sql server2017可以在linux上部署AG,又是一个降低运营成本的好消息,这边先以sql server2016为例,详细讲述下如何部署实施。

    1. 操作步骤

      2.1 Windows 2016 无域故障转移群集部署方法

      故障转移群集是一个很实用的功能,而windows在2016版本开始,终于支持不用域做故障转?????.?在群集中,我们可以设定一个"群集IP"而客户端只需要根据这个"群集IP"就能连接当前群集的主服务器.而不必关心群集服务器之间的替换.而更棒的是,它是"去中心"的,它没有一个中心主机,我们都知道"有中心"的集群,如果"中心"出了问题,那么整个集群都无法运行了.而故?????????,????????????,????????????(??????????????,????????????,??????).?

    演示环境

      这边使用vwware16搭建windows2016 Datacenter环境,使用仅主机模式,并且在vwware的编辑的虚拟网络编辑器里设置了网段和掩码,如下图:

    演示环境

    1. 通用配置

    Key

    Value

    系统版本

    Win2016

    集群IP

    192.168.3.2

    网段

    255.255.255.0

    网关

    192.168.3.1

    2. 设备配置

    设备编号

    IP地址

    域名

    1

    192.168.3.8

    d1.net

    2

    192.168.3.11

    d2.net

    IP以及名称规划:

    节点1(物理服务器或虚拟机):d1   IP地址:192.168.3.8

    节点2(物理服务器或虚拟机):d2 IP地址:192.168.3.11

    Windows群集名称:CLUSTER.net IP地址:192.168.3.15(虚拟IP)

    可用性组名称:SQLAG

    SQL侦听器名称:listen IP地址:192.168.3.18(虚拟IP)

    注意事项:

    1,只有Windows Server 2016 操作系统才能配置不依赖域的群集 ,2台服务器的操作系统???????????SQL Server?????????????????

    2,两个节点的Windos Server 2016 都以Administrator账户登录,并且两台服务器的Administrator密码相同,无特殊意义,只是为了方便后续的操作。

    3,两个节点的SQL Server 2016 服务启动账户都设置成Administrator 。2个节点的数据库都有Administrator的登录名,也就是使用Administrator登录服务器时,可用Windows身份???????SQL Server???

          即:

    节点1的SQL Server上有:d1\administrator  ;节点2上有:d2\administrator ;这2个登录账号,在安装SQL Server的时候可创建。均有sysadmin权限。

    一:首先配置Windows故障转移群集(2个节点均使用Administrator登录)

    第一步:安装Windows故障转移群集(所有节点都需要安装)

     第二步:每个节点的计算机不需要加入域,但需要添加DNS后缀,且每个节点的后缀必须要????????????net),如下图所示的操作。

    第三步:在每个节点上都添加一个用户(我增加的用户名称是DCAdmin),且用户名以及密???????????????????????????????????????2???????????????????????????

    第四步:在每个节点的 hosts 文件中添加每个节点的服务器IP地址和名称、群集IP地址和???????????IP???????????????????????

    hosts文件路径:C:\Windows\System32\drivers\etc

    hosts文件可以用记事本打开

    服务器名称,填写的是计算机全名,也就是服务器名带上之前设置的DNS名称后缀的名称,??????d1.net。host文件需要在2个节点的服务器上都进行相同的操作。

     我这边使用的dns解析来解决,首先需要安装dns

    1. 所有主机配置DNS解析记录 并测试解析

      1. 新建正向查找区域NET

    1. 新建反向查找区域

    结果就像这样的:

    1. 新建反向查找记录  (我们新建正向记录勾选了PTR指针 默认已经新建了B/C主机的反向记录) 现在只需新建一条本机的PTR记录

    1. 测试解析

    无域的服务器都要配置dns服务器,可以使用host但是我觉得网络配置使用静态表实在太low,毕竟不是开发做做switchhost的换同根同域环境。

    A主机配置故障转移群集 B/C主机连接到群集 指定虚拟IP192.168.3.15

      1. 主机A创建集群CLUSTER

    这边填之前的说好的192.168.3.15

    这样各个节点已经连接了。

    第五步:设置允许应用或功能通过防火墙,两个节点均要设置,按照下面图中红框框出的地方设置,注意选项后面打勾的位置。

    二:配置SQL Server AlwaysOn 

    SQL Server的安装这里就不描述,直接从配置AlwaysOn开始操作。

    1 ,这里配置AlwaysOn,我采用的是共享文件夹的方式,所以首先在DB1这个节点上创建一个?????????????????????????????????????????DCAdmin??????DB2???????????????????

    1. 在DB1和DB2上设置启用AlwaysOn

    启用AlwaysOn会要求重启服务,重启就可以。

    3,重启服务后,查看服务器属性,确保 HADR 为 True 

    既然节点没有加入域,那么就不能用域认证,只能用证书认证,因此需要在每个节点的数据库中创建其他节点的数据库证书。(请留意我连接数据库的账户,在创建端口的代码中有用到)

    因此在配置可用性组前先在各节点配置证书认证信任。

    4,分别在两个节点数据库上创建证书,并且彼此还原对方的证书,SQL代码如下:

    注:我是在节点1上用administrator登录服务器,使用Windows身份登录SQL Server。在节?2????????administrator????????????????Windows????????SQL Server?

    --共享文件夹路径: ---\\JF-SQLDB01\SQLAlwaysOn   使用共享文件夹是为了方便读取每个节点的证书

    --节点一上执行:创建主密钥/证书/端点,备份证书到共享文件夹中。

    USE master;

    GO

    CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'JFAlwaysOnShare2016' ----密码

    GO

    CREATE CERTIFICATE Cert_DB01

    WITH SUBJECT = 'Cert_DB01',

    START_DATE = '2021-04-01',EXPIRY_DATE = '2029-12-31' --证书的有效时间

    GO

    ----导出证书,将证书放在共享文件夹里面

    BACKUP CERTIFICATE Cert_DB01

    TO FILE = '\\D1\SQLAlwaysOn\Cert_DB01.cer'

    GO

    ---创建端点

    CREATE ENDPOINT [SQLAG_Endpoint]

    AUTHORIZATION [WIN-DR6UKA2RJDA\Administrator] ----此账户是连接数据库的账户

    STATE=STARTED

    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)---侦听端口,1024 和 32767 之间的任何数字都有效。侦听IP地址,默认值为 ALL,表示??????????????????? IP ?????????????

    FOR DATA_MIRRORING

    (ROLE = ALL,AUTHENTICATION = CERTIFICATE Cert_DB01, ENCRYPTION = REQUIRED ALGORITHM AES)

    GO

    --节点二上执行:创建主密钥/证书,备份证书。

    USE master;

    GO

    CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'JFAlwaysOnShare2016';

    GO

    CREATE CERTIFICATE Cert_DB02

    WITH SUBJECT = 'Cert_DB02',

    START_DATE = '2021-04-01',EXPIRY_DATE = '2029-12-31';

    GO

    BACKUP CERTIFICATE Cert_DB02

    TO FILE = '\\D2\SQlAlwayon\Cert_DB02.cer';

    GO

    CREATE ENDPOINT [SQLAG_Endpoint]

    AUTHORIZATION [WIN-93HCUQ47RJN\administrator]

    STATE=STARTED

    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)

    FOR DATA_MIRRORING

    (ROLE = ALL,AUTHENTICATION = CERTIFICATE Cert_DB02, ENCRYPTION = REQUIRED ALGORITHM AES)

    GO

    --节点一上执行:创建节点二的证书

    USE master;

    GO

    CREATE CERTIFICATE Cert_DB02

    FROM FILE = '\\JF-SQLDB01\SQLAlwaysOnShare\Cert_DB02.cer';

    GO

    --节点二上执行:创建节点一的证书

    USE master;

    GO

    CREATE CERTIFICATE Cert_DB01

    FROM FILE = '\\JF-SQLDB01\SQLAlwaysOnShare\Cert_DB01.cer';

    GO

    上面两部做不了就手动安装,原因是sql server没有读证书权限增加进去

    1. 配置可用性组,接下来就和以前版本的配置是一样的了,不再描述,按照下面的截图一步一步配置

    这个最好把db2设置为sa模式,然后用db1的机器尝试连接下,保证可用性配置的1433是联通的

    这里是选择数据库,记住一定要全量备份下,但是db2不用新增同样数据库

    这边服务器名用d2,并且自动故障转移选择勾上并且同步为是

    这边一点要有个共享文件夹,上次放证书的那个,不通的话后面验证不通过

    1. 最后创建侦听器,当然,创建侦听器也可以在上一步设置。

    最后,可以使用侦听器名称来连接数据库,数据库显示已同步,配置无域AlwaysOn成功、

    参考自:

    配置SQL Server2016无域AlwaysOn

    https://blog.csdn.net/roven257/article/details/78691892?ops_request_misc=&request_id=&biz_id=102&utm_term=sql%20server%20alwayson&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduweb~default-3-78691892.first_rank_v2_pc_rank_v29

    SQL Server 2017 Always On AG on Linux(二)SQL Server 证书及权限配置

    https://blog.csdn.net/kk185800961/article/details/89483724

    Linux 上配置 AG

    https://www.cnblogs.com/guarderming/p/10570484.html

    AlwaysOn添加新可用性副本

    https://www.it610.com/article/1281403096454414336.htm

    WINDOWS2016故障转移群集

    https://blog.csdn.net/weixin_42256332/article/details/89151749

    SQLSERVER非域环境搭建镜像

    https://www.cnblogs.com/cmt/p/14580194.html?from=https%3A%2F%2Fwww.cnblogs.com%2FFly446854715%2Fp%2F4173345.html&blogId=198684&postId=4173345

    VMware虚拟机的三种网络连接方式以及主机向虚拟机发送文件的实现

    https://blog.csdn.net/weixin_39490421/article/details/79518927

    Windows 2016 无域故障转移群集部署方法 超详细图文教程

    https://blog.csdn.net/demonson/article/details/81708809

    SQLServer2008端口及防火墙设置

    https://www.cnblogs.com/pipci/p/7850892.html

    (WSFC) resource control API returned error code 5057 & Microsoft SQL Server, Error: 41009

    https://blog.csdn.net/burgess_liu/article/details/16855267

    连接到 Always On 可用性组侦听器

    https://docs.microsoft.com/zh-cn/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover?view=sql-server-ver15

    展开全文
    orichisonic 2021-07-14 10:27:10
  • kk185800961 2021-11-27 11:17:53
  • weixin_39732991 2020-12-21 10:00:39
  • weixin_39603622 2020-12-21 10:00:41
  • weixin_39743423 2020-12-21 10:00:33
  • Hehuyi_In 2021-05-16 10:41:39
  • weixin_33266588 2021-08-06 03:17:00
  • weixin_39999222 2020-12-21 10:00:37
  • weixin_31366207 2021-01-26 03:50:12
  • weixin_39743357 2020-12-21 10:00:44
  • qq_42391371 2021-08-10 10:14:26
  • weixin_45130813 2021-11-04 11:53:25
  • weixin_39677870 2021-02-07 01:15:19
  • m0_57382568 2021-07-03 16:18:13
  • zqh123zqh 2020-12-22 19:54:38
  • xiaoxionglove 2021-02-18 12:46:33
  • shy871 2021-06-03 14:00:07
  • r023875206 2021-11-18 16:23:32
  • upluck 2021-05-18 06:46:33
  • weixin_39959298 2020-12-21 10:00:37
  • upluck 2021-05-18 06:45:19
  • weixin_42280959 2021-01-13 10:59:11
  • xjjj064 2021-03-10 15:59:54
  • weixin_39618339 2021-01-27 11:50:07
  • qq_45380502 2021-04-06 13:57:16

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 339,580
精华内容 135,832
关键字:

alwayson

友情链接: RSSI的定位.rar