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

Posted 2023-04-06

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。两项服务有可能会在两台不同的机器上。 参考技术A 不支持。需要企业版。

sql server 搭建发布订阅后，改端口不正常工作的问题

sql 的发布订阅，想必大家都了解，但一般都是在默认的1433的情况下搭建的，那么1433换成别的端口，发布还能正常工作吗？

  在一次客户的真实场景上我就遇到了。

 

好了，今天不想写太多，简化下， 测试环境

   发布服务器  计算机名 win-01 

   分发服务器  计算机名 win-01  （与发布用的同一台）

   订阅服务器  计算机名 win-02

   用到的试验库是  YY

 

  在默认的端口1433  的场景下 ，我们已经搭建起了发布订阅，如图

 

   

做了两张表的复制。

 

 

我们看下 复制监视器  

 

 在win-01 的 表中插入、删除、修改都是正常的，这里就不多做介绍了。

 

那么 ，这时我们把win-02 这台实例默认的 1433 改成 4111 后，订阅还正常不？

 

 我们此时再看下复制监时器的状态，如图

这是状态已经是，连不上订阅的状态了， 此时我们再写入数据，

发布服务器 win-01 

 

订阅服务器win-02  

可以看到，并没有同步过来。此时应该怎么办呢？

经过测试发现，只需要在win-01 也就是 分发的服务器上，通过建立别名的方式去映射就可以了。

win-01 上建立别名  如图

 

 记住两个都要创建上，32位的是给通过图形界面创建订阅用到的别名，64位的 是给同步程序用的（不需重启）。

这是我们再看复制监视器 

 

再看 win-02 上的表中的数据  如图

 

 已经同步过来了。