不可抗力因素导致数据灾难？其实可以抵抗！
（本文阅读时间：5分钟）
近年来，企业级用户遭遇数据被破坏或丢失的事件时有发生，而这些事件将引起业务受阻、影响用户体验及企业声誉等情况，甚至导致数据无法找回、业务再无恢复，造成的影响不可逆转。试想，如果花费几十年的时间来恢复由于灾难发生所损伤的“元气”，这是否足以拖垮一个正在飞速发展的企业呢？数据时代，对于企业来说，数据即创造价值的基本条件之一。因此，一个值得信赖的云服务厂商对所有企业的发展都至关重要，构建可靠的异地容灾及故障转移，才能够更加从容地面对不可预计的灾难的发生。
作为微软助力客户数据库迁移上云的重要举措，Azure SQL Database 托管实例服务正式登陆由世纪互联运营的 Microsoft Azure。以全托管的形式在云端提供了 SQL Server 的几乎全部功能，能为企业提供将本地部署的 SQL Server 数据库以更低成本迁移上 Azure 云的捷径，并且可以提供几乎100% 的应用兼容性。
于此同时，许多客户提出生产数据库上云后如何构建异地容灾？这的确是企业级客户的真实需求，作为全球一流的云供应商，微软在数据库层面也提供的相应的手段来保证系统高可用性。故障转移组是一项 SQL 数据库功能，可用于管理复制和故障转移的一组 SQL 数据库服务器上的数据库或托管实例与另一个区域中的所有数据库。它使用的底层技术与相同活动异地复制相同。可以手动启动故障转移，也可以基于用户定义的策略委托 SQL 数据库服务进行故障转移。
下面我们就来介绍如何在世纪互联的Azure云上构建SQL托管实例异地容灾。首先确保满足这些先决条件：
1. 两个托管的实例必须能够在不同 Azure 区域。
2. 辅助节点必须是空的（无用户数据库）。
3. 主要和次要托管的实例必须位于同一资源组。
4. 托管的实例属于需要通过连接的 Vnet VPN 网关。不支持全局 VNet 对等互连。
5. 两个托管的实例 Vnet 不能有重叠的 IP 地址。
6. 您需要设置网络安全组 (NSG) ，端口 5022 和范围 11000 ~ 12000 是打开入站和出站连接从其他托管实例子网。目的是允许实例之间的复制流量
7. 辅助实例配置有正确的 DNS 区域 id。
在Azure 建立Primary SQL 托管实例
定义实例名为mikesqlmi1,区域为China North 2.
在China East 2上，准备好虚拟网络，并创建Secondary 托管实例mikesqlmi2
在两个托管实例的VNET里面，分别创建gateway 子网
在VNET1上创建VPN网关
类似创建vnet2-gw，并创建两个单向连接（North2->East2; East 2->North2 ），确保两路连接状态正常
创建Primary实例上数据库testdb
点击mikesqlmi1上的Instance Failover Groups(preview),并Add group
这里我们成功建立了北京至上海的故障转移组(failover group)
然后我们测试一下切换功能，来验证故障转移实例是否正常工作。
Portal 上显示切换成功
使用SSMS登入到新的Primary 实例mikesqlmi2,并检查。
我们发现mikesqlmi1上的testdb,已成功复制到mikesqlmi2上
添加应用子网app-subnet,并在此子网里建一台虚机
记录read/write 监听器的终结点
在这台虚机上，使用SSMS访问read/write listener ,并验证目前的primary是mikesqlmi2。
再次切换，read/write listener endpoint DNS无需变化, 依然会指向新的的primary
实验结束，删除故障转移实例组。
至此，我们已经完成了SQL DB 托管实例异地容灾的搭建。从容地应对灾难性数据的损失，本身并不是件易事，完成以上步骤后，还需要不断保持警惕状态，建议大家在生产数据库上线前做好容灾构建和切换测试，最大程度保证系统的可靠性。在世纪互联的Azure云时刻为您保驾护航