数据库
首页 > 数据库> > 【sql server alwaysOn】sql server alwaysOn实践汇总

【sql server alwaysOn】sql server alwaysOn实践汇总

作者：互联网

  1. 【0】架构准备

【0.1】基本架构信息

概念及参考：http://www.mssqlmct.cn/dba/?post=97

准备：利用vmvare workstation12

机器：克隆了4台windows server 2012 R2 datacenter +sql server 2014，单核，2G内存（有点卡，建议3G）

网络选择仅主机模式（VMnet8），网关为192.168.214.2

设备名称

IP地址

操作系统与数据库

角色

DB1

192.168.214.151

WIN 2012 R2 + MSSQL2014

主副本

DB2

192.168.214.152

WIN 2012 R2 + MSSQL2014

辅助副本（同步）

DB3

192.168.214.153

WIN 2012 R2 + MSSQL2014

辅助副本（异步）

DC1

192.168.214.154

WIN 2012 R2

DC/DNS，域控alwayson.com

DB1 故障转移集群 VIP

192.168.214.160

  

故障注意集群虚拟IP

DB1 可用性侦听组

192.168.214.161

  

Alwayson侦听器

故障转移集群VIP：192.168.214.160

可用性组侦听器IP：192.168.214.161

 

 

 

 

 

 

 

 

【0.2】基本步骤与思路

 

【0.3】基本概念

    暂且看不懂可以不着急，做完实验回来看更佳。

【0.3.1】alwayson概念

"可用性组" 针对一组离散的用户数据库（称为"可用性数据库" ，它们共同实现故障转移）支持故障转移环境。 一个可用性组支持一组主数据库以及一至八组对应的辅助数据库(包括一个主副本和两个同步提交辅助副本)。 辅助数据库不是备份，应继续定期备份您的数据库及其事务日志。

每组可用性数据库都由一个"可用性副本" 承载。 有两种类型的可用性副本：一个"主副本" 和一到四个"辅助副本"。 它承载主数据库和一至八个"辅助副本" ，其中每个副本承载一组辅助数据库，并用作可用性组的潜在故障转移目标。 可用性组在可用性副本级别进行故障转移。 可用性副本仅在数据库级别提供冗余 － 针对一个可用性组中的该组数据库。 故障转移不是由诸如因数据文件丢失或事务日志损坏而使数据库成为可疑数据库等数据库问题导致的。

主副本使主数据库可用于客户端的读写连接。 此外，它在称为"数据同步" 的过程中使用，在数据库级别进行同步。 主副本将每个主数据库的事务日志记录发送到每个辅助数据库。 每个次要副本缓存事务日志记录（"硬化"日志），然后将它们应用到相应的辅助数据库。 主数据库与每个连接的辅助数据库独立进行数据同步。 因此，一个辅助数据库可以挂起或失败而不会影响其他辅助数据库，一个主数据库可以挂起或失败而不会影响其他主数据库。或者，您可以配置一个或多个辅助副本以支持对辅助数据库进行只读访问，并且可以将任何辅助副本配置为允许对辅助数据库进行备份。

部署 Always On 可用性组需要一个 Windows Server 故障转移群集 (WSFC) 群集。 给定可用性组的每个可用性副本必须位于相同 WSFC 群集的不同节点上。 唯一的例外是在迁移到另一个 WSFC 群集时，此时一个可用性组可能会暂时跨两个群集。

为您创建的每个可用性组创建一个 WSFC 资源组。 WSFC 群集将监视此资源组，以便评估主副本的运行状况。 针对 Always On 可用性组 的仲裁基于 WSFC 群集中的所有节点，而与某一给定群集节点是否承载任何可用性副本无关。 与数据库镜像相反，在 Always On 可用性组中没有见证服务器角色。

 

【0.3.2】可用性模式

可用性模式是每个可用性副本的一个属性；可用性模式确定主副本是否需要等待辅助副本将事务日志写入到磁盘。

（1）异步提交模式

异步提交模式是一种灾难恢复解决方案，适合于可用性副本的分布距离较远的情况。如果每个辅助副本都在异步提交模式下运行，则主副本不会等待任何辅助副本强制写入日志，而会在将日志记录写入本地日志文件后，立即将事务确认发送到客户端。主副本使用与针对异步提交模式配置的辅助副本相关的最小事务滞后运行。

在"异步提交模式"下，辅助副本永远不会与主副本同步。虽然给定的辅助数据库可能会赶上对应的主数据库，但任何辅助数据库在任何时点都可能会落后。对于主副本和辅助副本相隔很远而且您不希望小错误影响主副本的灾难恢复方案的情况，或性能比同步数据保护更重要的情况，异步提交模式将会很有用。而且，由于主副本不会等待来自辅助副本的确认，因而辅助副本上的问题从不会影响主副本。

异步提交辅助副本会尝试与接收自主副本的日志记录保持一致。但异步提交辅助数据库往往会保持未同步状态，并且可能稍微滞后于相应的主数据库。通常，异步提交辅助数据库和相应的主数据库之间的这个时间差会很小。但是，如果承载辅助副本的服务器的工作负荷过高或网络速度很慢，则这个时间差会变得较大。

异步提交模式所支持的唯一故障转移形式为强制故障转移（可能造成数据丢失）。强制故障转移是一种最后手段，仅可用于当前主要副本长时间保持不可用状态并且主数据库的即时可用性比可能丢失数据的风险更为重要的情况。故障转移目标必须是其角色处于 SECONDARY 或 RESOLVING 状态的副本。故障转移目标将转换为主角色，并且其数据库副本将成为主数据库。任何剩余的辅助数据库以及变得可用后的以前的主数据库都将被挂起，直到您手动单独恢复它们。在异步提交模式下，原始主副本尚未发送到以前的辅助副本的任何事务日志都将丢失。这意味着，某些或全部新的主数据库可能会缺少最近提交的事务

（2）同步提交模式

同步提交模式相对于性能而言更强调高可用性，为此付出的代价是事务滞后时间增加。在同步提交模式下，事务将一直等到辅助副本已将日志强制写入到磁盘中才会向客户端发送事务确认。

在同步提交可用性模式下，副本联接到某个可用性组后，辅助数据库就会与对应的主数据库求得一致并进入 SYNCHRONIZED（已同步）状态。只要一直在进行数据同步，辅助数据库就会保持 SYNCHRONIZED 状态。这可确保对主数据库提交的每个事务也应用到对应的辅助数据库。在同步辅助副本上的每个辅助数据库之后，辅助副本的同步运行状态总体上将为 HEALTHY。

注意：

1. 如果为当前主副本配置了异步提交可用性模式，那么对所有的辅助副本都采集异步方式提交事务，不管这些副本各自的可用性模式，所以要保证同步提交模式那么主副本和辅助副本都需要配置同步提交模式。

2.如果主副本与某一同步辅助会话超时，暂时将该辅助副本切换到异步提交模式。在该辅助副本重新与主副本连接后，它们将恢复同步提交模式。

【0.3.3】故障转移模式

可用性副本的主角色和辅助角色在称为"故障转移" 的过程中通常是可互换的。存在三种故障转移形式：自动故障转移（无数据丢失）、计划的手动故障转移（无数据丢失）和强制手动故障转移（可能丢失数据）。最后一种形式通常称为"强制故障转移"

自动故障转移所需条件

仅在以下条件下才发生自动故障转移：

注意：

1.在数据库级别，诸如因数据文件丢失而使数据库成为可疑数据库、删除数据库或事务日志损坏之类的数据库问题不会导致可用性组进行故障转移

2. AlwaysOn 可用性组监视自动故障转移集中两个副本的运行状况。如果任一副本失败，则该可用性组的运行状况状态将设置为"严重"。如果辅助副本失败，则自动故障转移将不可行，因为自动故障转移目标不可用。如果主副本失败，则可用性组将故障转移到辅助副本。在之前的主副本进入联机状态之前，将不存在任何自动故障转移目标。在任一情况下，为了在连续出现失败这种近乎不可能发生的情况下确保可用性，我们建议您将其他辅助副本配置为自动故障转移目标。

3.要设置故障转移模式为"自动"的前提是可用性模式是"同步提交"。

4.如果主要副本设置为手动故障转移，即使次要副本设置为自动故障转移，也无法发生自动故障转移。

5.只能设置一个自动故障转移辅助副本

 

【0.3.4】可读辅助副本

主要是解释如下图中的比较难理解的，《主角色中的连接》 和 《可读辅助副本》中的选项释义。

 

  1. 可读辅助副本（辅助角色支持的连接访问类型）

很明显，核心意思就是，当该台机器变成辅助副本的时候应该是什么角色。

1.无（无连接）

不允许任何用户连接。 辅助数据库不可用于读访问。 这是辅助角色中的默认行为。

2.仅读意向（仅读意向连接）

辅助数据库仅适用于其 Application Intent 连接属性设置为 ReadOnly 的连接（读意向连接）。

3.是（允许任何只读连接）

辅助数据库全部可用于读访问连接。 此选项允许较低版本的客户端进行连接。

（2）主角色中的链接（主角色支持的连接访问类型）

很明显，核心意思就是，当该台机器变成主副本的时候应该是什么角色。

1.允许所有连接

主数据库同时允许读写连接和只读连接。 这是主角色的默认行为。

2. 允许读/写连接（仅允许读/写连接）

当 Application Intent 连接属性设置为 ReadWrite 或未设置时，允许此连接。 不允许其 Application Intent 连接字符串关键字设置为 ReadOnly的连接。 仅允许读写连接可帮助防止您的客户错误地将读意向工作负荷连接到主副本。

注意：所有的限制只针对配置了可用性数据库，非可用性数据库不受这些连接的限制，配置读写分离至少得保证有两个可读副本，如果只有一个可读副本当可读副本变成了主副本之后会导致只读意向无副本可连接。

 

【0.3.5】alwayson同步原理

1.任何一个SQL Server里都有个叫Log Writer的线程，当任何一个SQL用户提交一个数据修改事务时，它会负责把记录本次修改的日志信息先记入一段内存中的日志缓冲区，然后再写入物理日志文件（日志固化）,所以对于任何一个数据库，日志文件里都会有所有数据变化的记录。

2.对于配置为AlwaysOn主副本的数据库，SQL Server会为它建立一个叫Log Scanner的工作线程,这个线程专门负责将日志记录从日志缓冲区或者日志文件里中读出，打包成日志块，发送给各个辅助副本。由于它的不间断工作，才使主副本上的数据变化，可以不断地向辅助副本上传播。

3.在辅助副本上，同样会有两个线程，完成相应的数据更新动作，它们是固化（Harden）和重做（Redo）。固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本的磁盘上的日志文件里（这个过程被称为"固化"）。

而重做线程，则负责从磁盘上读取日志块，将日志记录翻译成数据修改操作，在辅助副本的数据库上完成。当重做线程完成其工作以后，辅助副本上的数据库就会跟主副本一致了。AlwaysOn就是通过这种机制，保持副本之间的同步。重做线程每隔固定的时间点，会跟主副本通信，告知它自己的工作进度。主副本就能够知道两边数据的差距有多远。

这些线程在工作上各自独立，以达到更高的效率。Log Scanner负责传送日志块，而无须等待Log Writer完成日志固化；辅助副本完成日志固化以后就会发送消息到主副本，告知数据已经传递完毕，而无须等待重做完成。其设计目标，是尽可能地减少AlwaysOn所带来的额外操作对正常数据库操作的性能影响。

同步操作按下列方式维护：

1.从客户端收到事务后，主副本会将事务的日志写入事务日志，同时将该日志记录发送到辅助副本。

2.日志记录写入主数据库的事务日志后事务将不能撤消，除非在此时故障转移到尚未收到该日志的辅助副本。主副本将等待来自同步提交辅助副本的确认。

3.辅助副本将强制写入日志（固化），并将确认消息返回给主副本。

4.收到来自辅助副本的确认后，主副本将完成提交处理并向客户端发送一条确认消息。

 

【0.3.6】会话超时机制

由于软错误不能由服务器实例直接检测到，因此，软错误可能导致一个可用性副本无限期等待会话中另一个可用性副本的响应。 为了防止发生这种情况， Always On 可用性组实施了会话超时机制，此机制基于以下条件：所连接的可用性副本会在每个打开的连接上按固定间隔发送 ping。 在超时期限内收到 ping 指示连接仍是开放的且服务器实例正在通过此连接进行通信。 收到 ping后副本将重置此连接上的超时计数器。主副本和辅助副本相互 ping 以指示它们仍处于活动状态， 会话超时限制是用户可配置的副本属性，默认值为 10 秒。

如果在会话超时期限内没有收到来自另一个副本的ping，该连接将超时、连接将关闭；超时的副本进入 DISCONNECTED 状态。 即使为同步提交模式的副本，事务也将不等待该副本重新连接暂时将该辅助副本切换到异步提交模式。在该辅助副本重新与主副本连接后，它们将恢复同步提交模式。

理解掌握这些概念对部署维护AlwaysOn集群非常的有帮助，可以结合测试对概念更深入的理解。

   

注意：域服务器宕机了也不影响使用SQLServer身份验证连接副本或者监听器，Windows身份验证会受影响。所以只要不故障切换AD宕机了也不影响AlwaysOn群集的连接。这个功能减少了AlwaysON对AD的依赖，同时也减少建双域控的成本。

 

【0.4】架构版本局限性

Sql server2012：一个主副本和四个辅助副本。

【1】环境准备

【1.1】软件下载

网址：https://msdn.itellyou.cn/

（1）Windows server 2012 R2下载

文件名：cn_windows_server_2012_r2_with_update_x64_dvd_6052725.iso

SHA1：82292FA197E6C9DD9AF8F7E68E7A79A5DA1DDA2B

文件大小：5.16GB

发布时间：2014-12-15

下载链接：

ed2k://|file|cn_windows_server_2012_r2_with_update_x64_dvd_6052725.iso|5545705472|121EC13B53882E501C1438237E70810D|/

 

（2）sql server 2014 sp2 develop 下载

文件名cn_sql_server_2014_developer_edition_with_service_pack_2_x64_dvd_8967935.iso

SHA1：4E605491D4FF5C2637666498D0969FEF5E960DDB

文件大小：3.28GB

发布时间：2016-07-14

下载链接：

ed2k://|file|cn_sql_server_2014_developer_edition_with_service_pack_2_x64_dvd_8967935.iso|3518996480|B7232287C95D107EE4ED07F7C47B250C|/

【1.2】克隆之后修改服务器sid

（1）登录2008R2，查看当前的SID号。

\>whoami /user

　　

（2）2008R2自带sysperp程序，不像2003还需要去安装光盘找。

　　路径为 C:\Windows \System32\sysprep\sysprep.exe

　　

 

（3）双击执行，并且勾选

　　

 

（4）运行过程

　　　　

  　　　　

（5）所有好了之后再次验证

　　whami /user

　　　

【1.3】修改IP地址和主机名

太简单了，这里就不讲了

【1.4】操作系统与软件安装

太简单了，这里就不讲了

【1.5】修改计算机名

如此，根据前面的部署架构，把192.168.214.154计算机名修改成DC1，做为域控服务器。

（1）右击我的电脑，打开属性

（2）选择高级系统设计

 

（3）修改计算机名,点击确定。

 

（4）重启计算机

（5）再次进入该步骤，进行核验

如此，根据前面的部署架构，把192.168.214.154计算机名修改成DC1，做为域控服务器。

其他的机器分别对应DB1（151）、DB2（152）、DB3（153）改完后重启

 

 

【1.6】修改数据库计算机名

因为是克隆出来的（先装好sql server再克隆的），在【1.5】修改且重启后，要修改sql server对应的实例名称。

在DB1 DB2 DB3上分别修改数据库服务器名为DB1 DB2 DB3

 

--查看

SELECT @@SERVERNAME as InstalledName, SERVERPROPERTY('SERVERNAME') as NetworkName

 

--修改

IF @@SERVERNAME <> SERVERPROPERTY('SERVERNAME')

BEGIN

EXEC sp_dropserver@server = @@SERVERNAME

DECLARE @new_server_name SYSNAME

SELECT @new_server_name = CAST(serverproperty('servername') as SYSNAME)

EXEC sp_addserver@server = @new_server_name , @local = 'local'

END

GO

 

--核验

sp_helpserver

最后的sp_helpserver变成了我们的名称，这才表示操作成功了。

务必要重启生效

【1.7】新建数据库winodws登录账户

右击登录名-》新建登录名

 

并且给与系统管理员 sysadmin权限

 

【2】搭建域服务器与DNS

【2.1】添加域控功能

【2.1.1】修改IP与DNS

先修改ip地址，并且将dns指向自己，并且修改计算机名为DC1，升级成域控后，机器名称会自动变成dc1.alwayson.com

修改主机名后，需要重启生效。

【2.1.2】安装域控功能

 

 

 

 

后续一直下一步，然后点击安装即可。

 

【2.2】DC1提升为域控服务器与DNS配置

【2.2.1】运行域服务配置向导

在运行中输入"dcpromo" 或者如下图点击将此服务器提升为域控制器

【2.2.2】添加新林、配置域名alwayson.com

（1）配置新林及域名

 

（2）配置功能级别与管理员密码

这里配置密码为 a123456789!

 

有个警告，不用管。继续下一步

 

默认的，继续下一步

 

（3）配置域控相关数据文件、日志文件和sysvol目录

我这里是虚拟机，所以随便设置了，生产应当设置在非系统盘。

 

可以看看核心信息，比如DNS服务器，比如域名，比如NetBios名称，相关文件夹位置。

且新域管理员密码与此计算机本地管理员密码相同。

 

（4）条件检查与安装

点击安装，等着就是了。安装完后记得重启。

 

【2.2.3】检查服务器启动

重启DC1后登陆

账户名已经变成alwayson\administrator，密码还是原来的administrator；查看netlogon服务是否开启。

【2.3】DB1/DB2/DB3加入域

【2.3.1】配置DNS

需要加入域的PC机器，如DB1/DB2/DB3，其DNS都设置为域服务器192.168.214.154

 

 

【2.3.2】加入域

（1）DB1/DB2/DB3配置域为alwayson.com

（2）从域控上核验

【2.3.3】配置host文件（所有机器）

文件位置：C:\Windows\System32\drivers\etc\hosts

192.168.214.151        DB1

192.168.214.152        DB2

192.168.214.153        DB3

192.168.214.154        DC1

【2.4】构建域账户

新建一个可以登录所有机器的域账户。

【2.4.1】打开域控管理面板

 

【2.4.2】新建test域账户

（1）新建：右击Users=》新建=》用户

 

 

 

（2）设置密码及策略

下一步之后

    

最后再点下一步、完成。

 

 

 

 

（3）右击该账户（刚刚新建的那个）=>属性设置其可以登录到DB1/DB2/DB3

 

 

 

 

 

 

 

（4）设置其可以登录到DB1/DB2/DB3

 

 

（4）该用户加入用户组

右击该用户=》属性=》隶属于

 

【3】配置故障转移集群

【3.0】前置环境条件

1.操作系统建议使用企业版，有一次因为其它低版本导致群集安装失败。

2.先安装好SQLServer实例再搭建故障转移群集，否则如果在安装的过程中有群集节点故障可能导致安装失败。

同时安装SQLServer必须使用administrator本地管理员用户进行安装，其它用户可能导致某些功能安装失败！！！

3.搭建群集的3台服务器需要相同的域、相同操作系统（包括补丁，软件更新，软件版本，存储，底层bois等）、IP地址同一网段、一致的软硬件等；如果不希望配置的过程中出现麻烦最好不要去做无谓的配置修改，保持三台电脑完全一致即可。

4.加入到集群的每台服务器保证互ping正常，否则无法通过故障转移集群验证。

5.加入集群的服务器相关服务正常启动，包括：Remote Procedure Call (RPC)、Remote Registry、Server、Windows Management Instrumentation。

6.使用域账户登录

 

【3.1】所有机器添加故障转移集群功能

这里以DB1机器操作做示范：添加角色和功能

直接默认，下一步即可

直接默认，下一步即可

 

 

 

这里无需选择任何选项，直接下一步即可

 

 

 

然后在功能这一块，找到故障转移集群，勾上即可。然后继续下一步

 

 

 

 

 

直接点击安装即可。

 

 

 

安装完成

 

正确的打开方式应该如下图，否则会出现找不到故障转移群集管理器的尴尬局面；

 

【3.2】DB1配置集群管理

其实DB1/DB2/DB3中任意一台机器都可以，一台创建把其他的加入进来即可

【3.2.1】切换成域控账户登录

当我直接本地用户登录时，点击故障转移群集管理器，却出现如下提示

 

这里我们就用域管理员登录啦。alwayson\administrator

 

【3.2.2】安装故障转移群集

（1）点击创建群集

然后可以浏览查找，可以查找到所有域账户

 

运行所有测试，仔细看看报警，且不能有错误

 

（2）配置群集节点与VIP

 

（3）确认信息

 

 

 

（4）完成

 

【3.2.3】配置集群仲裁

 

我们已经有3个节点了，没必要配置仲裁了

 

 

继续下一步

 

继续下一步，直接跳到摘要了（中间那步配置群集仲裁设置被OS自动跳过了，因为检测奇数节点），点击完成

 

 

最后的仲裁节点及投票信息如下：

去域控DC1机器上，查看计算机和用户，发现已经在域控服务器上生成了

（为什么名字没显示全？是因为缩略最多显示15个字符，双击点开或查看属性就有全名了）

 

【4】Sqlserver AlwaysOn搭建

【4.0】前置环境条件

1.将域用户（需要域管理权限）配置为SQLServer服务和代理的启动用户，同时将域用户加入到SQLServer登入用户并赋予sysadmin服务器角色。

2.将域用户加入到在每台SQLServer服务器的本地用户administrator组中

3.先安装好SQLServer实例再搭建故障转移群集，否则如果在安装的过程中有群集节点故障可能导致安装失败。同时安装SQLServer必须使用administrator本地管理员用户进行安装，其它用户可能导致某些功能安装失败！！！

4.将1433、5022端口加入到防火墙（这里为了测试我已经把防火墙全部关闭了）

5.由于alwayson对于故障转移群集依赖非常的高，如果有节点由于网络原因节点连接不上会导致alwayson添加数据库失败，保证数据库服务器和域服务器之间的网络顺畅

6.使用windows身份验证的域用户搭建alwayson（这里直接用我们之前创建的域账户 alwayson\ test登录DB1~DB3）

7.加入可用性组的数据库必须要是完整模式

 

 

【4.1】配置域账户在sql和win中的权限

DB1/DB2/DB3三个机器都要操作哦

【4.1.1】配置域账户在sql中的权限

因为最开始没权限，登录肯定失败的。

先用其他管理员权限账户登上去，windows验证的或者SQ验证的均可，我这里就用SQL验证用sa了。

 

Sa验证

 

 

右击登录名=》新建登录名

然后开始创建基于windows验证的域账户，并给与sysadmin权限。

 

 

如何找到域账户在哪里呢？上图中点击搜索，然后在位置那里，选择域就可以搜索指定域账户了。

 

 

 

最后权限赋予该域账户权限sysadmin；完成

 

【4.1.2】配置域账户在win中的权限

三个机器都把域账户，添加到本地administrators组。不加会怎么样呢？会报错，具体见故障9

 

【4.2】配置sqlserver启动账户为域账户

【4.2.1】打开SSCM

 

 

【4.2.2】修改sql server代理及引擎的启动用户

先关闭上图框选出来的服务，然后先修改sql server代理，再修改sql server引擎。

 

【4.2.3】开启always on功能

 

【4.3】配置AlwaysOn可用性组（DB1上运行）

【4.3.1】登录

直接用我们当前登录服务器的域账户进行windows身份验证登录，这一步我们在【4.1.1】已经配置好过。

 

 

【4.3.2】创建测试数据库test

 

这里创建它，是为了等下做可用性组的主库。整个always on集群的同步库就基于它了。

 

【4.3.3】创建可用性组

（1）右击可用性组=》新建可用性组向导，这个开局没什么用，直接下一步。

 

（2）给定可用性组名称，这里我们就给个test_alwayson，然后下一步

 

（3）选择数据库，但他需要我们完整备份一次数据库，才能被选择

 

那我们就按照提示，备份了之后再来。这里我把reportServer一起备份了吧。

backup database test to disk='C:\bak\test.bak'

backup database ReportServer to disk='C:\bak\ReportServer.bak'

备份完之后，我们刷新一下就可以了，如下图，我们还可以一次性选择多个库，我这里选2个库吧。Test和自带的reportServer库。

 

（4）发现没有其他副本可用，直接添加副本，然后输入机器名也行，浏览也行，输入IP也行

 

 

发现连不上，报错啊

 

打开SSCM，发现原来是TCP/IP没开，赶紧把3个机器上的TCP/IP协议全部打开

 

开了之后还需要重新启动引擎。

 

 

 

 

 

 

之后再来看看。果然连上了，这里我们把DB2作为同步提交且为自动故障转移对象，DB3为异步提交的辅助副本。

可读辅助副本，这个选项一定要都选是，因为默认是否，不选的那个实力就不能读取对应数据库的信息了。

 

（5）端点选项卡，用默认的5022就可以了。

 

 

（6）备份首选项选项卡，这个我们也默认吧，一般都自己写代码做备份控制的。

 

（7）侦听选项卡，这里我们就不配置，到后面再配置吧，然后直接下一步

 

（8）初始化选项，这里我们自己新建一个共享文件夹吧c:\share_bak,然后直接下一步。

 

 

（9）开始构建创造可用性组，但有报错，这是因为啊reportserver是系统自带用户数据库，另外2个机器上已经存在了。

我把DB2/DB3上的reportserver库给删掉了。就可以了。

 

 

 

（10）查看一下摘要，没什么问题直接点安装即可。

 

（11）完成，具体步骤做了什么也可以看得到。

 

（12）查看可用性组

 

（13）各种角色功能说明

可用性模式的说明

角色

可用性模式

功能说明

主副本

同步提交

无

异步提交

无

辅助副本

同步提交

可用性组内的数据库实时同步，对于主副本的写操作的事务，只有等到辅助副本同步后才能提交，辅助副本的延迟响应可能影响性能。

异步提交

可用性组内主副本节点与辅助副本节点数据非实时同步，主副本的写操作不必等待辅助副本的响应，因此到辅助副本不会影响主副本的写操作，但是存在数据丢失风险，因此不能作为故障转移的节点。

 

故障转移模式的说明

角色

故障转移模式

功能说明

主副本

手动

无

自动

无

辅助副本

自动

当主副本节点发生故障时，通过仲裁辅助副本可以自动转为主副本

手动

可手动转为主副本

 

 

 

主角色中的连接的说明

角色

主角色中的连接

功能说明

主副本

允许所有连接

主副本同时允许读写连接和只读连接。 这是主角色的默认行为

仅允许读/写连接

允许ApplicationIntent=ReadWrite或未设置连接条件的连接。 不允许ApplicationIntent=ReadOnly的连接。 仅允许读写连接可帮助防止客户错误地将读意向工作负荷连接到主副本。

辅助副本

允许所有连接

无

仅允许读/写连接

无

 

可读辅助副本的说明

角色

可读辅助副本

功能说明

主副本

否

无

仅读意向

无

是

无

辅助副本

否

无法访问辅助副本上的可用性组内的数据库，无论是否带参数连接

仅读意向

可用性组内的数据库仅接受带有ReadOnly参数的只读连接

是

可用性组内的数据库接受任何只读连接

注：以上功能说明项为"无"，并不表示它无用，只是暂时无效，因为我们还需要考虑故障转移，当故障转移之后，它的角色就变了。

 

用SSMS查看一下同步状态，OK

 

（14）查看可用性组面板

    

 

【4.3.4】配置可用性组侦听器

（1）右击AlwaysOn高可用性下的可用性组侦听器=》添加侦听器

 

（2）配置侦听器信息

名字可以随便起，端口为外界访问端口，这里我们设置成和数据库默认端口一样1433。

IP地址选静态IP，且该IP要和之前的VIP不一样啊。这里我们设置IP为192.168.214.161

 

（3）查看与核验

 

 

并且，我们都可以直接用这个侦听IP登录了。这里我们可以看到访问的是DB1机器。

 

 

在域控、DNS上也已经出现了。

 

【4.4】基本故障转移测试

【4.4.1】手动故障转移测试

可以在任意节点，右击可用性组=》故障转移，但各个角色可选择的故障转移副本不同。

如果是主副本所在实例，则可以选择任意节点作为手动故障转移后的主节点。如果是辅助副本则只能选择自己。

 

 

因为我们做的一个同步一个异步，这里我们故障转移到DB2去。

 

需要验证一下登录，我们点击链接输入对应的登录信息即可。这里我用的是windows域账户登录，之前准备工作有说。

 

获取到了摘要信息，这个信息是一个总结信息，只是用来观看的。我们还可以把操作生成脚本，这里倒是没用到。

 

查看结果，执行完成；

 

核验：（1）查看DB1和DB2状态，发现是成功的

 

核验：（2）连接侦听器，看其连接到的是哪里

 

【4.4.2】自动故障转移

（1）关掉主库所在DB2的引擎服务，模拟故障

在SSMS，服务，SSCM中，均可关闭

 

（2）查看主库自动切换

很明显，主库已经又一次切换回DB1了。

 

（3）核验

我在DB3机器上连接可用性组侦听器IP，果然切换到DB1去了。

 

 

（4）把DB2再拉起来，发现它已经自动连上去了，且主副本中的不可用标识也恢复成可用了。

 

【4.4.3】数据同步测试

在主副本上建表且插入数据；

 

在辅助副本上查看数据

 

测试成功！

 

 

【4.5】只读路由配置

Sql server2014的只读路由，只是有个优先级，比如有2个只读，会根据优先级访问，高的故障了才会访问低的，并不能达到读负载均衡。

【4.5.1】设置可用性组数据性

根据【0.3】的原理，及【0.3.4】数据库实例在主副本、辅助副本的角色设定，我们这里需要修改一下以便测试。生产上也应当这样改。

表示如果是主副本必须连接字符串加ReadWrite，如果是辅助副本则只可以读，且连接字符串必须加ReadOnly。

 

【4.5.2】设置读写分离与只读路由

--查看可用性组信息

SELECT * FROM master.sys.availability_replicas

 

---建立read指针 - 在当前的primary上为每个副本建立副本对于的tcp连接

ALTER AVAILABILITY GROUP [test_alwayson]

MODIFY REPLICA ON

N'db1' WITH

(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://db1.alwayson.com:1433'))

 

ALTER AVAILABILITY GROUP [test_alwayson]

MODIFY REPLICA ON

N'db2' WITH

(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://db2.alwayson.com:1433'))

 

ALTER AVAILABILITY GROUP [test_alwayson]

MODIFY REPLICA ON

N'db3' WITH

(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://db3.alwayson.com:1433'))

 

----为每个可能的primary role配置对应的只读路由副本

--list列表有优先级关系，排在前面的具有更高的优先级,当db02正常时只读路由只能到db02，如果db02故障了只读路由才能路由到DB03

ALTER AVAILABILITY GROUP [test_alwayson]

MODIFY REPLICA ON

N'db1' WITH

(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('db2','db3')));

 

ALTER AVAILABILITY GROUP [test_alwayson]

MODIFY REPLICA ON

N'db2' WITH

(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('db1','db3')));

 

--查询优先级关系

SELECT ar.replica_server_name ,

rl.routing_priority ,

( SELECT ar2.replica_server_name

FROM sys.availability_read_only_routing_lists rl2

JOIN sys.availability_replicas AS ar2 ON rl2.read_only_replica_id = ar2.replica_id

WHERE rl.replica_id = rl2.replica_id

AND rl.routing_priority = rl2.routing_priority

AND rl.read_only_replica_id = rl2.read_only_replica_id

) AS 'read_only_replica_server_name'

FROM sys.availability_read_only_routing_lists rl

JOIN sys.availability_replicas AS ar ON rl.replica_id = ar.replica_id

 

------------------------------------

允许ApplicationIntent=ReadWrite或未设置连接条件的连接。 不允许ApplicationIntent=ReadOnly的连接。

仅允许读写连接可帮助防止客户错误地将读意向工作负荷连接到主副本。

 

Sql server2014的只读路由，只是有个优先级，比如有2个只读，会根据优先级访问，高的故障了才会访问低的，并不能达到读负载均衡。

 

 

 

【4.6】核验读写分离与只读路由

【4.6.1】使用SSMS核验

（1）核验读写ApplicationIntent=ReadWrite

允许ApplicationIntent=ReadWrite或未设置连接条件的连接。 不允许ApplicationIntent=ReadOnly的连接。

仅允许读写连接可帮助防止客户错误地将读意向工作负荷连接到主副本。

使用SSMC连接侦听器192.168.214.161，ApplicationIntent=ReadWrite（可读写），查看连接到的是哪个实例？当前主库实例是DB1

 

连接上去之后，我们查看一下实例属性，看看其连接到的是哪个机器？

右击实例=》属性，发现是DB1。写操作达到目的？

然后我们操作，做一些非查询功能试试，果然可以。

 

（2）核验只读路由ApplicationIntent=ReadOnly

连接参数写ApplicationIntent=ReadOnly。连接属性必须要选《认连接到数据库》 选项，这个数据库必须是可用性组数据库中的一个。

否则无法配置成读写分离。

 

我们根据【4.5.2】中的配置，查看一下，只读路由情况。

SELECT ar.replica_server_name ,

rl.routing_priority ,

( SELECT ar2.replica_server_name

FROM sys.availability_read_only_routing_lists rl2

JOIN sys.availability_replicas AS ar2 ON rl2.read_only_replica_id = ar2.replica_id

WHERE rl.replica_id = rl2.replica_id

AND rl.routing_priority = rl2.routing_priority

AND rl.read_only_replica_id = rl2.read_only_replica_id

) AS 'read_only_replica_server_name'

FROM sys.availability_read_only_routing_lists rl

JOIN sys.availability_replicas AS ar ON rl.replica_id = ar.replica_id

 

如下图，当DB为主库时，其只读路由规则为DB2,DB3,且DB2优先级比DB3高。所以预计，如果主库是DB1的时候，以只读方式连接侦听器访问的应该是DB2.

连接后我们查看一下，果然如此，连接到了DB2；

 

现在主副本是DB1，那我们现在把DB2机器服务停止，看看是否会自动连接到DB3上去。

我根本都没有断开连接然后重新连接，原本这个链接就直接自动跳到DB3去了。证明只读路由与读写分离成功了！

这个时候，我再启动DB2，看看这个连接会不会自动再跳回来。哇，真的跳回来了！

Sql server2014的只读路由，只是有个优先级，比如有2个只读，会根据优先级访问，高的故障了才会访问低的，并不能达到读负载均衡。

 

【4.6.2】使用sqlcmd核验

我们基本要用的核心参数

-U 访问用户名

-P 用户密码

-S 服务器

-K 访问参数

-d 访问数据库

-Q 需要执行的语句

-e 将要执行的语句打印出来

 

测试：只读连接

如下图，发现我们是成功了，连接到的是DB2，为什么下面那个有报错呢？是因为我测试了一下域控挂了会怎么样，所以域控登录windows验证有问题。

 

【故障解决】

【故障1】无法安装.Net Framework 3.5

Windows server 2012R2，自带的是.NET Framework 4.5,如果想装SQL server2008或者SQL server2012就需要安装 .ENT Framework 3.5或者2.0的版本，建议安装 .NET3.5 版本，我本人亲测过，成功了！如果直接装SQL server2008或者2012甚至2014，就会报：无法安装一下功能 .NET Framework 3.5。

如果找一个.NET Framework 3.5的来安装，系统会报安装了一个或者多个角色服务或功能失败，找不到原©文件等错误。

 

按照提示从控制面板-程序-启动或关闭Windows功能里看看

这和Win7，win10 ，xp操作不一样，但是原理是一样；

   

   

   

我们看到系统默认安装了.NET Framework 4.5于是隐隐有种不祥的预感，但我们还是要硬着头皮勾选3.5

 

显示需要指定备用路径，但我没有指定

 

（1）故障错误

到这里就是一个失败的安装；

（2）解决方法

从网上参考了很多：https://blog.csdn.net/sunny_lv/article/details/73603360

这篇文章里说了很多方法，大家可以尝试。

从网上找了安装盘路径下的 C:\sources\sxs简包放入指定位置后，输入备用源路径也没起作用，只能乖乖下载整个镜像文件

（WindowsServer2012R2镜像文件迅雷链接：ed2k://|file|cn_windows_server_2012_r2_vl_with_update_x64_dvd_4051059.iso|4683122688|BD0B95997679F83A4EE2D062865D8E64|/ ）

下载的镜像文件里有sxs这个文件

于是灵光乍现（投机取巧），让我们来试一试这个简包，于是单独复制sxs文件到服务器的C:/下。

填写备用源路径为C:/sxs

   

其实回想一下，备用源路径只要能指向到正确的安装盘下的sxs文件即可。之前下载的安装简包可能不是对应Windows servers 2012R2版本里切取出来的，所以使用本文方法的同学一定要注意选取对应版本的简包(我用的简包链接在文中)，然后指定备用源路径即可。

 

 

【故障2】无法使用RDO远程连接

（1）故障信息

RDO等第三方工具远程连接时

提示"远程计算机需要网络级别身份验证，而您的计算机不支持该验证，请联系您的系统管理员或者技术人员来获得帮助" 

（2）解决办法

1.先用个人电脑自带远程工具mstsc连接到服务器Windows Server 2016
2.开始-运行-gpedit.msc，进入组策略编辑器
3.找到左侧边栏计算机配置-管理模板-Windows组件-远程桌面服务-远程桌面会话主机-安全项
4.修改"远程（RDP）连接要求使用指定的安全层"，改为启用，安全层选择RDP
5.修改"要求使用网络级别的身份验证对远程连接的用户进行身份验证"，改为禁用
6.重启计算机

具体图解，看下图：

 

最终结果如下图：

具体的右边这2个选项的配置图查看如下：

要求使用网络级别的身份验证对远程连接的用户进行身份验证；

远程（RDP）连接要求使用指定的安全层；

配置好，重启即可

【故障3】没有故障转移群集管理器

（1）故障信息

安装的时候出现下图：

没有故障转移管理器工具。

我再次寻找，还是没有，无论是仪表盘上的工具按钮，还是管理工具，都没有。

原本应该正确的打开方式应该如下图：

 

 

 

（2）解决办法

我卸载了一次故障转移群集=》然后重启=-》再重新装故障转移群集=》再重启

正确的打开方式就出来了：

但是我又有了新的问题，变成了核心代码模式，没有图形界面了，具体问题和解决见【故障4】。

【故障4】如何切换回桌面模式

第一步，进入PowerShell。在命令行提示输入符处，直接输入"PowerShell"：

接下来，输入"Install-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra"：

 一旦完成该安装过程，接下来就需要重启服务器了。我们建议，如果手头上没有其他必须现在完成的工作或者机器可以暂时中断的情况下，直接在命令

行中输入"shutdown -r -t 0"实现系统重启

【故障5】客户端与域控时间不一致

未实验测试通过，慎用；

AD域中客户端时间与服务器时间不同步的解决办法

域中的计算机时间不一致，对我们来说是个不错的技术问题，而且时间不同步也会出现客户端不能正常加域和lync客户端不能登陆的问题。下面我来讲述一下我的解决办法。

 

1、域控配置

windows server 2012 成为域控后，时间设置里的，internet时间就没有了，为了解决这个问题，用以下CMD命令可解决：

w32tm /config /manualpeerlist:time.windows.com /syncfromflags:manual /reliable:yes /update

或w32tm /config /manualpeerlist:time.nist.gov /syncfromflags:manual /reliable:yes /update

因为中国地区老是不能和time.windows.com 时间同步，建议采取和国家授时中心服务器[time.nist.gov]

保持同步。

打开注册表，检查设置设置是否成功。

2、设置组策略，启动NTP服务器

3、域策略中设置windows time服务自动启动

4、客户端

更新域策略gpupdate /force

如果不重启的话，先net stop w32time，然后net start w32time

5、如果企业内有不加入域的服务器[如lync边缘服务器]，我们按如下设置。

日期和时间/internet时间/更改设置，服务器选择time.nist.gov,勾选与internet时间服务器同步，确定。

 

【故障6】集群安装失败或节点退出不了

在正常删除Cluster 节点之后，再添加节点时，报"节点已经加入群集"，无法加入，注册表信息删除后可正常移除Cluster服务,如下:

删除注册表中这两个后重新启动就可以了

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ClusDisk

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ClusSvc

   

 

【故障7】OpenService "RemoteRegistry" 失败

解决方法如下：

1.域账户登录

2.三台机器时间必须一致

 

 

【故障8】创建可用性组报错

（1）未在WSFC群集中注册该资源类型，请在Sql server配置管理器中禁用后再启用AlwaysOn.

按它说的，禁用再启用即可。

 

（2）该库已经存在

直接删除掉从库的就可以了，如果是大库，那么以norecovery的方式还原过去，然后在数据同步那里选择仅连接即可。

（3）联接辅助副本上的数据库导致了错误

这个，重新备份全备+事务备以norecovery的方式还原到辅助副本即可。

【故障9】创建可用性组侦听器报错

（1）报错信息

尝试为侦听器创建网络名称和 IP 地址失败.WSFC 服务可能未在运行或在其当前状态

VIP如下：

 

创建侦听器报错

 

（2）解决办法

下面三个思路尝试解决

（1）群集VIP和alwaysOn侦听的VIP不能一样，否则报错（如上面（1）中我贴的报错信息，就是这个情况）

（2）将域用户添加到本地管理组中

（3）原因在于必须先在"故障转移群集管理"-"服务和应用程序"上右键、配置一个"客户端访问点"，并将现有群集脱机，再将现有群集的属性中的依赖项与刚才配置的"客户端访问点"关联。

具体实操：见下一页

1、添加客户端访问点

　在任意一个节点打开"故障转移群集管理"，在左侧的"服务和应用程序"列表中选择"AlwaysOn1"，为其"添加资源"--"客户端访问点"。

 

2、使资源脱机

　　为了将前面的操作所新建的客户端访问点与需要故障转移的资源进行绑定，需要先将资源脱机，然后修改资源的属性。

 

 

3、配置依赖关系

 

 

4、使资源联机

 

 

说明：在SSMS中添加侦听器的界面。推荐！

 

5、检查结果

　　打开"SQL Server Management Studio"，在"可用性组侦听器"列表中可见名为"SqlFailOver"的侦听器。

　　转到DC1，打开"Active Directory 用户和计算机"和DNS，可见"SqlFailOver"这个虚拟网络名称（VNN）帐户及其IP地址。

 

【故障9】在加载Always on高可用性属性时出错（SSCS中开启AlwaysOn功能时）

故障信息：

 

解决办法：

把存储引擎启动域账户加入本地administrators组里。

 

【故障10】域控服务器挂了会有什么样的影响？

（1）对alwaysOn的影响

域服务器宕机了也不影响使用SQLServer身份验证连接副本或者监听器，Windows身份验证会受域服务器的影响。

所以只要不故障切换AD宕机了也不影响AlwaysOn群集的连接。这个功能减少了AlwaysON对AD的依赖，同时也减少建双域控的成本。

比如，当域控挂了，使用windows身份验证会报错如左下图，使用sql验证方式却不受影响，如右下图使用sa（也可以不用sa但权限及sid务必一样）

    

 

【故障11】尝试加入可用性组时出错

 

解决办法：把sql server引擎服务启动账户设置成带有 加入了域管理员组　、本地管理员组的域账户（比如本文的alwayson\test）

         或者直接使用域管理员账户（本文中的alwayson\administrator）

 

 

【故障12】故障转移次数限制，短时间内故障转移几次后，无法继续故障转移了

 

在测试期间由于故障转移时间间隔次数限制，可能会导致故障节点上线之后无法自动恢复

（1）错误信息

（2）解决办法

右击故障转移群集式立体，属性，然后再常规选项卡中点击管理核心群集资源组。找到故障转移选项卡，兵设置为运行故障回复。

 

还有，侦听器也要这样设计

 

【参考文献】

Windows server 2012 R2故障转移集群：https://www.cnblogs.com/wanggege/p/4752783.html

标签：alwaysOn,副本,数据库,可用性,server,故障,sql,连接,辅助副本
来源： https://www.cnblogs.com/gered/p/12255220.html