虚IP解决AlWaysON读库服务器过保替换

合集 - 复杂问题简单化(11)

1.学会把复杂问题简单化2019-01-10 2.稻盛和夫：真正的聪明人，善于把事物简单化2019-01-10 3.马伟明：任何事物，只要抓住了规律，就等于牵住了牛鼻子2019-01-09 4.思考能力的提升从把复杂问题简单化开始2024-10-31 5.数据库运维核心--可控2021-08-13 6.部分领域核心领悟总结2021-09-10 7.真正的高手，都很简单2021-01-25

8.虚IP解决AlWaysON读库服务器过保替换2019-09-09

9.核心只读数据库实例故障应急解决方案2019-07-31 10.数据抽取平台pydatax介绍--实现和项目使用2024-02-27 11.用ELK分析每天4亿多条腾讯云MySQL审计日志(1)--解决过程2021-03-04

公司核心交易数据库，使用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，提了个建议： 能否用虚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分钟）