对于数据库的维护来说，备份工作可谓是重中之重。MS Azure 当然也提供了很完善的数据库备份功能。但是在动手创建备份计划前请思考一下备份工作的真实目的。当然首先要保证数据的安全，一般来说定时创建数据库的备份文件，再拷贝到不同的存储设备上就可以了。其次，当灾难发生时可不可以用最短的时间还原数据库从而恢复应用？再次，能不能让备份的数据库也创造一些价值…
让我们带着这些问题一起来了解下 Azure 提供的一种可以跨越数据中心的数据库备份方式：Active Geo-Replication。
Active Geo-Replication 是什么？
这里的 Active 我们可以理解为"正在运行的"，Geo 表示的是"geographic"也就是"地理的"，Replication 是"复制"的意思。合起来的大意就是"在不同的地理位置上运行的副本"。
Active Geo-Replication 允许我们最多配置4个只读的从数据库，再加上一个主数据库，此时你就会拥有五个数据库的实例，并且它们都是可访问的。注意，这五个数据库可以设置在不同的数据中心，也就是说当其中的四个数据中心完全挂掉的时候，你的数据库依然是安全的，并且可以立即使用，因为它是正在运行的数据库。主数据库可读写，并且以异步的方式把变更同步到其余的从数据库。我们可以轻松的把主数据库和从数据库配置到不同的数据中心，因而当灾难降临的时候，我们可以用最少的时间恢复程序的执行并且做到不丢失数据。
这是如何做到的呢？当主数据库由于任何原因不可用时，我们可以把任何一个从数据库切换为主数据库，切换完成后，各个数据库会立即适应自己的新角色，即主数据库异步的向从数据库同步数据。需要注意的是，Azure 并不会智能的帮我们做切换工作，这个活儿需要小伙伴们自己手动执行，或者是写程序执行。
Active Geo-Replication 实现了一个可以在不同的区域间进行数据库冗余备份的架构 (Azure上的数据库) 。它通过异步复制已提交的事务来保证主从服务器的同步。因此从数据库中的数据会稍微比主数据库滞后一点点(笔者在主数据库中插入一条数据，在下一行中执行从数据库中的查询就能查到这条数据)。
Active Geo-Replication 的设置非常简单，可以通过图形化的操作完成。下面的截图是设置了一个从数据库的 demo:
这一点真的不是MS吹牛，好用到你想在哪个数据中心创建备份直接点地图上的圈圈就行了！但让人不爽的还是操作的时间问题，笔者尝试把8G的数据库向不同的数据中心做备份，短的几分钟就好了，长的需要数小时！
使用 Active Geo-Replication 的优势
提供数据库级别的灾难恢复
当我们把从数据库部署到 Azure 上的不同的数据中心时，就为应用程序提供了最强的的灾难恢复能力。跨数据中心的冗余数据库备份让我们能够很容易的，并且很快的从灾难中恢复数据，这些灾难可能是人力不可抗拒的自然灾害，也有可能是一些人为的恶意攻击。
只读的从数据库可以分担主数据库的部分负载
像生成报表等一些只读的操作完全可以通过访问从数据库来完成，从而降低主数据库的负载。对于笔者来说，这是使用 Active Geo-Replication 的重要目的。因为笔者是在维护一个旧的系统，不是必须要做的事情，笔者是不愿意去优化那些已经跑了很多年的、慢吞吞的、很复杂的报表查询操作的。现在好了，只需要把这些查询定向到备份用的从数据库就可以了，结果就是所有操作的性能都会有所提升。
更进一步，还可以把从数据库与主数据库设置在同一区域中然后实现对读操作的负载平衡，详情请参考 MSDN。当然这并不会增加应用程序的容灾能力。
数据库迁移
通过使用 Active Geo-Replication 我们可以用最短的时间完成数据库的迁移工作。其实就是创建一个从数据库的过程。
应用程序升级
我们可以创建一个从数据库作为应用程序升级失败后回退用的备份。这里可能会让人迷惑，因为主从数据库是有同步关系的，在升级主数据库的过程中从数据库肯定会被同步，它又如何能够作为备份呢？真相是这样的，在从数据库创建后可以让它断开与主数据库的主从关系，断开后就不会再被同步，所以可以起到备份的作用。
Active Geo-Replication的主要功能
前面我们介绍了 Active Geo-Replication 相比传统备份手段的一些优势，接下来我们一起看看它都有哪些主要功能。
自动进行的异步复制
我们只能为已经存在的数据库添加从数据库。并且只能把从数据库添加到和主数据库不同的 Azure SQL Database server 中。被创建的从数据库会使用主数据库中的数据进行填充，这个过程称为播种(seeding)。播种完成后，主数据库中的更新就会以异步复制的方式自动同步到从数据库中。
支持最多四个从数据库
两个或两个以上的从数据库可以显著的增强主数据库的容灾能力。当有多个从数据库存在时，即便其中的一个从数据库发生了故障，也不影响主数据库的抗灾能力。注意，当你搞多个从数据库作为备份时也是有成本的，需要根据具体需求确定从数据库的个数。
从数据库是只读的
应用程序可以把一些只读的操作放在从数据库上。并且可以使用不同的用户权限去操作从数据库。此处我们可能会关心一下主从数据库同步的性能，当我们在从数据库上执行操作时，会不会影响主数据库到从数据库的同步。照MS的说法是不会的，对从数据库的读操作使用了一种称为快照隔离模式(snapshot isolation mode)的高大上方法，能够在读操作的同时，不影响主数据库到从数据库的同步。
可以使用elastic database pool
Active Geo-Replication 可以像普通数据库一样被配置到 elastic database pool 中。
从数据库可以设置为与主数据库不同的配置
对于作为备份存在的从数据库而言，如果保持资源类型和主数据库一致是相当奢侈的。好在MS也为我们提前想好了。把从数据库的资源类型设置的低一点可以为我们节省不少的预算。但这样也可能会带来一点问题，就是主从数据库的同步延迟会增加。具体情况取决于你的应用。
用户可控的灾难恢复
一个从数据库可以在任何时刻被切换成主数据库。同时，原来的主数据库会成为从数据库。
当灾难发生在主数据库上时，我们可以把一个从数据库切换成主数据库，程序只需要重新配置数据库的链接信息即可。再次强调，这个操作需要用户来做或者用户写程序来完成。
同步防火墙和认证信息
传统 sql server 的登录用户都是在 database server 级别设置的，这在数据库同步的应用场景中可能会带来一些不便。比如从数据库所在的 database server 上是否设置了相同的用户登录信息，如果没有，当主从数据库切换后，应用程序访问数据库时就可能碰到登录问题。
为了解决这一问题，新的 sql server 支持数据库级别的用户访问控制。用户不需要有登录 sql server 的权限，只要能够访问某个数据库就可以了，并且用户的信息是保存在数据库的配置文件中的，可以随数据库一起复制。
同理，防火墙的规则也可以设置在数据库上。
使用PowerShell进行管理
可以使用 Azure Resource Manager (ARM) APIs 通过 PowerShell 管理 Active Geo-Replication。
总结
Active Geo-Replication 在提供数据库备份的同时也增加了很多附加的价值，为我们的应用程序和维护带来了更多的灵活性。如果使用得当可以通过很少的成本增加来创造大量的价值。
来源：https://www.cnblogs.com/sparkdev/p/6875376.html