作者:桦仔
10余年DBA工作经验
微信:debolop
QQ交流群:740052625
公众号:数据库实战派
项目背景
最近,重庆的一位客户找到本人,客户的业务是 移动互联网支付,是 微信支付收单渠道的合作伙伴,其数据库主要存储的是 支付流水和交易流水。由于客户公司缺乏 专业DBA,他们希望借助本人的技术支持,完成 数据库服务器的搬迁容灾项目。
★需求:客户需要将 10楼的服务器人工搬迁到同一座楼的15楼,并且这个过程必须严格控制在 有限的停机时间内完成。
迁移面临的挑战主要是:
总停机时间少于10分钟 数据绝对不能有任何丢失
环境:
客户目前使用的数据库为 SQL Server 2008R2
操作系统为 Windows Server 2008R2。
方案讨论
针对客户的需求,我们根据SQL Server的特点 提出了多种实现方案。我们针对每个方实现案的优势与不足进行了深入分析。
方案一:数据库复制
思路:保留10楼的发布库不变,在15楼增加订阅库,通过复制功能同步数据。
优点:满足不停机的要求。致命缺陷:数据库复制是 异步的,不能保证数据的一致性。
结论:此方案无法满足客户 数据0丢失和数据强一致性的要求,故而舍弃。
方案二:日志备份
思路:在15楼新建一台服务器,将10楼的发布库完整备份还原至15楼。搬迁时,再追加一次日志备份,恢复至15楼服务器。
挑战:数据量大,日志文件(ldf)高达90GB+。操作过程需要断开所有数据库连接 将数据库设为只读模式 备份并移动日志文件 恢复日志文件后,重新设置为读写模式
问题:整个过程 超过25分钟,无法满足 10分钟停机时间 的要求。
回滚风险:若在15楼的数据库有写入操作,再回滚需要重新备份数据库,回滚时间远超15分钟。
结论:该方案虽然能保证数据完整性,但无法控制在短时间内完成,故而舍弃。
方案三:SQL Server AlwaysOn
与客户深入沟通后,我们决定采用 SQL Server AlwaysOn 高可用方案。
方案升级内容
新增成都机房节点,提高系统的可靠性和容灾能力。
数据库升级:将 数据库升级至 SQL Server 2016 SP2 版本。
操作系统升级:所有服务器升级至 Windows Server 2016。
回滚机制:如果15楼服务器出现问题,可以快速切换回 成都机房,并确保数据同步完成后能够进行故障转移。
架构升级方案解析
从示意图可以看出,目前架构需要进行如下几项升级:
新增成都机房:扩展现有架构,增加一个位于成都的机房。
数据库升级:将所有数据库升级至 SQL Server 2016 SP2 版本。
操作系统升级:将所有操作系统更新至 Windows Server 2016。
回滚方案:在15楼数据库有数据写入的情况下,如需进行回滚操作,会按照以下步骤进行:
首先,终止数据库所有连接,确保数据不再继续写入。禁用数据库账号,防止新的连接产生。等待成都从库完成数据同步后,手动将故障转移回成都机房。整个回滚过程预计在 10分钟内 完成。
升级过程记录
大约一个月后,客户通知我们,软硬件环境均已准备就绪。在数据库升级过程中,我们团队全程参与了操作。
升级后环境配置:
操作系统:Windows Server 2016
数据库:SQL Server 2016 SP2
机房带宽:各机房10M,未设置专线
VPN:通过华为防火墙内置的VPN功能
数据库大小:800GB以上
AlwaysOn节点:共计5个节点,其中重庆机房3个,成都机房2个升级后的架构更加稳健,并通过示意图可以清晰地看到优化后的系统布局。
具体实施
在构建好这个架构之后,下一步就是具体操作了。
由于采用的是点对点VPN,切换过程涉及到拆除和重建VPN连接。
下面是具体的切换步骤:
切换步骤:
将主库切换至成都机房。
拆除10楼到成都机房的VPN连接。
关闭10楼的所有服务器,并搬迁至15楼。
启动15楼的所有服务器。
在15楼重建至成都的VPN连接。VPN建好后,成都机房的主库和域控会自动与重庆机房的域控和从库进行通信,主库会将差异数据回传至重庆,无需人工干预。
将成都机房的主库切换回重庆机房15楼。
然而,这里存在一个比较棘手的问题:客户没有使用专线,两边机房之间只有10M的带宽!
如此低成本的架构,没有专线、带宽有限,仅靠硬件防火墙的VPN搭建起来的内网,SQL Server真的能够胜任吗?
答案是:没问题!SQL Server 完全可以胜任!!!
描述一下切换过程
第一步:在重庆机房节点kill掉所有数据库连接并设置程序用数据库帐号设置为禁用,禁止连接数据库
第二步:打开AlwaysOn的AG的属性界面,将成都异地节点改为同步提交模式
第三步:使用脚本查看当前数据库中各个表的记录数
第四步:打开AlwaysOn的显示面板,查看成都机房节点数据同步情况,如果已经追上主库的日志那么实施故障转移
第五步:手动进行故障转移
第六步:在成都机房节点查看AlwaysOn的转移情况
第七步:在成都机房节点使用脚本验证当前数据库中各个表的记录数是否与手动故障转移之前的记录数相同
第八步:在成都机房节点打开AlwaysOn的AG的属性界面,将所有的辅助副本都改为异步提交模式
第九步:拆除10楼到成都的VPN
第十步:重庆机房所有数据库服务器关闭SQL服务然后关机
第十一步:所有服务器搬到15楼并开机
第十二步:重建15楼到成都的VPN
第十三步:在成都机房节点kill掉所有数据库连接并设置程序用数据库帐号设置为禁用,禁止连接数据库
第十四步:在成都机房节点打开AlwaysOn的AG的属性界面,将原来重庆机房的主副本节点改为同步提交模式
第十五步:使用脚本查看当前数据库中各个表的记录数
第十六步:打开AlwaysOn的显示面板,查看重庆机房节点数据同步情况,如果已经追上主库的日志那么实施故障转移
第十七步:手动进行故障转移
第十八步:在重庆机房节点查看AlwaysOn的转移情况
第十九步:在重庆机房节点使用脚本验证当前数据库中各个表的记录数是否与手动故障转移之前的记录数相同
第二十步:在重庆机房节点打开AlwaysOn的AG的属性界面,将成都节点副本改为异步提交模式
整个过程非常顺利,没有数据丢失,停机时间控制在10分钟之内
原理概述
AlwaysOn 集群具备以下特点:
数据加密和压缩:在数据库块级别传输数据,安全高效。
自动数据补偿:确保数据在切换时自动补偿,无需手动干预。
无须重建集群:切换和回切无需重建集群,过程更简单傻瓜。
简化操作:即使不具备专业技能,也能轻松操作。
数据零丢失:保证数据的完整性,避免数据丢失。
在重庆机房关闭期间,数据会自动补偿,确保绝对不会发生数据丢失。
停机时间点:整个过程仅有两个停机时间点,每个时间点约为 5 分钟:
停机时间点 1,主库切换到成都机房
停机时间点 2,成都机房切换回去重庆机房
最后一个
为什么选择 Windows Server 2012 R2或以上操作系统?是因为该版本引入了动态仲裁机制。也就是说,即使 WSFC 集群中只剩下一个节点,整个集群也不会宕机。
利用这个机制,即使重庆机房所有服务器关闭,成都机房的数据库节点仍然可以正常工作。这与 Windows Server 2008 R2 操作系统相比,是一个显著的进步。
★在 Windows 2012 R2 时代,仍有一些老司机会延续旧习惯,将异地节点的投票权去掉。然而,这种做法在当前环境下可能导致问题,如果整个 WSFC 集群中没有任何节点具有投票权,集群会立即宕机,成都机房的 AG 状态将显示“正在解析”。这是因为 WSFC 集群中没有任何节点拥有投票权,即使成都节点处于开机状态,也无法保持集群的正常运行。
因此,需要提醒大家,如果操作系统是 Windows 2012 R2或者以上,不再需要取消异地节点的投票权。在这种新环境下,Windows 2012 R2 的动态仲裁机制可以有效解决此问题。
如下图所示,即使只有成都节点在线,整个 WSFC 集群也不会宕机。
总结
到目前为止,大家会发现 AlwaysOn对于异地机房节点容灾的部署非常有优势。仅在本地机房部署 AlwaysOn 对风险防范不利,实施 AlwaysOn 异地容灾不仅提高了系统的容错能力,还能带来更多优势。
参考文章
http://www.tech-coffee.net/understand-failover-cluster-quorum/ http://windowsitpro.com/windows-server-2012/dynamic-quorum-windows-server-2012
加入我们的微信群,与我们一起探讨数据库技术,以及SQL Server、 MySQL、PostgreSQL、MongoDB、Oracle、Redis 的相关话题。
微信群仅供学习交流使用,没有任何广告或商业活动。