公司核心交易数据库,使用SQL 2012 AlWaysON的1主4从,有2台(8.14,8.15)从库服务器,已经使用3年多,过保替换,新买的2台服务器已经安装好,一开始方案如下:
服务器(8.14)替换方案: 1, 需提前修改程序连接8.14的配置和DBMS,改成8.15服务器并重启相关服务 2, 监控几天未有程序使用8.14数据库服务器 3, 凌晨2点—5点,在AlwaysON集群中删除8.14服务器 4, 修改原8.14(1.14)成新IP,修改8.84的IP成(8.14) 5, 配置新的8.14机器加入8.13的故障转移集群 6, 新8.14还原3个数据库和日志 7, 配置新8.14的3个数据库加入AlwaysON集群 8, 测试新8.14的可用性
自己想了想,这个机会,可以用DNS解决以前程序连IP的故障问题,一旦程序连的8.14服务器出现故障,连接8.14程序要全部修改重启,太麻烦,故障一发生,一定是个大事故,想用这个机会用DNS解决,到时真的出问题
只需要修改DNS解析IP就可以。
后来跟开发和测试沟通, 测试觉得涉及到程序太多,修改起来的确麻烦,开发那边觉得,公司内网的DNS解析稳定性不可靠,一个开发负责人说他以前的有老东家准备用dns域名来做,后来取消了,不可靠。
这么多人反对,用DNS方案来替换不行。
后来大家讨论: 能否用虚IP来解决这个程序修改的问题,这样以前用8.14,8.15 这样的IP就不用改任何程序,把这个类似的8.14等IP提成虚IP,因为Windows没有虚IP的说法,就是直接加上一个IP。
在线下做了一个模拟环境,模拟线上用虚IP来更换服务器:
测试报告 线下测试机: 192.168.60.36(主) 192.168.60.133/60.152/60.247 (备机) 配置SQL Server AlwaysON 1主3从 测试删除节点: 1, 删除备机60.133的SQL Server AlwaysON集群 (1分钟内) 2, 删除备机60.133的Windows集群 (1分钟内) 3, 修改60.133的IP 4, 在60.247增加60.133的新IP 5, 其他机器连60.133数据库正常
测试下来,用虚IP方案是可行了,后来又连续测试了一周,没有什么异常。后来和开发测试讨论,方案如下:
8.15旧机器替换 删除8.15节点: 1, 删除备机8.15的SQL Server AlwaysON集群 (1分钟) 2, 删除备机8.15的Windows集群 (1分钟) 3, 修改8.14的IP (3分钟) 4, 在8.14增加8.15的新IP (3分钟) 5, 测试连8.15数据库是否正常 (10分钟) 新加节点8.85 提前配置好账号密码(已处理),提前几个小时还原最新的完整数据库备份(3个),提前半小时备份最新的3个数据库日志 1, 新加备机8.85到windows集群 (1分钟) 2, 还原最新的8.13的3个数据库日志 (15分钟) 3, 配置8.85到SQL Server AlwaysON集群 (15分钟) 4, 删除8.14的8.15 IP (3分钟) 5, 在8.85新加8.15 IP (3分钟) 6, 测试连8.15数据库是否正常 (10分钟)
定在周日凌晨的1:00--5:00,这个时间,2台机器替换下来,花了大约2个小时,替换过程比较顺利。
总结:
1,以前我们老是说linux的虚IP,在windows中很少去做这个,这次把实机的IP变成一个可以虚的IP,根据需要在不同的服务器增加,删除。达到减少服务器不可用时间,又能快速解决问题。
2,用虚IP来解决这个服务器替换,的确是一个比较省时省力的办法。
原文地址:https://www.cnblogs.com/zping/p/11493411.html
时间: 2024-10-16 16:36:52