SQL Server 2016 Failover Cluster + ALwaysOn

SQL Server 2016 Failover Cluster + ALwaysOn 环境的搭建

近期公司为了提升服务的可用性，就想到了部署AlwaysOn，以前的环境只是部署了SQL Server Failover Cluster，因此决定将云端放一台SQL Server来配置ALwaysOn，具体思路就是在本地的SQL Server Failover Cluster中再增长一个节点，而后将新家的节点放到Azure云端，而后在这两个实例之间配置AlwaysOn，部署后，有个问题就是集群之间没法自动故障转移，须要手动干预才能够具体后期咱们再作详细介绍，废话就很少说了，开始实践配置；
环境介绍：

Hostname：DC1
Role：DC
IP:192.168.5.20
Domain：ixmsoft.com
Hostname：ISCSI
IP:192.168.5.38
Role:Storage
Hostname：S1
Role：SQL Server 2016
IP:192.168.5.41
Hostname：S2
Role：SQL Server 2016
IP:192.168.5.42
Hostname：AO1
Role：SQL Server 2016
IP:192.168.5.43
SQL-CLUSTER
192.168.5.46
SQLCLUSTER
192.168.5.47
HA-LP1
ListenIP：192.168.5.48

由于要作磁盘共享，因此咱们使用系统自带的ISCSI作为链接器；
咱们首先安装配置ISCSI服务器：
首先是挂载两块盘：一块是Data：50G，一块是仲裁：10G

而后安装ISCSI目标服务器

咱们安装后，咱们打开ISCSI管理---建立ISCSI虚拟磁盘

咱们新选择DATA盘

咱们增长须要分配磁盘的计算机IP
咱们增长两台SQL Server服务器

确认信息

建立完成


再次新建一个虚拟磁盘用于仲裁

设置磁盘名称

全部的磁盘已增长完成

咱们开始从5.41上经过ISCSI链接程序链接共享磁盘

提示确认启动服务

输入ISCSI服务器地址，快速连接

已链接

卷和设备已加载

咱们此时就能够在192.168.5.41上看见分配的两块磁盘了

咱们同理也按照上面的方法，在192.168.5.42上进行ISCSI连接
准备好以上操做后，咱们就能够开始安装故障转移集群了；
咱们首先在S1上进行操做安装

安装完成

安装后，咱们一样在第二台S2上进行安装，安装后，咱们就打开集群管理器
右击故障转移集群管理器----验证配置

增长两台SQL Server服务器

验证经过后，点击完成

验证经过后，咱们就能够建立了；
咱们定义集群名称及IP
SQL-CLUSTER
192.168.5.46

定之后，确认信息

开始建立集群

定义完成

两个节点信息

磁盘信息

配置仲裁

高级仲裁选项

选择全部节点

选择仲裁磁盘

咱们同时将第一个磁盘增长到群集共享卷

咱们准备安装SQL Server 2016

定义SQL Server网络名称
SQLCLUSTER

选择数据磁盘

定义群集网络IP
192.168.5.47

定义帐户信息

定义数据目录，自动选择磁盘共享卷目录

安装完成

咱们在群集管理器中就能够看见多了一个角色及管理IP

咱们准备安装第二个节点

下一步便可

默认便可

确认信息


节点增长完成

测试集群
咱们从节点1切换到节点2

切换中

切换完成

咱们使用SSMS进行链接测试
咱们使用SQL集群地址进行链接

咱们使用群集网络地址连接

咱们查看集群属性----集群化--true

到此咱们SQL Server的Failover Cluster已经配置完成。。

SQL Server 2016 Failover + ALwaysOn功能配置介绍

咱们上一篇介绍了SQL Server 2016 Failover Cluster的配置，今天咱们继续上一篇没有完成的配置介绍，准备增长一个节点，而后配置实现AlwaysOn配置，实现SQL Server 2016 Failover Cluster+ ALwaysOn达到SQL Server的单点故障及高可用性，SQL Server 2016 Failover Cluster已经完成了配置，接着咱们配置 ALwaysOn，咱们准备了一台SQL服务器，可是也须要加入到集群节点；咱们下面是上节的配置介绍图；
Hostname：DC1
Role：DC
IP:192.168.5.20
Domain：ixmsoft.com
Hostname：ISCSI
IP:192.168.5.38
Role:Storage
Hostname：S1
Role：SQL Server 2016
IP:192.168.5.41
Hostname：S2
Role：SQL Server 2016
IP:192.168.5.42
Hostname：AO1
Role：SQL Server 2016
IP:192.168.5.43
SQL-CLUSTER
192.168.5.46
SQLCLUSTER
192.168.5.47
HA-LP1
ListenIP：192.168.5.48

咱们首先在新的节点上安装集群故障转移角色

咱们如今在群集节点上增长节点，将第三台SQL加入该节点

输入新节点的名称

验证经过

测试经过后，直接增长节点

节点增长完成

咱们再次查看节点信息

咱们接着安装独立SQL实例

咱们安装功能角色

必需要命名一个实例，由于已经在集群中建立了一个默认实例；若是你已在群集中装了一个SQL群集实例，则再在群集中的节点上安装SQL实例时（不管单机
仍是群集的），不能再使用这个实例名称。也就是说你已经在群集节点一、2上装了群集的SQL
默认实例的话，则在节点3上也不能再安装单机的SQL默认实例。这种状况下能够选择在节点
上3安装一个SQL命名实例，

定义帐户信息

服务器配置信息

数据目录咱们定义到本地便可

安装完成

节点三安装完后，咱们发现服务没有端口，默认额SQL 端口是1433，因此咱们修改默认端口---SQL Server配置管理中

SQL Server 2016 Failover Cluster+ ALwaysOn(三)
咱们前面两篇文章介绍了SQL Server 2016 Failover Cluster的配置，同时又介绍配置新增AlwaysOn节点的先前条件，今天咱们主要介绍Always的详细配置。咱们前面已经提到了，若是要实现SQL Server 2016 Failover Cluster+ ALwaysOn，SQL Server Failover Cluster两个节点或者多个节点安装一个SQL 实例，而后ALwaysOn也须要安装一个单独的实例，虽然AlwaysOn节点必需要加入Faillover Cluster中，可是要建立AlwaysOn必需要它和以前的SQL群集实例之间建立AlwaysOn可用性组关系。另外AlwaysOn功能的开启是在实例级设置的，这里一共有2个SQL实例，因此就须要对这2个SQL实例分别进行设置。对于SQL群集实例，在其任一全部者节点上使用SQL Server configuration manager设置一次就能够了（重启SQL服务后生效）。
咱们仍是继续回顾上面的架构图

接下来咱们配置ALwaysOn High Availability，咱们发现提示错误，可是有引导咱们如何配置

咱们经过SSMS右击--AlwayOn High Avaliablity 会有一个提示，意思是必须为服务器实例启用AlwaysOn功能，以后才能在此实例上建立可用性组，若要启用AlowaysOn，请打开SQL Server配置管理器，右键单击SQL Server实例名称，选择属性，而后使用SQL Server属性对话框的AlwaysOn高可用性选项卡，咱们连接集群地址，点击ALways High Availability,提示咱们开启的方法了
注意：咱们使用SSMS链接到SQL Server后，在服务器属性对话框中,单击通常页面。 的HADR启用属性
显示下列值之一:真正的若是启用了老是在可用性组织；假,若是老是在可用性组是禁用的。

因此咱们要开启功能

SQL Server服务---属性--右击

咱们将SQL Server服务的登陆帐户换成域帐户

咱们勾选启用AlwayOn可用性组

应用--确认后，须要重启数据库服务

正在重启服务

第二台服务器的AlwaysOn当节点切换到节点2的时候，发先是自动勾选的；因此不用勾选；另外当角色不在操做的节点的时候，咱们就会发现LWAYSON高可用没法操做；属于正常现
象；咱们能够经过系统提示的信息就会知道

咱们再次查看角色的状态：如下状态属于正常现象，缘由是因为启用了ALwaysOn高可用

这种状况下能够选择在节点上3安装一个SQL命名实例，而后在它和以前的SQL群集实例之间建立AlwaysOn可用性组关系。
另外AlwaysOn功能的开启是在实例级设置的，这里你一共有2个SQL实例，因此就须要对这2个SQL实例分别进行设置。对于SQL群集实例，在其任一全部者节点上使用SQL Server
configuration manager设置一次就能够了（重启SQL服务后生效）。
咱们一样先将节点三的ALwaysOn高可用性功能打开

咱们用SSMS连接实例

咱们都知道高可用性是基于DB的，因此咱们须要建立数据库：HAGourpDB1

同时建立一张表，perinfo

咱们插入数据

咱们开始在集群实例下建立高可用性组

勾选数据库层运行状态检测，定义高可用性组的名称：HA-GP1

提示须要首先完整备份

因此咱们先备份一下

完整备份及备份类型

备份完成

咱们一样备份Log

咱们须要将备份的数据库和log在三节点还原一次

恢复状态：RESTORE WITH NORECOVERY

恢复完成

数据库状态未还原模式

恢复事务log

一样选择恢复状态

恢复完成

咱们继续建立高可用性组，知足条件继续下一步

咱们增长副本

不管是主副本或者辅助副本都选择同步提交模式，辅助副本的Readable Secondary选择为Yes。只是为了后面的只读辅助数据库准备。

AlwaysOn和镜像同样都采用Endpoint（端点）来进行数据传输。AlwaysOn使用端点是为了和辅助副本进行日志传输和心跳线的通讯

备份优先级勾选Prefer Secondary。意思是有限考虑辅助副本上作数据备份。只有在没有辅助副本的状况下才使用主副本。把辅助副本的优先级别调为100，而主副本50。

咱们监听端口稍后建立

确认便可---yes

这个地方是选择初始化数据库的方式。若是你选择Full，你须要提供一个共享地址，AlwaysOn本身自动备份数据库而后还原到目标的辅助副本上。这里咱们选择Join only，因此
咱们须要事先把数据库备份并还原到目标的辅助数据库上----Join only

开始下一步后，咱们查看状态

建立完成


咱们展开数据库高可用性组

咱们查看角色会多出一个高可用性组角色

咱们接着建立一个监听
AlwaysOn建立后，客户端就须要进行链接，为了让应用程序可以透明地链接到主副本而不受故障故障转移的影响，咱们须要建立一个侦听器，侦听器就是一个虚拟的网络名称，能够经过这个虚拟网络名称访问可用性组，而不用关心链接的是哪个节点，它会自动将请求转发到主节点，当主节点发生故障后，辅助节点会变为主节点，侦听器也会自动去侦听主节点。
一个侦听器包括虚拟IP地址、虚拟网络名称、端口号三个元素，一旦建立成功，虚拟网络名称会注册到DNS中，同时为可用性组资源添加IP地址资源和网络名称资源。用户就可使用此名称来链接到可用性组中。与故障转移群集不一样，除了使用虚拟网络名称以外，主副本的真实实例名还能够被用来链接。
SQL Server2012早期版本的SQL Server只有在实例启动的时候地会尝试绑定IP和端口，可是SQL Server2012却容许在副本实例处于运行情况的时候随时绑定新的IP地址、网络名称和端口号。所以能够为随时为为可用性组添加侦听器，并且这个操做会当即生效。当添加了侦听器以后，在SQL Server的错误日志中能够看到相似：在虚拟网络名称上中止和启动侦听器的消息。
要注意的是，SQLBrowser服务是不支持Listener的。这是由于应用程序在使用Listener的虚拟网络名链接SQLServer时，是以一个默认实例的形式进行访问的（只有主机名，没有实例名），所以客户端根本就不会去尝试使用SQLBrowser服务。

定义监听名称及IP
名称：HA-LST;
IP地址：192.168.5.48;
Port为1433

定义完成

咱们在查看角色，就会发现有对应的管理地址了

定义完成后，咱们能够查看高可用行组的显示面板

咱们能够经过显示面板查看高可用性组的状态

接下来咱们切换一下；切换前咱们须要注意一个问题：切换的时候不能在集群管理器里面切换，须要在高可用性组下切换，否则会有问题，就算切换成功了，有些数据也会出现问题
咱们首先在集群管理器里面查看节点全部者

另外咱们链接到群集节点后，发现高可用性组下的可用性副本的节点属于辅助节点；

接下来咱们准备开始切换，咱们使用SSMS链接到第三个节点实例
查看当前可用性组下在第三个节点处于辅助副本状态

咱们开始切换

选择主副本

确认信息

转移完成

咱们再查看AO1第三节点的AG状态就成了主副本了

咱们再从主切换到备

选择新的主副本

连接副本

开始链接

连接成功

确认转移信息

转移完成

咱们从SQLCLUSTER上插入一条数据

而后从AO1上查看数据

咱们从AO1上插入数据提示，数据库为只读，因此没法插入数据

缘由是因为当前节点属于第二节点，若是可读可写的话，须要将该节点转移到主副本节点才能够

咱们将AO1\ALWAYON下的AG下的HA-GP1从从副本转移到主副本咱们再次插入数据

转移完成


咱们再次尝试插入数据

咱们从SQLCLUSTER集群节点查看数据是否同步

咱们再次到SQLCLUSTER节点插入数据，提示错误
缘由是节点属于AO1

可是咱们查看数据，从当前节点从AO1插入的数据依然能够同步到SQLCLUSTER

各副本间的数据同步
AlwaysOn必需要维护各副本间的数据一致性，当主副本上的数据发生变化，会同步到辅助副本上。这里AlwaysOn经过三个步骤来完成：
步骤1：主副本记录发生变化的数据；
步骤2：将记录传输到各个辅助副本；
步骤3:把数据变化操做在辅助副本上执行一遍。
具体实现以下：
在主副本和辅助副本上，SQL Server都会启动相应的线程来完成相应的任务。对于通常的SQL Server服务器，即没有配置高可用性，会运行Log Writer的线程，当发生数据修改事务时，此线程负责将本次操对应的日志信息记录到日志缓冲区中，而后再写入到物理日志文件。但若是配置了AlwaysOny主副本的数据库，SQL Server会为它创建一个叫Log Scanner的线程，不间断的工做，负责将日志从日志缓冲区或日志文件里读出，打包成日志块，发送到辅助副本。所以能够保证发生的数据变化，不断送给各辅助副本。
辅助副本上存在固化和重作两个线程完成数据更新操做，固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本磁盘上的日志文件里，所以称为固化，而后重作线程负责从磁盘上读取日志块，将日志记录对应的操做重演一遍，此时主副本和辅助副本上的数据就一致了。重作线程每隔固定的时间点，会跟主副本通讯，告知本身的工做进度。主副本由此知道两边数据的差距。Log Scanner负责传送日志块，不须要等待Log Writer完成日志固化；辅助副本完成日志固化之后就会发送消息到主副本，告知数据传输完成，而不须要等待重作完成，这样各自独立的设计，是尽量减小 AlwaysOn所带来的操做对数据库性能的影响。

SQL Server 2016 ALwaysOn 增多个客户端访问点(侦听器)

高文龙 关注 0人评论 1181人阅读 2018-01-11 11:00:12

咱们前面3片文章介绍了SQL Server 2016 Failover Cluster+ ALwaysOn的完整配置，今天咱们介绍一下若是给ALwaysOn增长多个客户端访问点，常规状况下，每一个可用性组只有一个单独的可用性组侦听器（Listener），可是在某些极端状况下可能会对相同的可用性组建立多个侦听器。好比一些历史遗留问题。此时可能须要建立一个额外的侦听器用于硬编码。
可是，经过图形化界面（SSMS）、T-SQL甚至PowerShell都不能建立第二个侦听器，必须使用Failover Cluster Manager来实现。咱们在咱们的“SQLAG”角色内建立一个客户端接入点（Client Access Point）资源。按下面步骤：
咱们打开故障转移群集管理器----角色---选择AG---增长资源--客户端访问点

咱们就能够定义客户端访问点名称及对应的访问点IP

确认信息

增长完成

此时咱们就能够在角色---AG下看见两个访问名称及IP地址

状态是部分运行中

咱们资源---发现刚才新增长的是脱机状态

此时咱们右键新的客户端访问点并选择属性：

依赖关系

选择以前的监听器

咱们右击联机便可

联机后，咱们用这两个监听器地址均可以连接管理的

 

SQL Server 2016 Failover +AlwaysOn 增长数据库到可用性组

高文龙 关注 0人评论 1611人阅读 2018-01-11 11:20:30

SQL Server Failover +AlwaysOn 增长数据库到可用性组
前面几篇文章都已经详细介绍了SQL Server Failover +AlwaysOn 的配置，今天咱们主要介绍SQL Server Failover Cluster+AlwaysOn下 增长数据库到可用性组
咱们首先须要建立一个数据库及表

数据库名称
HAGroupDB2

建立表

给表插入数据

咱们把这个数据库增长到高可用性组中；当前新建的数据库没有同步

咱们再高可用性组下增长数据库

提示须要咱们完整备份一下

因此咱们备份

咱们同时也备份事务日志

备份完成后，咱们换须要将备份的数据库和事物log在节点3上进行还原

还原数据库

还原时候，选项中必须选择还原状态：RESTORE WITH NORECOVERY

数据库还原完成

咱们查看还原状态

再还原事物日志


还原选项---咱们选择第二个选项---RESOTRE WITH NORECOVERY

还原完成

咱们还原了数据库和事务日志后，数据库的状态未正在还原状态

接下来咱们就开始增长数据库到AG中了

咱们选择Join only

咱们连接已存在的副本服务器

链接成功

加入成功

咱们查看AG中的数据库信息

查看集群数据库的状态，也成为了已同步


咱们查看面板，一切正常

综合上面的操做，咱们可使用powershell来完成

$DatabaseBackupFile = "\\share\backups\MyDatabase.bak"  
$LogBackupFile = "\\share\backups\MyDatabase.trn"  
$MyAgPrimaryPath = "SQLSERVER:\SQL\PrimaryServer\InstanceName\AvailabilityGroups\MyAg"  
$MyAgSecondaryPath = "SQLSERVER:\SQL\SecondaryServer\InstanceName\AvailabilityGroups\MyAg"  

Backup-SqlDatabase -Database "MyDatabase" -BackupFile $DatabaseBackupFile -ServerInstance "PrimaryServer\InstanceName"  
Backup-SqlDatabase -Database "MyDatabase" -BackupFile $LogBackupFile -ServerInstance "PrimaryServer\InstanceName" -BackupAction 'Log'  

Restore-SqlDatabase -Database "MyDatabase" -BackupFile $DatabaseBackupFile -ServerInstance "SecondaryServer\InstanceName" -NoRecovery  
Restore-SqlDatabase -Database "MyDatabase" -BackupFile $LogBackupFile -ServerInstance "SecondaryServer\InstanceName" -RestoreAction 'Log' -NoRecovery  

Add-SqlAvailabilityDatabase -Path $MyAgPrimaryPath -Database "MyDatabase"  
Add-SqlAvailabilityDatabase -Path $MyAgSecondaryPath -Database "MyDatabase"

©著做权归做者全部：来自51CTO博客做者高文龙的原创做品，如需转载，请注明出处，不然将追究法律责任