所以切换进程涉及拆除VPN和重建VPN的进程 切换进程 （1）主库切换到成都机房 （2）拆除10楼到成都机房的VPN （3）10楼所有处事器关机搬到15楼 （4）15楼所有处事器开机 （5）重建15楼到成都的VPN。

并且需要在有限的停机时间之内，此刻SQL2014 SP2没呈现过这个问题） 而到了Windows2012R2时代，把异地节点的投票权去掉， 由于客户何处没有DBA，客户利用的数据库是SQL Server2008R2。

在15楼增加一个订阅库，要回滚需要完整备份数据库或疏散数据库然后还原到10楼或附加到10楼的数据库。

有乐趣的伴侣可以发站短跟我交换^_^ 参考文章： 附上AlwaysOn搭建教程 第一篇 第二篇 第三篇 如有差池的处所，不能满意要求二，这个对比Windows2008R2是一个相当大的进步 这里有一个留意点 在Windows2008R2时代。

纵然开拓要找回半年甚至一年之前的谁人数据也是可以的 最后这次项目标整个切换进程尚有许多细节，今朝的架构需要做如何进级 增加一个成都机房 所有数据库进级到SQL Server2014 SP2 所有操纵系统进级到Windows2012R2 回滚：一旦15楼的数据库有数据写入，停机时间节制在10分钟之内 道理 相信不少人都用过SQL Server的AlwaysOn集群，kill掉数据库所有毗连-》配置数据库为只读模式-》备份-》移动日志备份文件-》还原日志备份文件-》配置数据库为读写模式 ，查察重庆机房节点数据同步环境，傍边数据库进级进程走起君也有参加在内 进级完毕之后的情况 操纵系统：Windows2012R2 数据库：SQL Server2014 SP2 双方机房带宽：各10M 没有拉专线 VPN：利用华为防火墙内置的VPN成果 数据库巨细：100G+ AlwaysOn节点数：5个 重庆机房3个 成都机房2个 进级之后的示意图 到今朝为止，有些老司机依然会继承利用这种做法，要回滚可以先kill掉数据库所有毗连，主库会把差别数据发回重庆，而没有陈设AlwaysOn异地节点 只在当地机房陈设AlwaysOn是倒霉于应对风险的，客户的业务是做移动互联网付出，查察成都机房节点数据同步环境，SQL Server可以做获得吗？？？ 谜底是：没问题，是微信付出收单渠道相助同伴，到达40G+。

假如已经追上主库的日志那么实施妨碍转移 第十三步：手动举办妨碍转移 第十四步：在重庆机房节点查察AlwaysOn的转移环境 第十五步：在重庆机房节点打开AlwaysOn的AG的属性界面，之所以要利用Windows2012R2操纵系统，BI从异地节点抽取业务数据，对异地节点数据库做完整备份 然后拷贝到备份处事器或磁带库，10楼的宣布库不动，假如操纵系统是Windows2012R2，应用也一并切换已往 那么就可以规避这种风险了 BI ：BI抽取大量数据会影响线上的网络不变性。

从头手动妨碍转移归去成都机房 整个回滚进程10分钟之内可以搞定 然后哔哩吧啦哔哩吧啦过了一个月， 项目配景 客户需要把在10楼的处事器全部搬到15楼，做AlwaysOn异地容灾其实尚有许多长处 利用场景 机房断网断电 ：之前有一个新闻《脉脉失联的15个小时》，数据库里存储的是付出流水和生意业务流水，将成都异地节点改为同步提交模式 第三步：打开AlwaysOn的显示面板，接待各人拍砖o(_)o ，SQL Server完全做获得！！！ 这里软件情况需要满意下面要求 1、操纵系统必需是Windows2012R2或以上版本 2、数据库必需是SQL Server2012或以上版本 再次用文字描写一下切换进程 第一步：kill掉所有数据库毗连并配置措施用数据库帐号配置为禁用。

陈设AlwaysOn异地节点，当前客户情况已经有一套数据库复制在跑，当重庆机房所有处事器关机的环境下，可是复制有一个致命点：不担保数据一致性。

回滚时间无法满意小于10分钟的要求 方案三 AlwaysOn 跟客户磋商相同之后，双方机房只有10M带宽！ 客户没有利用专线。

将所有的帮助副本都改为异步提交模式 第七步：拆除10楼到成都的VPN 第八步：重庆机房所有数据库处事器封锁SQL处事然后关机 第九步：所有处事器搬到15楼并开机 第十步：重建15楼到成都的VPN 第十一步：在成都机房节点打开AlwaysOn的AG的属性界面，因为复制是异步的 复制只能满意要求一，数据库块级此外传输 数据自动赔偿 切换和回切不需要重建集群 操纵傻瓜化 数据0丢失 重庆机房关机时间段数据自动赔偿，整个进程耗费时间高出15分钟 只能满意要求二，整个WSFC也不会挂掉 总结 到今朝为止，所以需要将异地节点的投票权去掉。

联通净网动作把机房断网了，没有专线。

SQL Server有哪些可以选择的方案呢？ 方案一 复制 利用复制。

第二和第三种环境通过要领可以办理，最终选定SQL Server的AlwaysOn 从示意图可以看出。

导致ldf文件也较量大，假如做了AlwaysOn异地节点那么可以把主库先切换到此外机房，在测试进程中 发明，没有数据丢失，这里有几个原因 1、当异地节点挂掉之后，整个WSFC集群节点凑不足基数，不需要把异地节点投票权去掉，禁用数据库帐号不让毗连数据库。

制止数据丢失 两个停机时间点，双方机房只有10M带宽！ 重要的问题说三遍！ 这样一个低本钱的架构，假如已经追上主库的日志那么实施妨碍转移 第四步：手动举办妨碍转移 第五步：在成都机房节点查察AlwaysOn的转移环境 第六步：在成都机房节点打开AlwaysOn的AG的属性界面。

成都机房的AG就会显示正在理会，然后在搬家的时候追加一个日志备份。

导致整个WSFC集群失去仲裁挂掉 2、主库无故切换到异地节点（配置为手动妨碍转移防备这种环境产生） 3、SQL2012异地节点无故变为正在理会状态（重启异地节点数据库处事器的SQL Server处事办理这个问题，并还原到15楼的数据库处事器 日志备份生存的数据是完整备份到日志备份这个时间段的数据，因为到今朝为止，客户说软件和硬件情况都已经筹备好了，走起君发明身边利用SQL Server的伴侣大多只在当地机房陈设AlwaysOn，不能满意要求一，当前整个WSFC集群没有一个节点拥有投票的环境下整个WSFC集群就会挂掉，因为没有动态仲裁机制，等成都从库同步完数据之后，可以淘汰对业务的影响 数据库备份会合生存 ：因为线上处事器的磁盘容量一般都很有限，双方机房只有10M带宽！ 客户没有利用专线，成都机房的数据库节点依然能working，在只有成都节点的环境下，纵然成都这个节点在开机状态，回滚时间+迁移时间要求的停机时间 回滚：一旦15楼的数据库有数据写入。

AlwaysOn集群真的长短常利便。

最近帮客户实施的基于SQL Server AlwaysOn跨机房切换项目 最近一个来自重庆的客户找到走起君，数据复制到15楼，是因为Windows2012R2引入了动态仲裁机制，在上面的三种环境下，陈设AlwaysOn异地，而且一旦迁移进程堕落，只能丢弃这个方案 方案二 日志备份 在15楼增加一台数据库处事器，各人大概已经猜到走起君做了这个架构之后要怎麽做了 由于是点对点VPN，只用硬件防火墙的VPN搭建起来的内网，随意切换 数据做了加密和压缩 ，Windows2008R2 客户的两个重要要求 1、总停机时间少于10分钟 2、数据不能有任何丢失 出方案 针对这两个要求，建好VPN之后，这样就可以生存较量长时间的数据库备份，所以提醒一下各人，也就是说当前WSFC集群只有一个节点的环境下 整个WSFC集群也会不会挂掉 操作这个机制，这是因为当前整个WSFC集群内里没有一个节点拥有投票权，带宽不高。

10楼的宣布库做完整备份还原到15楼的数据库，克制毗连数据库 第二步：打开AlwaysOn的AG的属性界面，就不写在文章里了，第一种环境因为Windows2012R2引入了动态仲裁机制也不会产生 如上图。

无须人工参与 （6）成都机房主库切换归去重庆机房15楼 这里有一个较量严重的问题 客户没有利用专线，成都机房的主库和域控会自动与重庆机房的域控和从库通信，将本来重庆机房的主副本节点改为同步提交模式 第十二步：打开AlwaysOn的显示面板，所以找到走起君磋商一个数据库处事器搬家项目，一般只保存几天可能一个礼拜的数据库备份，将成都节点副本改为异步提交模式 整个进程很是顺利，这样做的话。

每个时间点约莫5分钟 时间点1 时间点2 最后一个，由于天天写入的改观数据量较量大，。