SQL Server AlwaysOn架构及原理

SQL Server AlwaysOn架构及原理

   SQL Server2012所支持的AlwaysOn技术集中了故障转移群集、数据库镜像和日志传送三者的优点，但又不相同。故障转移群集的单位是SQL实例，数据库镜像和日志传送的单位是单个用户数据库，而AlwaysOn支持的单位是可用性组，每个组中可以包括一个或者是多个用户数据库。也就是说，一旦发生切换，则可用性组中的所有数据组会作为一个整体进行切换。

   AlwaysOn底层依然采用Windows 故障转移群集的机制进行监测和转移，因此也需要先建立Windows Cluster，只不过可用性组中的数据库不一定非要再存放在共享存储上了。可以是存储在本地磁盘上。

   下面，先看一下AlwaysOn的关键特性：

   1. 同故障转移群集一样，也需要一个虚拟网络名称用于客户端的统一连接。

   2.一个主服务器可以最多对应四个辅助服务器，总数达到五个，而且辅助服务器支持只读功能。

   3.辅助服务器可以独立执行备份和DBCC维护命令。通过配置，可以实现客户端的只读请求可以被自动定向到辅助服务器。

   4.主服务器和辅助服务器之间的数据会被加密和压缩，以提高安全性和网络传输效率。

   5..支持自动、手动和强制三种故障转移方式。

   6.有仪表盘用于监控AlwaysOn的运行状态。

   7.可以实现多站点的部署，即主站点和辅助站点可以跨物理网络。

AlwaysOn的基本架构

   在Windows MSCS故障转移群集的基础上部署AlwaysOn高可用组，用户可以在群集节点上安装SQL Server单机实例，也可以安装SQL Server群集实例，AlwaysOn仅要求所有SQL Server实例都运行在同一个MSCS中，但SQL Server实例本身是不需要群集模式的，这与SQL Server2008 群集的实例完全不同。在此推荐使用单机模式的SQL Server，好处是：可用性副本是个单机实例，那么数据库副本就存放在该运行该实例节点的本地磁盘上；如果可用性副本是个群集实例，那么数据库副本就存放在共享磁盘上。

   可用性组从Windows群集角度来看，就是一个群集资源，其中的所有数据库作为一个整体在节点间进行故障转移，当然这不包括系统数据库，系统数据库是不能加入高可用性组中的。

   因为需要借助Windos群集实现监控和转移，所以AlwaysOn会受到一些限制：

   一个可用性组中的所有可用性副本必须运行在单一的Windows群集上，跨不同Windows群集的SQL Server实例不能配置成一个AlwaysOn可用性组。

   一个可用性组的所有可用性副本必须运行在Windows群集的不同节点上。运行在同一个节点上的两个不同实例不能用作同一个可用性组的副本。

   如果某个可用性副本实例是一个SQL群集实例，那同一个SQL群集的其他非活跃节点上安装的任何其他SQL实例都不能作为它的辅助副本。

   一个数据库只能属于一个可用性组。

   AlwaysOn最多可以支持五个副本，但只有一个可用性副本上运行的数据库是处于可读写状态。这个可读写的数据库被称为主数据库（PrimaryDatabase），同时这个可用性副本被称为主副本（primaryreplica）。其余的副本都被称为辅助副本（secondaryreplica），辅助副本上的数据库可能是不可访问的，或者是只能接受只读操作（取决于可用性组的配置），这些数据库被称为辅助数据库。一但发生故障转移，任何一个辅助副本都可以成为新的主副本实例。主副本会不断地将主数据库上的数据变化发送到辅助副本，来实现副本间的数据库同步。下图就显示了一个可用性组中各副本之间的关系。

   下面，咱们再通过一个图看 一下AlwaysOn可用性组与Windows故障转移群集之间的关系，在这个图中，Windows的故障转移群集使用到了两个子网，在左边的子网里，有两个节点 ；右边的子网里有三个节点，其中最右边两个节点上创建了一个SQL Server的群集实例，存放于共享存储；其他三个节点安装的是单机实例，存放于本地存储；一共四个实例组成了一个AlwaysOn可用性组，其中一个主副本，其他的都是辅助副本。

侦听器

   AlwaysOn创建后，客户端就需要进行连接，为了让应用程序能够透明地连接到主副本而不受故障故障转移的影响，我们需要创建一个侦听器，侦听器就是一个虚拟的网络名称，可以通过这个虚拟网络名称访问可用性组，而不用关心连接的是哪一个节点，它会自动将请求转发到主节点，当主节点发生故障后，辅助节点会变为主节点，侦听器也会自动去侦听主节点。

一个侦听器包括虚拟IP地址、虚拟网络名称、端口号三个元素，一旦创建成功，虚拟网络名称会注册到DNS中，同时为可用性组资源添加IP地址资源和网络名称资源。用户就可以使用此名称来连接到可用性组中。与故障转移群集不同，除了使用虚拟网络名称之外，主副本的真实实例名还可以被用来连接。

   SQL Server2012早期版本的SQL Server只有在实例启动的时候地会尝试绑定IP和端口，但是SQL Server2012却允许在副本实例处于运行状况的时候随时绑定新的IP地址、网络名称和端口号。因此可以为随时为为可用性组添加侦听器，而且这个操作会立即生效。当添加了侦听器之后，在SQL Server的错误日志中可以看到类似：在虚拟网络名称上停止和启动侦听器的消息。

   要注意的是，SQLBrowser服务是不支持Listener的。这是因为应用程序在使用Listener的虚拟网络名连接SQLServer时，是以一个默认实例的形式进行访问的（只有主机名，没有实例名），因此客户端根本就不会去尝试使用SQLBrowser服务。

各副本间的数据同步

   AlwaysOn必须要维护各副本间的数据一致性，当主副本上的数据发生变化，会同步到辅助副本上。这里AlwaysOn通过三个步骤来完成：

步骤1：主副本记录发生变化的数据；

步骤2：将记录传输到各个辅助副本；

步骤3:把数据变化操作在辅助副本上执行一遍。

具体实现如下：

   在主副本和辅助副本上，SQL Server都会启动相应的线程来完成相应的任务。对于一般的SQL Server服务器，即没有配置高可用性，会运行Log Writer的线程，当发生数据修改事务时，此线程负责将本次操对应的日志信息记录到日志缓冲区中，然后再写入到物理日志文件。但如果配置了AlwaysOny主副本的数据库，SQL Server会为它建立一个叫Log Scanner的线程，不间断的工作，负责将日志从日志缓冲区或日志文件里读出，打包成日志块，发送到辅助副本。因此可以保证发生的数据变化，不断送给各辅助副本。

  辅助副本上存在固化和重做两个线程完成数据更新操作，固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本磁盘上的日志文件里，因此称为固化，然后重做线程负责从磁盘上读取日志块，将日志记录对应的操作重演一遍，此时主副本和辅助副本上的数据就一致了。重做线程每隔固定的时间点，会跟主副本通信，告知自己的工作进度。主副本由此知道两边数据的差距。Log Scanner负责传送日志块，不需要等待Log Writer完成日志固化；辅助副本完成日志固化以后就会发送消息到主副本，告知数据传输完成，而不需要等待重做完成，这样各自独立的设计，是尽可能减少 AlwaysOn所带来的操作对数据库性能的影响。

本文出自 “杜飞” 博客，保留此出处http://dufei.blog.51cto.com/382644/1384210

SQL Server AlwaysOn架构及原理

标签：

小编还为您整理了以下内容，可能对您也有帮助：

sql server 中创建架构，架构是干什么用的，为什么要创建架构，有什么好处？

SQL Server 中的 架构 ( schema )

与 软件构架 与 架构师 的不是同一个概念

schema 是用于 在一个 大项目中的 各个 小项目

每个 小项目的表, 放在 各自的 schema 下面.

这样, 遇到 小项目里面. 有 相同名字的 表的话, 不会发生冲突.

例如一个 公司的 系统.

里面分2个 子系统, 分别为 财务系统 和 人力资源系统.

这2个 子系统, 共用一个数据库

.

那么 财务系统的表, 可以放在 财务的 schema.

人力资源系统的表，放在 人力资源系统的模式里面。

这2个 子系统， 能够 互相访问 对方的表

但是又不因为 表重名 的问题，影响对方。

体系结构是下面这个样子的

[服务器名称].[数据库名称].[构架名称].[表名]

create database --> 创建一个数据库

create schema --> 创建一个构架

当你在 SQL Server 里面， 使用 create database 创建一个数据库以后。

你可以不必额外的去创建 schema

因为 SQL Server 会 自动的创建一个 名字叫 dbo 的 schema

sql数据库原理

1)SQL模式：SQL模式是表和授权的静态定义。 一个SQL模式定义为基本表的集合。 一个由模式名和模式拥有者的用户名或账号来确定, 并包含模式中每一个元素(基本表、视图、索引等)的定义。 (2)SQL数据库：SQL(Structured Query Language)，即‘结构式查询语言’， 采用英语单词表示和结构式的语法规则。 一个SQL数据库是表的汇集，它用一个或多个SQL模式定义。 (3)基本表：在SQL中， 把传统的关系模型中的关系模式称为基本表(Base Table)。 基本表是实际存储在数据库中的表，对应一个关系。 (4)存储文件：在SQL中， 把传统的关系模型中的存储模式称为存储文件(Stored File)。 每个存储文件与外部存储器上一个物理文件对应。 (5)视图：在SQL中，把传统的关系模型中的子模式称为视图( View)，视图是从若干基本表和（或）其他视图构造出来的表。 (6)行：在SQL中，把传统的关系模型中的元组称为行( row)。 (7)列：在SQL中，把传统的关系模型中的属性称为列( coloumn)。 (8)实表：基本表被称为“实表”， 它是实际存放在数据库中的表。 (9)虚表：视图被称为“虚表”，创建一个视图时， 只把视图的定义存储在数据词典中，而不存储视图所对应的数据。 (10)相关子查询：在嵌套查询中出现的符合以下特征的子查询： 子查询中查询条件依赖于外层查询中的某个值， 所以子查询的处理不只一次，要反复求值，以供外层查询使用。 (11)联接查询：查询时先对表进行笛卡尔积操作， 然后再做等值联接、选择、投影等操作。 联接查询的效率比嵌套查询低。 (12)交互式SQL： 在终端交互方式下使用的SQL语言称为交互式SQL。 (13)嵌入式SQL： 嵌入在高级语言的程序中使用的SQL语言称为嵌入式SQL。 (14)共享变量：SQL和宿主语言的接口。 共享变量有宿主语言程序定义， 再用SQL的DECLARE语句说明， SQL语句就可引用这些变量传递数据库信息。 (15)游标：游标是与某一查询结果相联系的符号名， 用于把集合操作转换成单记录处理方式。 (16)卷游标：为了克服游标在推进时不能返回的不便， SQL2提供了卷游标技术。 卷游标在推进时不但能沿查询结果中元组顺序从头到尾一行行推进， 也能一行行返回。

sql数据库原理

1)SQL模式：SQL模式是表和授权的静态定义。 一个SQL模式定义为基本表的集合。 一个由模式名和模式拥有者的用户名或账号来确定, 并包含模式中每一个元素(基本表、视图、索引等)的定义。 (2)SQL数据库：SQL(Structured Query Language)，即‘结构式查询语言’， 采用英语单词表示和结构式的语法规则。 一个SQL数据库是表的汇集，它用一个或多个SQL模式定义。 (3)基本表：在SQL中， 把传统的关系模型中的关系模式称为基本表(Base Table)。 基本表是实际存储在数据库中的表，对应一个关系。 (4)存储文件：在SQL中， 把传统的关系模型中的存储模式称为存储文件(Stored File)。 每个存储文件与外部存储器上一个物理文件对应。 (5)视图：在SQL中，把传统的关系模型中的子模式称为视图( View)，视图是从若干基本表和（或）其他视图构造出来的表。 (6)行：在SQL中，把传统的关系模型中的元组称为行( row)。 (7)列：在SQL中，把传统的关系模型中的属性称为列( coloumn)。 (8)实表：基本表被称为“实表”， 它是实际存放在数据库中的表。 (9)虚表：视图被称为“虚表”，创建一个视图时， 只把视图的定义存储在数据词典中，而不存储视图所对应的数据。 (10)相关子查询：在嵌套查询中出现的符合以下特征的子查询： 子查询中查询条件依赖于外层查询中的某个值， 所以子查询的处理不只一次，要反复求值，以供外层查询使用。 (11)联接查询：查询时先对表进行笛卡尔积操作， 然后再做等值联接、选择、投影等操作。 联接查询的效率比嵌套查询低。 (12)交互式SQL： 在终端交互方式下使用的SQL语言称为交互式SQL。 (13)嵌入式SQL： 嵌入在高级语言的程序中使用的SQL语言称为嵌入式SQL。 (14)共享变量：SQL和宿主语言的接口。 共享变量有宿主语言程序定义， 再用SQL的DECLARE语句说明， SQL语句就可引用这些变量传递数据库信息。 (15)游标：游标是与某一查询结果相联系的符号名， 用于把集合操作转换成单记录处理方式。 (16)卷游标：为了克服游标在推进时不能返回的不便， SQL2提供了卷游标技术。 卷游标在推进时不但能沿查询结果中元组顺序从头到尾一行行推进， 也能一行行返回。

sql server连接原理？

1． 何时创建连接池？

当第一个连接请求到来时创建连接池；连接池的建立由数据库连接的连接字符创来决定。每一个连接池都与一个不同的连接字符串相关。当一个新的连接请求到来时如果连接字符串和连接池使用的字符串相同，就从连接池取出一个连接；如果不相同，就新建一个连接池。

2． 何时关闭连接池？

当连接池中的所有连接都已经关闭时关闭连接池。

3． 当连接池中的连接都已经用完，而有新的连接请求到来时会发生什么？

当连接池已经达到它的最大连接数目时，有新的连接请求到来时，新的连接请求将放置到连接队列中。当有连接释放给连接池时，连接池将新释放的连接分配给在队列中排队的连接请求。你可以调用close和dispose将连接归还给连接池。

4． 我应该如何允许连接池？

对于应用程序而言，默认为允许连接池。（这意味着你可以不必为这件事情做任何的事情）当然，如果你可以在SQLConnection对象的连接字符串中加进Pooling=true;确保你的应用程序允许连接池的使用。

SQL Server 2012 标准版是否能搭建alwayson

SQLServer 2012 Always on是针对高可用性和灾难恢复的新解决方案。可以配置一个或多个辅助副本以支持对辅助数据库进行只读访问，并且可以将任何辅助副本配置为允许对辅助数据库进行备份。 这样就提供了硬件的使用效率。

“可用性组”针对一组离散的用户数据库（称为“可用性数据库”，它们共同实现故障转移）支持故障转移环境。一个可用性组支持一组主数据库以及一至四组对应的辅助数据库。可用性组在可用性副本级别进行故障转移。故障转移不是由诸如因数据文件丢失或事务日志损坏而使数据库成为可疑数据库等数据库问题导致的。

每组可用性数据库都由一个“可用性副本”承载。有两种类型的可用性副本：一个“主副本”和一到四个“辅助副本”。前者用于承载主数据库，后者则承载一组辅助数据库并作为可用性组的潜在故障转移目标。主副本使主数据库可用于客户端的读写连接。此外，它在称为“数据同步”的过程中使用，在数据库级别进行同步。主副本将每个主数据库的事务日志记录发送到每个辅助数据库。每个辅助副本缓存事务日志记录（“硬化”日志），然后将它们应用到相应的辅助数据库。主数据库与每个连接的辅助数据库进行数据同步。因此，一个辅助数据库可以挂起或失败而不会影响其他辅助数据库，一个主数据库可以挂起或失败而不会影响其他主数据库。

或者，您可以配置一个或多个辅助副本以支持对辅助数据库进行只读访问，并且可以将任何辅助副本配置为允许对辅助数据库进行备份。部署 AlwaysOn可用性组需要一个 Windows Server故障转移群集 (WSFC)群集。

图显示一个可用性组，该组包含最大数目的可用性副本，即一个主副本和四个辅助副本。

来自：http://msdn.microsoft.com/zh-cn/library/ff877884.aspx

虽然2012 Always on是基于WSFC的，但是并不需要共享存储，所以配置就非常简单。

下面是我的安装步骤：

至少需要三台机器（我创建了三台虚拟机，一台是作为DC,DNS服务器，两台Nod3）

（备注：为啥一定要3台，因为SQL SERVER 的 Cluster服务不能安装在域服务器上。Windows2008 R2 和SQL SERVER 2012 一定要打上sp1.否则有不可预知的错误）

机器名

角色

OS

IP Address

DC

Domain Controller

Windows 2008R2

192.168.1.10

Node1

Cluster Node 1

Windows 2008R2

192.168.1.11 Public

192.168.2.1

心跳线

Node2

Cluster Node 2

Windows 2008R2

192.168.1.12 Public

192.168.2.2

心跳线窗体底端

首先配置Windows集群：

1. 安装.NETFramework 3.5.1 Features和Failover Clustering

2. 安装Windows KB 2494036

3.新建集群

4.选择加入集群的服务器：

5.检测配置：

6.不需要选择检测共享磁盘（AlwaysOn不需要）

7.开始检测：

8.检测内容（检测完成后可以导出Report）：

9.之后输入Cluster名字和IP点击下一步创建成功，成功后打开Server Manager查看集群配置(可以看到并没有共享磁盘，跟传统的集群还是有区别的)：

现在我们集群已经配置后了，下一步是安装SQLServer并且配置Always On.

我们已经配置了Cluster,Part2 我们安装SQL Server 2012 评估版（要使用64位的SQLServer, X86不支持Always On）并且配置Alaways On Group.

1. 以管理员身份安装

2.选择单机安装（不是集群安装）

3.SQL Server 2012的新功能，可以在安装的时候搜索最新的补丁，将补丁也以前安装（这个是可选项）

4.规则检测

5.选择安装组件

6.实例名：

7.计算需要的磁盘空间：

8.Service账户（域账户）：

9.排序规则（可以根据自己需要选择）：

10.设置权限，数据库文件备份地址以及Filestream选项：

11.安装后需要重新启动（可以查看安装日志）：

12.在ConfigurationManager中对SQL Server开启Always OnHigh Availability(可以自动检测到前面我们创建的Cluster名字)

设置更改后需要重启Service.现在一切都具备了，我们可以配置Always On group了。

1.创建新的可用性组（可用性组向导，也可以用下面的选型）：

2.输入可用性组的名字：

3.选择组中的数据库：

4.Replica 选择Node2（选择自动Failover/可读数据库）:

5.点击下一步，Node1将会备份数据库到Share Folder然后还原到Node2做同步 (Node1为主,Node2为辅助)

下一步就是测试Node2数据可读已经Failover.

可用性组我们已经创建成功了，现在测试一下Node2 上读取数据以及Failover.

1. 数据测据：Node1上创建表test插入记录

在Node2上访问test数据库，数据可以查到（在Mirror中是不可以查询的，而且数据同步不会导致Node2的连接断掉）：

2. Failover测试：

连接到Node2:

Failover后（Primary已经变成Node2）：

可以看到Always On group 既保证了高可用性，有可以实现同步数据库的只读访问，提供了硬件的利用率，非常给力的一个功能。

最后，建议在 “AlwaysOn 高可用性 ”下-》 “可用性组” 中，增加一个可用性组侦听器，在侦听器中可以设定一个IP，对外用此IP提供服务。这样，SQL服务的IP可以不同于windows集群的IP。两项服务有可能会在两台不同的机器上。