前不久帮顾客施行的依附SQL Server AlwaysOn跨机房切

2019-10-11 12:14 来源:未知

最近帮客户实施的基于SQL Server AlwaysOn跨机房切换项目

 

最近一个来自重庆的客户找到走起君,客户的业务是做移动互联网支付,是微信支付收单渠道合作伙伴,数据库里存储的是支付流水和交易流水。

由于客户那边没有DBA,所以找到走起君商量一个数据库服务器搬迁项目。

 

 


项目背景

客户需要把在10楼的服务器全部搬到15楼,而且需要在有限的停机时间之内,客户使用的数据库是SQL Server2008R2,Windows2008R2

图片 1

 

客户的两个重要要求

1、总停机时间少于10分钟

2、数据不能有任何丢失

 

 

 


出方案

针对这两个要求,SQL Server有哪些可以选择的方案呢?

 

方案一 复制

使用复制,当前客户环境已经有一套数据库复制在跑,10楼的发布库不动,在15楼增加一个订阅库,数据复制到15楼,但是复制有一个致命点:不保证数据一致性,因为复制是异步的

复制只能满足要求一,不能满足要求二,只能抛弃这个方案

 

方案二 日志备份

在15楼增加一台数据库服务器,10楼的发布库做完整备份还原到15楼的数据库,然后在搬迁的时候追加一个日志备份,并还原到15楼的数据库服务器

日志备份保存的数据是完整备份到日志备份这个时间段的数据,由于每天写入的变更数据量比较大,导致ldf文件也比较大,达到40G ,在测试过程中

发现,kill掉数据库所有连接-》设置数据库为只读模式-》备份-》移动日志备份文件-》还原日志备份文件-》设置数据库为读写模式 ,整个过程花费时间超过15分钟

只能满足要求二,不能满足要求一,并且一旦迁移过程出错,回滚时间 迁移时间>要求的停机时间

回滚:一旦15楼的数据库有数据写入,要回滚需要完整备份数据库或分离数据库然后还原到10楼或附加到10楼的数据库,回滚时间无法满足小于10分钟的要求

 

方案三 AlwaysOn

跟客户商量沟通之后,最终选定SQL Server的AlwaysOn

图片 2

从示意图可以看出,目前的架构需要做如何升级

增加一个成都机房

所有数据库升级到SQL Server2014 SP2

所有操作系统升级到Windows2012R2

回滚:一旦15楼的数据库有数据写入,要回滚可以先kill掉数据库所有连接,禁用数据库帐号不让连接数据库,等成都从库同步完数据之后,重新手动故障转移回去成都机房

整个回滚过程10分钟之内可以搞定

 

 

 

然后哔哩吧啦哔哩吧啦过了一个月,客户说软件和硬件环境都已经准备好了,当中数据库升级过程走起君也有参与在内

升级完毕之后的环境

操作系统:Windows2012R2

数据库:SQL Server2014 SP2

两边机房带宽:各10M   没有拉专线

VPN:使用华为防火墙内置的VPN功能

数据库大小:100G

AlwaysOn节点数:5个  重庆机房3个  成都机房2个

 

升级之后的示意图

图片 3

 

到目前为止,大家可能已经猜到走起君做了这个架构之后要怎麽做了

由于是点对点VPN,所以切换过程涉及拆除VPN和重建VPN的过程

切换过程

(1)主库切换到成都机房

图片 4

(2)拆除10楼到成都机房的VPN

(3)10楼所有服务器关机搬到15楼

(4)15楼所有服务器开机

图片 5

(5)重建15楼到成都的VPN,建好VPN之后,成都机房的主库和域控会自动与重庆机房的域控和从库通信,主库会把差异数据发回重庆,无须人工介入

(6)成都机房主库切换回去重庆机房15楼

图片 6

 

 

这里有一个比较严重的问题

客户没有使用专线,两边机房只有10M带宽!

客户没有使用专线,两边机房只有10M带宽!

客户没有使用专线,两边机房只有10M带宽!

重要的问题说三遍!

 

这样一个低成本的架构,没有专线,带宽不高,只用硬件防火墙的VPN搭建起来的内网,SQL Server可以做得到吗???

答案是:没问题,SQL Server完全做得到!!!

 

这里软件环境需要满足下面要求

1、操作系统必须是Windows2012R2或以上版本

2、数据库必须是SQL Server2012或以上版本

 

 

再次用文字描述一下切换过程
第一步:在重庆机房节点kill掉所有数据库连接并设置程序用数据库帐号设置为禁用,禁止连接数据库
第二步:打开AlwaysOn的AG的属性界面,将成都异地节点改为同步提交模式
第三步:使用脚本查看当前数据库中各个表的记录数,脚本地址:
第四步:打开AlwaysOn的显示面板,查看成都机房节点数据同步情况,如果已经追上主库的日志那么实施故障转移
第五步:手动进行故障转移
第六步:在成都机房节点查看AlwaysOn的转移情况
第七步:在成都机房节点使用脚本验证当前数据库中各个表的记录数是否与手动故障转移之前的记录数相同,脚本地址:
第八步:在成都机房节点打开AlwaysOn的AG的属性界面,将所有的辅助副本都改为异步提交模式
第九步:拆除10楼到成都的VPN
第十步:重庆机房所有数据库服务器关闭SQL服务然后关机
第十一步:所有服务器搬到15楼并开机
第十二步:重建15楼到成都的VPN
第十三步:在成都机房节点kill掉所有数据库连接并设置程序用数据库帐号设置为禁用,禁止连接数据库
第十四步:在成都机房节点打开AlwaysOn的AG的属性界面,将原来重庆机房的主副本节点改为同步提交模式
第十五步:使用脚本查看当前数据库中各个表的记录数,脚本地址:
第十六步:打开AlwaysOn的显示面板,查看重庆机房节点数据同步情况,如果已经追上主库的日志那么实施故障转移
第十七步:手动进行故障转移
第十八步:在重庆机房节点查看AlwaysOn的转移情况
第十九步:在重庆机房节点使用脚本验证当前数据库中各个表的记录数是否与手动故障转移之前的记录数相同,脚本地址:
第二十步:在重庆机房节点打开AlwaysOn的AG的属性界面,将成都节点副本改为异步提交模式

 

 

整个过程非常顺利,没有数据丢失,停机时间控制在10分钟之内

 

 


原理

相信不少人都用过SQL Server的AlwaysOn集群,AlwaysOn集群真的是非常方便,随意切换

数据做了加密和压缩 ,数据库块级别的传输
数据自动补偿
切换和回切不需要重建集群
操作傻瓜化
数据0丢失

 

重庆机房关机时间段数据自动补偿,避免数据丢失

 图片 7

 

两个停机时间点,每个时间点大约5分钟

图片 8

时间点1

图片 9

时间点2

 

最后一个,之所以要使用Windows2012R2操作系统,是因为Windows2012R2引入了动态仲裁机制,也就是说当前WSFC集群只有一个节点的情况下

整个WSFC集群也会不会挂掉

图片 10

 

利用这个机制,当重庆机房所有服务器关机的情况下,成都机房的数据库节点依然能working,这个相比Windows2008R2是一个相当大的进步

 

这里有一个注意点

在Windows2008R2时代,因为没有动态仲裁机制,所以需要将异地节点的投票权去掉,这里有几个原因

1、当异地节点挂掉之后,整个WSFC集群节点凑不够基数,导致整个WSFC集群失去仲裁挂掉

2、主库无故切换到异地节点(设置为手动故障转移防止这种情况发生)

3、SQL2012异地节点无故变为正在解析状态(重启异地节点数据库服务器的SQL Server服务解决这个问题,现在SQL2014 SP2没出现过这个问题)

 

 

而到了Windows2012R2时代,有些老司机依然会继续使用这种做法,把异地节点的投票权去掉,这样做的话,当前整个WSFC集群没有一个节点拥有投票的情况下整个WSFC集群就会挂掉,成都机房的AG就会显示“正在解析”,这是因为当前整个WSFC集群里面没有一个节点拥有投票权,即使成都这个节点在开机状态,所以提醒一下大家,如果操作系统是Windows2012R2,不需要把异地节点投票权去掉,因为到目前为止,在上面的三种情况下,第二和第三种情况通过方法可以解决,第一种情况因为Windows2012R2引入了动态仲裁机制也不会发生

 图片 11

如上图,在只有成都节点的情况下,整个WSFC也不会挂掉


总结

 

到目前为止,走起君发现身边使用SQL Server的朋友大多只在本地机房部署AlwaysOn,而没有部署AlwaysOn异地节点

只在本地机房部署AlwaysOn是不利于应对风险的,做AlwaysOn异地容灾其实还有很多好处

 

 

使用场景

机房断网断电:之前有一个新闻《脉脉失联的15个小时》,联通净网行动把机房断网了,如果做了AlwaysOn异地节点那么可以把主库先切换到别的机房,应用也一并切换过去

那么就可以规避这种风险了

 

BI:BI抽取大量数据会影响线上的网络稳定性,部署AlwaysOn异地节点,BI从异地节点抽取业务数据,可以减少对业务的影响

 

数据库备份集中保存:因为线上服务器的磁盘容量一般都很有限,一般只保留几天或者一个星期的数据库备份,部署AlwaysOn异地,对异地节点数据库做完整备份

然后拷贝到备份服务器或磁带库,这样就可以保存比较长时间的数据库备份,即使开发要找回半年甚至一年之前的那个数据也是可以的

 

SQL Review:代码审核,收集数据库性能数据,排查性能问题,尽可能减少对主库的影响

 

最后这次项目的整个切换过程还有很多细节,就不写在文章里了,有兴趣的朋友可以发站短跟我交流^_^

 

 

参考文章

 

附上AlwaysOn搭建教程
第一篇

第二篇

第三篇

第四篇

 

如有不对的地方,欢迎大家拍砖o(∩_∩)o 

本文版权归作者所有,未经作者同意不得转载。

从0开始搭建SQL Server AlwaysOn 第四篇(配置异地机房节点)

 

第一篇

第二篇

第三篇

第四篇

搭建非域AlwaysOn win2016 SQL2016

SQL Server AG集群启动不起来的临时自救大招

 

 

这一篇是从0开始搭建SQL Server AlwaysOn 的第四篇,这一篇开始搭建异地机房节点

 

注意点1

注意异地节点最好至少有2个AG节点,否则在本地节点进行手动故障转移的时候会出现仲裁警告,提示WSFC集群有脱机危险

在异地节点只有一个的情况下,虽然Windows2012R2有动态仲裁机制,但是,当本地节点非优雅宕机的情况下,整个WSFC集群有可能得不到任何票数

也就是异地节点也得不到票数而导致整个WSFC集群脱机!!

 

注意点2

当进行手动故障转移的时候,更新DNS缓存需要10分钟,所以当进行手动故障转移之后,用侦听器ip连接SQL Server会很慢,这是因为还在更新DNS缓存

 

 


步骤

这一篇依然使用step by step的方式介绍怎麽搭建AlwaysOn异地机房节点

 

新加异地机房节点机器名:

 

1、在异地节点上安装故障转移集群

 

 

2、在本地机房节点机器上打开故障转移集群管理器,添加一个节点

图片 12

 

3、验证配置

 图片 13

 

4、解决新加节点OU不同问题,只需修改组织单位ou,不需要修改站点site,因为如果本地机房和异地机房的域设置了site,在验证配置的时候会警告,当然可以忽略也可以修正

因为只是警告已而,忽略也无所谓

 

 

5、添加节点成功

图片 14

 

6、在新节点上安装好SQL Server并优化SQL Server,这里忽略安装和优化步骤

 

7、把异地机房新节点添加到alwayson可用性组里,打开alwayson的可用性属性界面,可用性组名称为:AGWMSJXC

 图片 15

可以看到添加了异地机房节点之后,这个异地机房节点还没有联接到可用性组,也就是当前可用性组还没识别到这个异地机房节点

图片 16

 

8、对侦听器添加另一个子网的VIP,这一步,如果可用性组没有启用可用性组侦听器那么这一步可以忽略

如果可用性组启用了侦听器,那么需要分两种情况

1、异地节点的网段跟本地机房是一样的,比如都是192.168.1.x ,那么这一步也不需要做

2、异地节点的网段跟本地机房是不一样的,也就是跨子网,比如本地机房是192.168.1.x,异地机房是192.168.10.x,那么这一步需要做

图片 17

图片 18

现在侦听器IP有两个,一个是本地机房网段的IP,一个是异地机房网段的IP

图片 19

 

添加了新的侦听器vip之后,故障转移集群管理器里会自动将这个侦听器vip资源脱机

 

 

 

9、新建一个测试可用性组,主要用来打通/开启本地节点和异地节点的5022端口

 图片 20

建好之后,在原AG刷新一下会看到异地节点JXCA-WMS08已经自动联接到可用性组AGWMSJXC

 

 

10、对数据库进行备份还原到异地节点JXCA-WMS08,在异地节点JXCA-WMS08上进行操作,将数据库逐个点击联接到可用性组

图片 21

 

11、异地节点添加完成

图片 22

 

 

12、手动故障转移主副本到异地节点

注意当只有一个异地节点的时候,正在验证WSFC仲裁投票配置那一栏会出现警告!

图片 23

故障转移之后会发现异地节点的侦听器ip联机,本地节点的侦听器ip脱机

图片 24

 

13、在异地节点上使用异地节点侦听器ip连接SQL Server,并写入测试数据

图片 25

 

14、把主副本手动故障转移回来本地节点

图片 26

 

15、用本地节点侦听器ip连接SQL Server,发现刚才对异地节点侦听器ip的数据写入都已经同步过来本地机房节点

 图片 27

 

16、添加WSFC集群IP地址资源的异地机房IP,在WSFC管理器里选中群集核心资源下面的服务器名称,右键-》属性

图片 28

添加一个异地机房的WSFC的vip:192.168.7.130

图片 29

图片 30

图片 31

添加成功之后vip会显示脱机这是因为当前WSFC主节点不在异地机房的节点上,而是本地机房的节点上

图片 32

 

 

17、把WSFC主节点转移到异地机房的某个节点,然后把本地所有节点都关机

图片 33

图片 34

 

这时候把本地机房的所有节点关机

 

图片 35

现在用异地机房节点的WSFC的vip连接WSFC集群

图片 36

图片 37

可以发现WSFC的主节点已经转移到WIN-BDKSOOLDV18这个异地节点上了,而且群集资源还是联机状态

图片 38

 

18、没有加入域的应用服务器(IIS服务器)如果需要用侦听器名称来连接alwayson集群是不行的,解决方法是修改

应用服务器的hosts文件,写上侦听器名和侦听器ip,这样客户端才能用侦听器名称连接alwayson集群,客户端的webconfig文件

里写侦听器名称,这样即使failover到异地节点也不需要修改应用服务器的webconfig文件,当然应用服务器加入了域就不用了,、

加入了域的应用服务器会自动去查询DC上的DNS管理器找到alwayson的侦听器名称

图片 39

图片 40

hosts文件

testaglisten  192.168.10.91
testaglisten  192.168.11.91

 

 

 

提示:实际上第16步不是必须的,你可以不添加WSFC的异地子网的vip,但是当本地机房所有节点关机之后

你就不能用本地的vip:192.168.6.60来连接WSFC集群,也就无法管理WSFC集群

 

 

附上结构图

两个网段,所以会有两个侦听器IP,但是同一个时刻只有一个侦听器IP是联机状态,在WSFC集群管理器里查看

主站点:192.168.6x

DR站点:192.168.7.x

图片 41

故障转移到DR站点之后

图片 42

 

 

参考文章:

 

如有不对的地方,欢迎大家拍砖o(∩_∩)o 

本文版权归作者所有,未经作者同意不得转载。

版权声明:本文由彩民之家高手论坛发布于彩民之家高手论坛,转载请注明出处:前不久帮顾客施行的依附SQL Server AlwaysOn跨机房切