【Always On】完整文档
有道云笔记markdown文档。
概述
发布订阅：alwayson之前的技术实现方案---SQL Server 2005,微软,查询分离。缺点：生产库和查询库的同步性能较差，存在性能问题，因此在大型生产环境为人诟病。AlwaysOn:SQL Server 2012
引入的一种新的技术架构，相比发布订阅性能明显提升;区别在于其充分利用内存高效读取的原理来实现日志的传递。
功能
原理
同步操作：
从客户端收到事务后，主副本会将事务的日志写入事务日志，同时将该日志记录发送到辅助副本。
日志记录写入主数据库的事务日志后，事务将不能撤消，除非在此时故障转移到尚未收到该日志的辅助副本。主副本将等待来自同步提交辅助副本的确认。
辅助副本将强制写入日志（固化），并将确认消息返回给主副本。
收到来自辅助副本的确认后，主副本将完成提交处理并向客户端发送一条确认消息。
客户端->>主副本: 提交事务
主副本->>主副本: 事务的日志写入事务日志
主副本->>辅助副本: 日志记录
辅助副本->>辅助副本:写入日志（固化）
辅助副本->>辅助副本:日志转换成修改操作，写入数据库（重做）
辅助副本->>主副本: 确认消息
主副本->>主副本: 完成提交
主副本->>客户端: 确认消息线程介绍以及职责
LogWriter 任何一个SQL Server 数据修改事务 内存缓冲 日志固化
graph LR
日志信息-->内存日志缓冲区
内存日志缓冲区-->物理日志文件Log Scanner 主副本 日志缓冲区或者日志文件 打包日志块 不间断工作 发送给各个辅助副本
graph LR
内存日志缓冲区/物理日志文件-->日志块
日志块-->辅助副本Harden 写入辅助副本的磁盘上的日志文件
Redo 日志记录翻译成数据修改操作 每隔固定的时间跟主副本通信 告知自己的工作进度
graph LR
Harden日志块-->存放到辅助副本磁盘日志文件
存放到辅助副本磁盘日志文件-->Redo日志块
Redo日志块-->数据修改操作任何一个SQL Server里都有个叫Log Writer的线程，当任何一个SQL用户提交一个数据修改事务时，它会负责把记录本次修改的日志信息先记入一段内存中的日志缓冲区，然后再写入物理日志文件（日志固化）,所以对于任何一个数据库，日志文件里都会有所有数据变化的记录。
对于配置为AlwaysOn主副本的数据库，SQL Server会为它建立一个叫Log Scanner的工作线程,这个线程专门负责将日志记录从日志缓冲区或者日志文件里中读出，打包成日志块，发送给各个辅助副本。由于它的不间断工作，才使主副本上的数据变化，可以不断地向辅助副本上传播。
- 在辅助副本上，同样会有两个线程，完成相应的数据更新动作，它们是固化（Harden）和重做（Redo）。
- 固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本的磁盘上的日志文件里（这个过程被称为"固化"）。
- 重做线程，则负责从磁盘上读取日志块，将日志记录翻译成数据修改操作，在辅助副本的数据库上完成。当重做线程完成其工作以后，辅助副本上的数据库就会跟主副本一致了。AlwaysOn就是通过这种机制，保持副本之间的同步。重做线程每隔固定的时间点，会跟主副本通信，告知它自己的工作进度。主副本就能够知道两边数据的差距有多远。
部署
所需资源
| 指标 | 域控服务器 | DB1 | DB2 | 共享文件夹or见证磁盘 |
|---|---|---|---|---|
| IP | 域控IP | DB1 IP | DB2 IP | |
| 网关 | 172.31.2.254 | 172.31.2.254 | 172.31.2.254 | |
| 子网掩码 | 255.255.255.0 | 255.255.255.0 | 255.255.255.0 | |
| DNS | 127.0.0.1 | 域控IP | 域控IP | |
| 计算机名 | Cluster01 | DBserver01 | DBserver02 | |
| 域名 | *.com | *.com | *.com | |
| 域账户 | username | |||
| 域密码 | ****** | |||
| 仲裁见证文件共享地址 | （\\share）共享地址 Tip：不能在域控上 | |||
| VIP（故障转移集群虚拟IP） | 172.31.1.E | |||
| SQL数据库版本 | SQL Server 2016 Enterprise Edition | SQL Server 2016 Enterprise Edition | ||
| SSMS | Server Management Studio 17.4 | Server Management Studio 17.4 | ||
| 服务器版本 | Windows Server 2012 R2 Standand 64位 | Windows Server 2012 R2 Standand 64位 | Windows Server 2012 R2 Standand 64位 | |
| VIP（alwayson虚拟IP） | Always On IP | Always On IP | ||
| 侦听器 | 侦听器名称 | |||
| 数据库 | dbname | |||
| sa密码 | ****** |
系统架构
- windows 群集
graph TD
故障转移群集_VIP1--> 节点服务器1_IP1
故障转移群集_VIP1--> 节点服务器2_IP2
故障转移群集_VIP1--> 节点服务器X_IPX....
- always on 集群
graph TD
数据库侦听器_VIP2--> DBServer01_IP1
数据库侦听器_VIP2--> DBServer02_IP2
数据库侦听器_VIP2--> DBServer0X_IPX....
搭建步骤
扩展优化
技术要点
==四种集群仲裁配置==
- [ ] 多数节点：这种配置不会用到仲裁磁盘，而所谓多数节点就是在正常节点数量占多数的情况下，集群才会提供服务，否则就停止服务。这种配置适用于
奇数节点的集群，例如5个节点的集群，其正常节点数量必须至少3个，集群才会提供服务 - [ ] 多数节点和磁盘：适用于
偶数节点的集群，他在计算法定数量时会将仲裁磁盘计算进来，例如，4个节点+1个仲裁磁盘节点的集群，可以将其视为5个节点的集群，这时正常节点数量必须至少3个，集群才会提供服务 - [x] 多数节点和文件共享：它和（多数节点和磁盘）类似，不过
仲裁磁盘改为共享文件夹内的文件 [ ] 没有多数：只有磁盘，只要仲裁磁盘脱机，集群就会停止提供服务（不建议使用，这种方式很早之前已经有了）
1. 仲裁配置：（多数节点） 和 （多数节点和文件共享）
2. 如果集群节点是奇数，那么使用多数节点。
3. 如果集群节点是偶数，那么使用多数节点和文件共享。
4. 需要配置一个共享文件夹，各个节点都能访问这个共享文件夹。
5. 共享文件夹所在机器不需要加入域。
6. 生产环境不要把共享文件夹放在域控上。
7. 一个节点和见证磁盘运行,可以运行。
8. 所有节点运行，见证磁盘不通信，停止运行。
==见证磁盘 VS 见证共享文件夹==
- [ ] 见证磁盘（简称仲裁盘）需要共享存储，各个服务器节点需要挂载同一个磁盘是放在共享存储上面。
[x] 见证共享文件夹：Windows 2008推出的见证磁盘方式，推出见证共享文件夹之后可以
不需要共享存储，只需要共享文件夹即可。==同步提交 VS 异步提交==
- [ ] 异步提交模式：使用此可用性模式的可用性副本称为"异步提交副本"。
当辅助副本处于异步提交模式下或者尽管辅助副本在同步提交模式下，但此时主副本在异步提交模式时，主副本无须确认该辅助副本是否已经完成日志固化，就可以提交事务。因此，主数据库事务提交不会受到辅助数据库的影响而产生等待。但是，辅助数据库的更新可能会滞后于主数据库，如果发生故障转移，可能会导致某些数据丢失。因此这种可用模式适合于可用性副本的分布距离较远的情况。 [x] 同步提交模式：使用此可用性模式的可用性副本称为"同步提交副本"。
同步提交模式要求主副本和辅助副本必须设置成同步提交副本。在同步提交模式中，主副本必须确认辅助副本已经完成日志固化才可以提交事务（不需要等待辅助副本完成日志重做），这样就保证两边的数据始终是同步的。但是这种保障的代价是主数据库上的事务提交会有滞后时间。可以说，同步提交模式相对于性能而言更强调高可用性。==故障转移集群VIP VS AlwaysOn 的VIP==
- [x] 1. 故障转移集群VIP：连接故障转移集群管理器的集群使用
[x] 2. AlwaysOn VIP 连接AlwaysOn使用
==故障转移模式==
可用性副本的主角色和辅助角色在称为“故障转移” 的过程中通常是可互换的。
三种故障转移形式： 1. 自动故障转移（无数据丢失） 1. 计划的手动故障转移（无数据丢失） 1. 强制手动故障转移（可能丢失数据）,通常称为“强制故障转移”==自动故障转移所需条件==
仅在以下条件下才发生自动故障转移：
- [x] 存在自动故障转移集。 此自动故障转移集由
主要副本和次要副本（自动故障转移目标）构成，主要副本和次要副本都配置为同步提交模式并且设置为自动故障转移。
如果主要副本设置为手动故障转移，即使次要副本设置为自动故障转移，也无法发生自动故障转移
自动故障转移目标具有正常运行的同步状态（这指示故障转移目标上的每个辅助数据库都与其相应的主数据库同步）。 - [x] Windows Server 故障转移群集 (WSFC) 群集
具有仲裁。 - [x]
主副本已变得不可用，并且由灵活的故障转移策略定义的故障转移条件级别已得到满足。
==辅助角色支持的连接访问类型==
[ ] 无连接
不允许任何用户连接。 辅助数据库不可用于读访问。 这是辅助角色中的默认行为。[ ] 仅读意向连接
辅助数据库仅适用于其 Application Intent 连接属性设置为 ReadOnly 的连接（读意向连接）。[x] 允许任何只读连接
辅助数据库全部可用于读访问连接。 此选项允许较低版本的客户端进行连接。- ==主角色支持的连接访问类型==
[x] 1.允许所有连接
主数据库同时允许读写连接和只读连接。 这是主角色的默认行为。[ ] 2.仅允许读/写连接
当 Application Intent 连接属性设置为 ReadWrite 或未设置时，允许此连接。 不允许其 Application Intent 连接字符串关键字设置为 ReadOnly的连接。 仅允许读写连接可帮助防止您的客户错误地将读意向工作负荷连接到主副本。
注意事项
- 所有机器防火墙都关掉
- 域控不需要安装故障转移集群服务和SQL Server.不需要加入到故障转移集群
- 两个节点都需要安装相同的更新程序，建议不要开启自动更新功能，由系统管理员手动更新
- SQL Server 2012 AlwaysOn只支持最多一个主副本和四个辅助副本.
- 最多允许三个同步提交的可用性副本(包括主副本)
- 最多允许两个自动故障转移副本(包括主副本)
- 现在AlwaysOn可用性组已经完全支持 Windows Azure ，可以把辅助副本部署到 Windows Azure 上
- 主副本机器和各个辅助副本机器的扇区是否一致，如果扇区不一致，或者环境不一样有可能导致同步慢或IP冲突问题
- 每个扇区字节数和每个物理扇区字节数这两个值，各个副本显示不同，那么最好不要搭建AlwaysOn
- 在AD用户和计算机管理界面 里的 域用户和故障转移集群用户的权限需要添加下面红框的权限，否则创建侦听器的时候有可能报错
跳坑记录
- [x] 1.数据库处于“正在还原”问题
- 原因分析：
数据库加入可用性组后，正常状态下数据库为标注为“已同步”，当删除可用性后，数据库状态会变成“正在还原”该状态数据库将无法正常读写。 - 解决方案：执行基本还原即可。
--修复正在还原数据库
RESTORE DATABASE omsprod WITH RECOVERY- [x] 2.孤立用户问题
- 原因分析：数据库备份还原后数据的登录名的用户映射关系丢失，数据库登录lcoms9999成为孤立用户，进而服务端连接数据库连接失败。
- 解决方案：执行以下脚本数据库删除原有的数据库登录名修复数据的孤立用户。
--查询孤立用户 --需要选定对应的数据库
sys.sp_who @loginame ='LCOMS9999' -- sysname
--删除登录用户
KILL 71
--修复孤立用户 --需要选定对应的数据库
sp_change_users_login 'Auto_Fix', 数据库用户名, NULL, '密码'- [x] 3.故障转移后，服务端连接数据库节点失败问题。
- 原因分析：数据库副本之间的sid不一致。
- 修复方案：执行脚本获取sid，将主要副本的登录用户的sid 同步到服务副本中。
--查询登录名sid --主库查询sid --将结果在辅助库中执行
SELECT
'create login [' +p.name + '] ' +
case when p.type in('U','G') then 'from windows ' else '' end +
'with ' +
case when p.type = 'S' then 'password = ' + master.sys.fn_varbintohexstr(l.password_hash) + ' hashed, ' +
'sid = ' + master.sys.fn_varbintohexstr(l.sid) +
',check_expiration = ' + case when l.is_expiration_checked >0 then 'ON, ' else 'OFF, ' end +
'check_policy= ' + case when l.is_policy_checked> 0 then 'ON, ' else 'OFF, ' end +
case when l.credential_id > 0 then 'credential = ' + c.name + ', ' else '' end
else '' end +
'default_database = ' + p.default_database_name+
case when len(p.default_language_name) >0 then ',default_language = ' + p.default_language_name else '' end
FROM sys.server_principals p
LEFT JOIN sys.sql_logins l ON p.principal_id = l.principal_id
LEFT JOIN sys.credentials c ON l.credential_id= c.credential_id
WHERE p.type in('S','U','G')
AND p.name<> 'sa'[x] 4.可用性组创建失败问题
- 原因分析：AlwaysOn集群创建失败删除后，需要重新停用、启用alwaysOn功能
解决方案：在每个数据库节点的数据库配置管理器上数据库服务的属性中重新停用、启用alwaysOn功能。
[x] 5.数据库连接字符串配置异常导致的数据库转移后失去连接问题
- 原因分析：数据库连接字符串对应到当前主要副本数据库，发生故障转移时数据库连接无法自动转移到原辅助副本中。
解决方案：更新数据的连接方式，将数据库连接到alwaysON的侦听器的虚拟IP上。当故障发生转移后数据库连接地址会自动的转移到新的主要副本数据库中。
[x] 6.数据库某一节点发生不可修复的故障时，需要重新部署数据库节点。
- 解决方案：修复数据库节点问题后，移除辅助副本的omsprod数据库，移除Alwayson集群的可用性组中的omsprod可用性数据库，重新添加该可用性数据库到可用性组中。
[x] 7.数据库某一节点发生不可修复的故障时，需要重新部署数据库节点。
解决方案：重新搭建一服务器虚拟机环境，使用服务器快照还原数据库节点。下一步按照步骤6执行。
[x] 8.数据库辅助节点无法查看的问题
- 原因分析：AlwaysON集群创建的时候可以设置集群的“可读辅助副本”的状态。当状态为否时，数据将无法正常打开查看。该状态下数据库仅用于数据库备份。
解决方案：设置“可读性辅助副本”的状态为是。
- [x] 9.主库磁盘满了导致集群故障转移异常并且导致辅助副本同步异常修复
- 现象描述：
主库磁盘满了,故障转移异常,导致辅助副本同步异常 - 修复步骤:
-
- 重新添加可用性组：
失败
- 重新添加可用性组：
-
- 移除节点：重新添加:
失败
- 移除节点：重新添加:
-
- 重新添加到域：
失败
- 重新添加到域：
-
- 重新添加到搭建，windows群集：
失败
- 重新添加到搭建，windows群集：
-
- 经检查群集添加失败的真实原因，主副本的防火墙个别端口被意外开启，由于前期排查时确定过防火墙已关闭，所以怀疑是公司的安全策略导致。
成功
- 经检查群集添加失败的真实原因，主副本的防火墙个别端口被意外开启，由于前期排查时确定过防火墙已关闭，所以怀疑是公司的安全策略导致。
引用
感谢前行者分享 不完全记录
189
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
