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数据库;

系统建议而且必须创建一个新的服务器;所以我们创建一个新的服务器

开始创建

开始创建及创建完成

https://azure.microsoft.com/zh-cn/documentation/articles/sql-database-business-continuity-design/?cdn=disable

注:我们前面说了,创建辅助数据库后,是无法对辅助数据库的数据进行查看。只能当时灾难出现了才可以自动切换。

时间: 2024-10-21 00:28:41

Global Azure SQL Server Database异地复制配置介绍的相关文章

Global Azure SQL Server Database 导出和导入配置介绍

我们前一篇文章介绍了Global Azure SQL Server Database的备份和还原配置介绍,今天我们就说说Global Azure SQL Server Database的导出和导入功能介绍,其实说到导出和导入,我们大家都会想到,其实就是将数据导出成一种格式,然后在另外一个环境中导入即可,该功能有点类似备份和还原的功能,也可以理解为迁移的功能,但是按照官网的字段定义就是导出和导入,在Global Azure SQL Server Database的导出原理就是将数据库整个架构导出到

Global Azure SQL Server副本功能配置介绍

我们前面几篇文章介绍了Global Azure SQL Server Database的Backup.Recovery.Export.Import等相关功能 ,今天我们介绍一下Global Azure SQL Server Database的副本功能,其实说到副本两个字,言外之意就是备份,在Global Azure SQL Server Database的副本配置其实就跟Backup及Export.Import的工作原理一样,副本就是将正在运行的Global Azure SQL Server D

通过SSMS工具迁移本地的SQL Server Database到Windows Azure SQL Database

微软的产品更新越来越快了,几乎每年都有产品更新,今天呢,我们主要介绍一下,如何将本地的SQL Server数据库迁移到windows azure上的SQL Server Database.当然说到SQL Serrver数据库的迁移,大家都会想到最普通及最普遍的方法,那就是通过备份数据库,然后通过备份的数据库文件进行还原.其实呢,我们在IT运维的工作中多少会有体会,最普通的方法往往是最有效的方法也是最安全的方法,但是效率不高,由于时代进步的太快了,我们也不能太out了,也不想用这个古老的方法去做数

通过SQL Server 2008数据库复制实现数据库同步备份

SQL Server 2008数据库复制是通过发布/订阅的机制进行多台服务器之间的数据同步,我们把它用于数据库的同步备份.这里的同步备份指的是备份服务器与主服务器进行 实时数据同步,正常情况下只使用主数据库服务器,备份服务器只在主服务器出现故障时投入使用.它是一种优于文件备份的数据库备份解决方案. 在选择数据库同步备份解决方案时,我们评估了两种方式:SQL Server 2008的数据库镜像和SQL Server 2008数据库复制.数据库镜像的优点是系统能自动发现主服务器故障,并且自动切换至镜

Windows 2008群集与SQL Server 2008群集安装配置

一.摘要: 本文主要讲述如何在windows server 2008 R2 系统上安装 SQL server 2008 的集群配置. 二.准备: 最少事先需准备三台服务器(理由看这里https://support.microsoft.com/zh-cn/kb/2795523),我此次的实验是在台式机电脑上面安装的,系统安装这里不讲.如果没有主机设备的,此实验可在vmware虚拟机上面安装实现.基本上大同小异,虚拟机这块我在这就不讲了. 因为手上没有存储服务器,所有只能用微软的iscsiTarge

P6 Professional Installation and Configuration Guide (Microsoft SQL Server Database) 16 R1

P6 Professional Installation and Configuration Guide (Microsoft SQL Server Database) 16 R1       May 2016 Contents About This Guide...................................................................................... 11 Shared Topics in This Guide .

SQL Server 2012 数据库镜像配置完整篇

"数据库镜像"是一种提高 SQL Server 数据库的可用性的解决方案. 镜像基于每个数据库实现,并且只适用于使用完整恢复模式的数据库.数据库镜像维护一个数据库的两个副本,这两个副本必须驻留在不同的 SQL Server 数据库引擎 服务器实例上. 通常,这些服务器实例驻留在不同位置的计算机上. 启动数据库上的数据库镜像操作时,在这些服务器实例之间形成一种关系,称为"数据库镜像会话".其中一个服务器实例使数据库服务于客户端("主体服务器"), 

目录:SQL Server 2014 安装与配置指南

<SQL Server 2014 安装与配置指南> 章节目录 第1章 SQL Server 2014 概况 http://mssqlmct.blog.51cto.com/9951484/1616457 第2章  规划SQL Server 安装 第3章  创建新的 SQL Server实例 第4章 修改SQL Server安装 第5章 升级到SQL Server 2014 第6章  配置 SQL Server 服务实例 第7章  使用SQL Server Management Studio 第8

oracle 、sql server 、mysql 复制表数据

我们知道在oracle 中复制表数据的方式是使用 create table table_name as select * from table_name 而在sql server  中是不能这么使用的 语句如下: select * into table_name from table_name; 而在 mysql 中有两种方式 1. create table a like b 2. 类似oracle的方式 create table table_name as select * from tabl