公司核心交易数据库，使用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来解决这个服务器替换，的确是一个比较省时省力的办法。