Global Azure SQL Server Database异地复制配置介绍
发布于 2016-01-01 02:04:01 | 300 次阅读 | 评论: 0 | 来源: PHPERZ
这里有新鲜出炉的SQL Server教程，程序狗速度看过来！
SQL Server 数据库
SQL Server 即 Microsoft SQL Server 。
SQL是英文Structured Query Language的缩写，意思为结构化查询语言。SQL语言的主要功能就是同各种数据库建立联系，进行沟通。按照ANSI(美国国家标准协会)的规定，SQL被作为关系型数据库管理系统的标准语言。
Global Azure SQL Server Database异地复制配置介绍
近期写了很多关于Azure的相关文章，前几篇介绍了VPN的相关配置，今天就说说Azure上的SQL Server相关的配置信息；今天呢，我们主要介绍的是在Global Azure上配置数据库的异地复制功能，通过了解，在Azure上启用异地复制的工作原理很我们平常对SQL Server的异地复制备份是有差别的，在Azure 上配置完SQL 异地复制后，在异地是无法连接到服务器的，而且也是无法打开备份数据的，最为重要的一点是，在Azure上无法演练SQL异地复制的整个效果的，当然我们也不能质疑Azure平台上的功能；Azure 平台上的数据库异地复制原理为；当主备服务器拖放在美国西部的时候，然后辅助服务器会建议放在美国东部，这样配置完异地复制后，当美国西部的数据机房严重故障的是会，才会将数据切换到美国东部的辅助数据库服务器，最终辅助服务器才会提升为主服务器工作；
Azure上 SQL Server的异地复制提供两种异地复制方式：
1.标准异地备援：其中联机(不可读)
2.主动异地备援：联机(只读)
两者的区别在于：
Standard的数据库支持标准异地备援，Premium的数据库支持标准异地备援及主动异地备援，详见下表：
选择哪一种业务连续性与灾难恢复( Business Continuity/Disaster Recovery ，BCDR )解决方案的关键因素往往与应用程序效能有关，如果您的应用程序的数据更新率( rate of updates )较低，处理的数据量也较少时，Azure SQL Database所提供最基本异理还原( Geo-Restore )将是适合您的方案。若应用程序需要处理较大的数据量，并且对于 RPO 以及应用程序效能要求较高时，就需要使用标准异地备援 ( Standard Geo-Replication ) 来符合您的需求。至于最高阶的主动异地备援 ( Active Geo-Replication ) 则是针对需要最低 RPO 以及处理大量数据异动量之需求所提供的解决方案。
当您从Azure SQL Database Basic服务层升级到Premium服务层时，您能够选择的业务连续性与灾难恢复( BCDR )解决方案也就越多。 Azure SQL Database 高阶版本包含了所有入门版本服务层级的全部 BCDR 功能。
标准异地备援与主动异地备援的不同处
现在让我们进一步了解标准异地备援的用户验经验，以及它不同于主动异地备援之处。
首先，标准异地备援与主动异地备援是建立在相同的技术上，但是标准异地备援较适合数据密集写入( write-intensive )量较少的应用情境。一般而言以下几点考虑会让用户决定该采用标准异地备援 :
目标应用程序的数据更新速率( update rate )不需要用很高之灾难备援SLA。
应用程序只需要简单的恢复作业流程，而不需要太复杂的逻辑来做故障转移的决定。
这些应用程序通常有成本上的考虑( cost sensitive )。
标准异地备援( Standard Geo-Replication )相较于主动异地备援( Active Geo-Replication )简化如下:
在Microsoft定义的灾难备援配对数据中心( DR paired )中建立一个备援数据库( secondary database )。灾难备援配对数据中心的列表可以在此查阅。
可以在主要( master )数据库上可以看到备援的数据库，但是除非故障转移完成，否则是不能够直接联机使用备援的数据库。
由于备援的数据库平时是不能够直接读取的，也因此收费较便宜。
当Azure数据中心长时间停摆时才会启用故障转移动作，每当Azure入口网站会显示Azure SQL Database服务为"degraded"时，很可能需要花费长达一个小时的时间才会恢复正常，。
在Azure数据中心长时间停摆的状况下，如果微软认为复原时间会超过24小时，或是Azure SQL Database发生问题而用户超过24小时没有主动启动故障转移程序，微软会将所有使用标准异地备援的用户数据库自动切换到备援的数据中心。
那我们怎么选择呢，具体我们使用以下方案进行确认
为什么要使用标准异地备援，而不是使用 Azure SQL Database Premium 的主动异地备援?
既然Azure SQL Database Premium版能够同时支持标准异地备援和主动异地备援。那在甚么情况下您要选择的是标准异地备援，而不是更为强大的主动异地备援呢 ?
标准异地备援被设计为一个较为简单且便宜的灾害还原解决方案( DR solution )，特别适合用来处理数据更新率较低的应用程序。如果 Azure SQL Database Premium 版数据库是被用来处理大批读取导向 ( read-oriented ) 的工作负载时，就相当适合使用标准异地备援。
当使用标准异地备援时，您无法选择备援数据库的数据中心位置，也不会如同主动异地备援般拥有四个具备读取权限的备援数据库，也无法完全控制在何时何地进行故障转移。但是相对的，使用标准异地备援让您得到一个由 Microsoft 控制，较为简单的监测方式以及故障转移流程。对于 Azure SQL Database Premium 用户而言，标准异地备援和主动异地备援是可以交互搭配使用的，例如您可以使用 Azure SQL Database Premium 版数据库去建立一个脱机的标准异地备援数据库，同时您仍可以利用主动异地备援功能，建立多个可读取的备援数据库用于读取负载平衡，以应付高密集读取的应用情境。
数据库故障转移 ( failover )
标准异地备援是专门为数据库提供从灾害停机中恢复的解决方案。除非有一个 Azure SQL Database 在主要的托管区域停止运作，否则您将无法启动故障转移到配对数据中心内的备援 ( secondary ) 数据库。也就是说若您使用标准异地备援，倘若发生用户应用层级的数据库停止运作，用户是无法自行手动进行的故障转移，若有这类需求，用户应该选择使用主动异地备援。
若有一个Azure数据中心发生长时间停机的状况时，微软会针对使用Azure SQL Database标准异地备援的数据库进行容错转移。这项措施的目标，就是要在 Azure SQL Database 停机发生后的一小时之内启动故障转移，一旦启动这项措施，用户您开始进行容错转移动作，将数据库移转至备援数据中心的数据库，并停止主数据库与备援数据库之间的数据复制动作。
这种方法使得故障转移变得相当简单，应用程序只需要判断是否启用故障转移的旗标( flag )，再来决定要进行故障转移还是等待目前数据库复原。这两种选择会依据应用程序需求而有所不同。若您的应用程序比较注重不停机的高可用性 ( higher availability ) 并能容忍漏失过去一个小时已经储存于主数据库内的数据，当为微软启用允许容错转移后，用户应尽速启用故障转移。倘若您的应用程序比较注重数据的完整性，已经储的数据遗失是非常敏感 ( sensitive ) 的，虽然微软已经允许标准异地备援用户开始进行容错转移，用户能可能愿意继续等待 Azure SQL Database 恢复正常，以避免数据库内的数据漏失。然而，若是主数据库所在之 Azure 数据中心若是在发生停机后 24 小时之内都没法复原，则标准异地备援的数据库都会自动执行故障转移动作。在这种最坏状况下，应用程序将会有 24 小时的停机时间并且会有部分数据遗失。无论是用户自己启动故障转移或是等待 24 小时让它自行发生，用户都需重新配置与设定您的应用程序的数据库联机，连接到容错转移后的备援数据库。
完成容错转移之后，您也会想要确定新的主要数据中心( Primary region )是否也受到相同的保护，因此在进行故障转移的过程中，Azure会更新它的灾难恢复配对数据中心( DR pair )，这将允许您从新的主要数据中心( Primary region )来启动新的地理数据复制来保护它自己。由于建立新的备援区域需要花费一些时间 ( 取决于数据库数据量大小 )，您必须承担在建立新的备援区域的这段期间，Azure SQL Database 暂时无高可用性备援能力，并且接受在没有保护状态下执行应用程序的风险。最妥当的办法就是等待故障转移数据库已经有完整备援数据中心保护之后，再启动应用程序。
建立完备原数据中心后，新的灾害复原( DR )的配置如下图所示 :
具体见下：
我们首先在美国西部创建一个SQL数据库---Student
我们设置数据库名词---Student，然后设置新建服务器，然后设置服务器位置为美国西部
设置排序----
Chinese_PRC_CI_AS
开始创建数据库
数据库创建完成
接下来我们使用SQL Server ManageStudio 连接该数据库
连接前，我们需要保证连接的服务器地址在SQL Server防火墙中；
连接成功后，我们首先创建一张表；然后定义一些字段，然后插入一些数据
create table info(
id int primary key IDENTITY(1,1) not null,
Name varchar(50),
Sex varchar(50),
Age varchar(500)
)
go
然后我们插入一些数据
--insert into dbo.info (name,sex,age) values ('张三','男','18')
--insert into dbo.info (name,sex,age) values ('李四','男','19')
--insert into dbo.info (name,sex,age) values ('王五','男','17')
--insert into dbo.info (name,sex,age) values ('小丽','女','18')
--insert into dbo.info (name,sex,age) values ('小芳','女','20')
然后我们查询数据
接下来我们配置异地复制；我们先打开美国西部的数据库
单击异地复制
我们单击进入异地辅助-系统推荐选择美国东部；
我们单击进入美国东部服务器；系统会默认选择数据库；
我们单击服务器名称--选择美国东部的SQL数据库；
系统建议而且必须创建一个新的服务器；所以我们创建一个新的服务器
开始创建
开始创建及创建完成
注：我们前面说了，创建辅助数据库后，是无法对辅助数据库的数据进行查看。只能当时灾难出现了才可以自动切换。