GVKun编程网logo

SQL Server在AlwaysOn中使用内存表的“踩坑”记录（sql always on）

19

在这篇文章中，我们将为您详细介绍SQLServer在AlwaysOn中使用内存表的“踩坑”记录的内容，并且讨论关于sqlalwayson的相关问题。此外，我们还会涉及一些关于AlwaysOn进阶Lev

在这篇文章中，我们将为您详细介绍SQL Server在AlwaysOn中使用内存表的“踩坑”记录的内容，并且讨论关于sql always on的相关问题。此外，我们还会涉及一些关于AlwaysOn 进阶 Level 1：What is "SQL Server AlwaysOn"?、Alwayson(1)——SQLServer2014的安装要求、SQL SERVER 2012 AlwaysOn - 维护篇 03、SQL SERVER 2012 AlwaysOn– 数据库层面 02的知识，以帮助您更全面地了解这个主题。

本文目录一览：

SQL Server在AlwaysOn中使用内存表的“踩坑”记录（sql always on）

SQL Server在AlwaysOn中使用内存表的“踩坑”记录（sql always on）

前言

最近因为线上alwayson环境的一个数据库上使用内存表。经过大概一个星期监控程序发现了一个非常严重问题这个数据库的日志文件不会截断，已用空间一直在增加（存在定时的每个小时的日志备份），同时内存表数据库文件也无法删除，下面就介绍一下后面我的处理过程，话不多说了，来一起看看详细的介绍吧。

数据库：

sql Server2014 Enterprise Edition (64-bit)

删除文件

使用一个单独非alwayson环境的数据库测试。

一、创建内存表

rush:sql;"> ---创建内存表文件组 ALTER DATABASE [test] ADD FILEGROUP [test_ag] CONTAINS MEMORY_OPTIMIZED_DATA GO ----创建内存表数据库文件 ALTER DATABASE [test] ADD FILE ( NAME = 'test_memory',FILENAME ='D:\database\memory' ) TO FILEGROUP [test_ag]; GO

二、删除内存表数据库文件

rush:sql;"> USE [test] GO ALTER DATABASE [test] REMOVE FILE [test_memory] GO

备注：此时还未创建表，创建完后数据库文件执行删除就无法删除，接下来试试在线文档的删除方法方法

三、官方相关的删除方法

即使已使用“DBCC SHRINKFILE”操作清空 FILESTREAM 容器，但出于各种系统维护原因，数据库可能仍然需要保留对已删除文件的引用。 sp_filestream_force_garbage_collection (TRANSACT-sql)将运行 FILESTREAM 垃圾回收器删除这些文件时，则可以安全进行这些操作。 除非 FILESTREAM 垃圾回收器已从 FILESTREAM 容器中删除所有文件，否则 ALTER DATABASEREMOVE FILE 操作将无法删除 FILESTREAM 容器并返回错误。 建议使用以下过程删除 FILESTREAM 容器。

1.运行DBCC SHRINKFILE (TRANSACT-sql)带有 EMPTYFILE 选项以将此容器的活动内容移动到其他容器

rush:sql;"> USE test; GO -- Create a data file and assume it contains data. ALTER DATABASE test ADD FILE ( NAME = Test1data,FILENAME = 'D:\database\t1data.ndf',SIZE = 5MB ); GO -- Empty the data file. DBCC SHRINKFILE (test_memory,EMPTYFILE); GO

数据库已经无需日志备份，当然我已经执行过日志备份。

4.运行sp_filestream_force_garbage_collection (TRANSACT-sql)强制垃圾回收器删除不再需要此容器中的任何文件

rush:sql;"> USE [test] GO EXEC sp_filestream_force_garbage_collection @dbname = N'test' @filename = N' test_memory ';

5.执行带有 REMOVE FILE 选项的 ALTER DATABASE，以删除此容器。

rush:sql;"> USE [test] GO ALTER DATABASE [test] REMOVE FILE [test_memory] GO

还是无法删除！！！

四、问题分析

一开始是在alwayson的环境中删除，提示由于副本的原因无法删除。后面单独在一个非alwayson的环境下的数据库测试同样是无法删除，起初以为是创建了内存表的原因后面测试仅仅创建文件组和文件然后来删除文件同样是无法删除，个人猜测有可能是buffer的缘故；在buffer中一直存在内存表相关的文件存在，通过执行DBCC DROPCLEANBUFFERS命令也无法清空buffer中的内存表对象。使尽浑身解数还是无法将它删除掉，最后只能投降了！！！线上环境等不下去；只能使用最不愿使用的生成表结构导出数据的办法来重建新的数据库。

生成脚本重建数据库

创建一个新的数据库同时保证当前数据库可用（重命名当前的数据库，新创建的数据库使用之前的名称这样可以保证应用程序那边不需要改变），这样如果出现什么问题也可以及时的切换回来。

步骤如下（在允许停机维护的情况下进行）：

1.禁用所有相关作业

2禁用应用程序登入用户

同时保证相关进程事务都已完成。

rush:sql;"> ALTER LOGIN [test] disABLE GO

USE [master]
GO
ALTER DATABASE [test] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;--将数据库设置成单用户并回滚当前连接

USE [test];---保持连接操作,防止其它用户此时进行连接
GO

3.执行checkpoint刷新所有脏页

rush:sql;"> CHECKPOINT

---返回当前buffer中每个数据库所占的buffer大小和buffer中脏页的大小
WITH CTE1
AS ( SELECT COUNT() 8 / 1024 AS dirty_cached_size_MB,COUNT() AS dirty_pages,CASE database_id
WHEN 32767 THEN 'ResourceDb'
ELSE DB_NAME(database_id)
END AS database_name
FROM sys.dm_os_buffer_descriptors
WHERE is_modified = 1
GROUP BY DB_NAME(database_id),database_id
),CET2
AS ( SELECT COUNT() 8 / 1024 AS cached_size_MB,COUNT() AS pages,CASE database_id
WHEN 32767 THEN 'ResourceDb'
ELSE DB_NAME(database_id)
END AS database_name
FROM sys.dm_os_buffer_descriptors
GROUP BY DB_NAME(database_id),database_id
)
SELECT
CET2.database_name,CET2.cached_size_MB,--CET2.pages,CTE1.dirty_cached_size_MB
--CTE1.dirty_pages
FROM CTE1 INNER JOIN CET2 ON CTE1.database_name = CET2.database_name

---将数据库选项改成多用户访问
ALTER DATABASE [test]
SET MULTI_USER;

4.生成数据库脚本

5.重命名旧的数据库

注意：如果数据库是在alwayson中，需要先从可用性数据库中删除，否则无法重命名数据库。

rush:sql;"> /* 1.断开数据库所有连接同时禁止新的连接进来 2.比如禁止登入用户、将实例设为单用户模式等。 */ ----1.设置数据库脱机 USE [master] ALTER DATABASE [test] SET OFFLINE WITH ROLLBACK IMMEDIATE;

----2.手动修改数据库物理文件名，例如将test.mdf改成test_old.mdf

----3.语句修改
USE [master]
ALTER DATABASE [test]
MODIFY FILE (NAME = test,FILENAME = 'C:\Program Files\Microsoft sql Server\MSsql12.MSsqlSERVER\MSsql\DATA\test_old.mdf');
GO
ALTER DATABASE [test]
MODIFY FILE (NAME = test_log,FILENAME = 'C:\Program Files\Microsoft sql Server\MSsql12.MSsqlSERVER\MSsql\DATA\test_old_log.ldf');
GO

---4.设置数据库在线
USE [master]
ALTER DATABASE [test] SET ONLINE

----5.修改数据库逻辑文件名

USE [test]
GO
ALTER DATABASE [test] MODIFY FILE (NAME=N'test',NEWNAME=N'test_old')
GO
USE [test]
GO
ALTER DATABASE [test] MODIFY FILE (NAME=N'test_log',NEWNAME=N'test_old_log')
GO

----6.重命名数据库
USE [master]
EXEC sp_renamedb N'test',N'test_old';

----7.查询
SELECT *
FROM sys.master_files
WHERE database_id = DB_ID('test_old');

6.创建新的数据库同时导入脚本到新的数据库

如果同时导出表结构和数据在ssms工具中执行可能会因为脚本过大无法执行，可以使用sqlcmd工具执行脚本导入，具体方法可以百度一下。当然还有其他方法就是只导出表结构然后通过“导出数据\导入数据”的方法同步数据。

注意：如果使用“导出数据\导入数据”的方法同步数据，注意勾选“启用标示插入”

7.其它

1.如果存在alwayson记得将新的数据库加入到可用性数据库组中。

2.将新的数据库加入到备份作业中。

3.对比新旧两个数据库的表数量是否相同。

4.配置登入用户新的数据库权限。

总结

内存表是2014新引入的功能所以对于新功能的第一个版本使用要比较慎重，特别是在线上环境。虽然在上线之前做过测试，但是显然备份这块的测试往往比较容易被忽略因为没有线上的这种环境。好在是这次影响的是一个新上的项目数据量和并发都很小且允许节假日停机维护；如果是非常大的系统对于需要导入导出数据肯定是非常头疼的事情关键还得看允许停机的时长。因为自己在生产环境踩了坑，写这篇文章希望后面的人可以避免踩坑。

备注：内存表在2014版本的alwayson中无法同步到辅助副本，这就导致了它的作用大打折扣，2016版本可以同步到辅助副本，建议有条件的直接上2016。

好了，以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对小编的支持。

AlwaysOn 进阶 Level 1：What is

AlwaysOn 进阶 Level 1：What is "SQL Server AlwaysOn"?

By Perry Whittle，2016/02/24（首次发布：2014/09/24）

关于系列

本文属于进阶系列：Stairway to AlwaysOn

AlwaysOn是一套复杂的技术，往往被误解。在这个阶梯中，您将学习AlwaysOn技术，它们如何适应高可用性堆栈，以及如何充分利用它们。

欢迎来到“SQL Server AlwaysOn的阶梯”系列的第一个级别。在这篇1级文章中，我们将发现“AlwaysOn”，“故障转移群集实例”（FCI）和“Windows Server故障转移群集”技术。我们将详细介绍每个细节并总结它们所在的高可用性堆栈的位置。这将为我们提供一个良好的基础，这对上升的楼梯水平是必不可少的。较高级别的楼梯将研究AlwaysOn可用性组和FCI使用的所需基础架构和不同的存储要求和选项。

在每个楼梯层次之后，您将进一步了解AlwaysOn结构如何构建。尽管作为DBA，您可能没有与AlwaysOn和FCI下面的核心基础设施项目进行任何直接交互，但是有助于全面了解所有技术如何集成。最后的楼梯将导致一个功能AlwaysOn配置。

我们首先要看基础知识，其中包括对已经提到的3种技术的简要描述。

AlwaysOn描述中使用了许多首字母缩写词和缩写词。本文结尾处包含了一个常用术语表。

不用多说，让我们深入了解每种技术。

Windows服务器故障转移群集

Windows Server故障转移群集（WSFC）是位于所有Microsoft高可用性应用程序下的核心高可用性（HA）产品。 WSFC是Windows Server操作系统软件套件的一部分。在创建SQL Server的故障转移群集实例，AlwaysOn高可用性组或甚至Microsoft Exchange邮件服务器群集之前，您需要部署和配置WSFC。

Windows Server故障转移群集提供了将多个计算机节点（物理和/或虚拟）组合起来为一组应用程序提供高可用性的能力。应用程序是服务器软件，如SQL Server或Exchange，我们希望能够在任何节点上运行。通过向客户端呈现包括唯一IP地址和唯一计算机名称或“虚拟网络名称”的虚拟接入点来使应用高度可用。此地址和虚拟名称成为应用程序组中的资源，并在参与节点（如令牌）之间传递。活动计算机节点的严重硬件故障将导致在该节点上运行的组服务的丢失。群集服务将根据故障类型（硬件或软件）自动尝试重新启动当前节点或伙伴节点上的组。

在较高级别上，客户端访问点详细信息与任何磁盘和服务资源一起传输到故障转移伙伴节点。群集实例的故障转移会导致客户端连接断开;一旦服务在另一个节点上可用，则客户端可以重新连接。常见的故障通常是其中之一，但是应用程序的任何故障都可能导致服务移动到另一个节点：

  • 公用NIC或网络故障
  • 电源故障
  • 主板故障
  • CPU故障

使用WSFC时，群集应用程序被安装到单独的组或“应用程序”中，其中包含一组资源，如磁盘，服务，IP地址等。组及其资源在任何时候都由单个节点拥有，而除非有计划的交换机或故障转移到该节点，否则不能从任何其他伙伴节点访问资源。

下面显示了Windows Server故障转移群集的典型视图。群集节点全部通过网络连接，域控制器和DNS服务与WSFC一起工作，以允许客户端连接到虚拟IP或虚拟网络名称，无论服务在哪个节点上运行。


为了部署FCI，计算机节点必须使用共享存储，这些存储通常从SAN出现给每个节点。为了部署一个典型的AlwaysOn组，节点利用自己的本地存储，而不是与其他集群伙伴共享。

尽管群集节点可能具有不同的硬件，但通常最好将节点间的硬件保持一致，以避免功能较弱的节点无法处理超出其功能的负载。但是，节点必须使用相同的操作系统补丁级别和网络配置;在部署Windows Server故障转移群集之前验证您的配置时，这将变得清晰。 Windows Server版本（Windows 2003中的8个节点，Windows 2008中的16个节点和Windows 2012中的64个节点）的最大群集节点数量不同。

部署强大的Windows Server故障转移群集需要仔细的设计，支持的硬件和相应版本的Windows Server操作系统。地理分散的集群（跨多个WAN的集群）进一步增加了所需的设计和规划的数量，并显着增加了成本。

知道WSFC仅提供故障转移伙伴功能很重要。应用程序在节点之间没有负载平衡或扩展。每个服务都运行在一个且只有一个节点上。

通常，在大型多节点群集中，您可以在Windows Server故障转移群集节点的子集上安装群集应用程序。在所有节点上安装应用程序的错误都可能导致一些不希望的故障转移，我们将在后面看到，也违反了AlwaysOn组限制策略，这可以确保所有AlwaysOn实例驻留在集群中的不同节点上。

WSFC需要某种形式的中介来控制群集资源所有权。此仲裁以Cluster Quorum的形式提供。自Windows 2003 SP1以来，此Quorum采用节点投票系统的形式，维持Quorum所需的多数选票。您还可以使用磁盘形式的其他仲裁资源进行本地化群集，也可以使用多站点群集的远程文件共享。从Windows Server 2012开始，法定人数使用动态节点权重配置在计划中断期间动态平衡群集投票，以防止不必要的故障转移。我们将在未来的层面更详细地讨论法定人数。

故障转移群集实例

SQL Server的故障转移群集实例一直是SQL Server产品中流行的高可用性技术。 SQL Server高度可用的实例是集群化的，以减轻任何节点硬件故障和任何潜在的软件故障。 这里唯一的薄弱环节是存储; 存储子系统成为单点故障。

故障转移群集实例是默认或命名的SQL Server实例，已作为群集应用程序安装到WSFC上。 群集应用程序通常具有以下资源：

  • IP地址
  • 网络名字
  • 共享磁盘
  • SQL Server服务
  • SQL Server代理服务

独立实例共享相同的基本要求，不同之处在于，使用独立实例时，IP地址和网络名称将从计算机节点本身获取，而磁盘存储由计算机的本地磁盘资源提供。

参考上面的图，我们看到了具有单个FCI的2节点集群的典型视图。 SQL Server的群集实例将使用已呈现给WSFC节点的任何共享存储。通常这种存储将采取从SAN提供的LUN的形式。 SQL Server的FCI部署在一个两步的过程中，这个过程将在稍后的阶梯中介绍。现在，下面是部署SQL Server的故障转移群集实例的两步过程的基本概述：

  1. 在将参与FCI的第一个计算机节点上启动“新建SQL Server故障转移群集安装”向导。一旦完成并成功完成，您就可以进入第二阶段了。
  2. 在希望加入新的SQL Server FCI的WSFC中的任何计算机节点上启动“将节点添加到SQL Server故障转移群集”向导。

注意：尽管标准版将FCI限制为2个节点，但并不指定有多少节点具有Windows群集的成员资格（您可能有任何数字，直到操作系统的最大值）。该限制是在SQL Server安装程序级别执行的。

FCI有点像一个跑道接力队的传球过程;计算机节点拥有群集的SQL Server应用程序及其资源，然后为客户端提供对SQL Server服务（持有接力棒）的访问权限。当活动的计算机节点失败（下落接力棒）时，合作伙伴节点进入并获得集群应用程序及其资源的所有权（接上接力棒）。

AlwaysOn可用性组

多年来，故障转移群集一直是为SQL Server提供高可用性的主要方法。当一个节点失败时，另一个节点接管向客户端提供SQL Server服务。 AlwaysOn与Windows Server故障转移群集技术集成，提供更具弹性的高可用性平台。

尽管群集在实例级别上工作，但AlwaysOn在数据库级别配置。 AlwaysOn可用性组是SQL Server 2012中引入的新技术，用于将预定义的数据库组复制到AlwaysOn中已知的一组只读伙伴实例或副本。多个节点各自托管一个AlwaysOn数据库的同步副本，并且最好通过监听器的配置来提供访问（稍后会详细介绍）。

AlwaysOn可用性组需要一个或多个辅助副本来托管高可用性数据库的副本。这些辅助数据库可能是可读或不可读的。它们也可以以异步或同步的方式进行更新。异步副本仅支持手动强制故障转移，而同步副本支持自动或手动故障转移。

次要只读副本可以配置为响应只读查询，您也可以将目标的次要目标作为备份/维护操作以减轻主数据库的压力。这种主从关系也是可逆的，以确保真正的高可用性。任何经过适当配置的只读伙伴在系统发生故障时都可能承担主角色。

AlwaysOn依靠WSFC核心功能实现AO提供的高可用性，但不需要与FCI相关的以下任何共享资源。

  • 共享磁盘
  • 共享的IP地址
  • 共享网络名称
  • 共享的SQL Server和SQL Server代理资源

这个共享资源规则有一个例外。创建AlwaysOn组侦听器时，将创建将由AO组副本共享的IP地址和网络名称资源。

正如我们所发现的，故障转移群集实例链中的薄弱环节是共享存储。这里有很多方法可以实现冗余，但是通常成本很高，而且安装和维护通常很困难。当然，如前所述，故障转移群集实例只能缓解服务器硬件。它不提供单个或甚至多个辅助数据库。我们在SQL Server 2012之前的SQL Server版本中有数据库镜像，但这些仅为单个不可读的辅助数据库提供了范围。

AlwaysOn仍然使用熟悉的SQL Server端点作为实例通信。端点在使用可用性组部署向导时自动配置。向导驱动的部署提供了最简单的部署路径，而手动部署需要大量的手动交互。尽管如此，一个基本的AlwaysOn组配置仍然非常容易部署和配置，并提供以前不可用的HA级别，而无需采用复杂的功能集成级别。

您也可以创建一个高可用的侦听器服务，您将使用该服务来接受到可用性组的传入连接。监听器由一个唯一的IP地址和一个唯一的虚拟网络名称组成。这是使组内数据库高度可用的最重大变化之一。

在创建AlwaysOn可用性组期间，将在Windows Server故障转移群集内创建一个群集角色，并包含一个资源。此资源在AlwaysOn组故障转移期间在伙伴节点之间进行故障转移，并标识AlwaysOn组的主副本。

AlwaysOn听众

监听程序在配置时将作为资源创建，并驻留在AlwaysOn可用性组的故障转移群集应用程序角色中。资源是：

  • 虚拟IP地址
  • 虚拟网络名称

侦听器使用TCP端口来接受传入的连接，并默认连接到主副本。当只读路由已配置时，指向只读意向连接的监听程序的连接将被路由到辅助伙伴而不是主要副本。这是我们可以减轻主副本负载的另一种方式。

在AlwaysOn组的故障转移期间，群集中的节点之间的群集应用程序及其资源将发生故障转移。群集应用程序的节点位置跟​​踪主副本及其底层节点，并根据需要在群集中移动。在主副本是SQL Server的群集实例的情况下，侦听器由该FCI 副本的主动节点拥有。

结论

这就是阶梯1的结尾，它提供了3个核心技术的快速介绍，用来使我们的SQL Server实例及其对象高度可用。 在我们的高可用性堆栈中，我们将WSFC作为基本级别，这是安装FCI或AlwaysOn可用性组的主要要求。 接下来，我们有了位于WSFC顶部的FCI，它依靠群集来服务和保护SQL Server实例。 最后，我们有AlwaysOn组，坐在SQL Server的独立实例和SQL Server的“故障转移群集实例”之上。

在2级中，我们将查看SQL Server High Availability中可用的存储类型及其典型用法。 这将帮助您了解系列中未来的阶梯级别。

词汇表

AO AlwaysOn可用性组
FCI SQL Server的故障转移群集实例
TCPIP 传输控制协议/互联网协议。 Microsoft客户端网络使用的网络协议
OS / NOS 网络操作系统
WSFC Windows Server故障转移群集
LAN 局域网
WAN 广域网
DNS 域名系统
DHCP 动态主机配置协议，自动为网络计算机分配IP地址
IP Address 32位（IPV4），分配给计算机对象的唯一地址
AD Active Directory，目录服务。 用于Windows域中的对象管理的Microsoft技术
DR 灾难恢复
SPF 单点故障
SCSI 小型计算机系统接口
iSCSI Internet小型计算机系统接口
FC 光纤通道
Replica SQL Server AlwaysOn可用性组中使用的术语引用作为特定AlwaysOn组的一部分的SQL Server实例

Alwayson(1)——SQLServer2014的安装要求

Alwayson(1)——SQLServer2014的安装要求

sqlServer2014的安装， 谈不上难， 但如果你不把握好， 可能还是安装不上的。

首先是软硬件环境。最好看一下： 安装 SQL Server 2014 的硬件和软件要求

因为要搭建 Alwayson 集群，而不是在自己本机玩玩新特性， 所以需要服务器版本的OS才行。 

win2003就不要奢望了，最好是2008或者2012。我这里就采用 Windows Server 2008 R2 Enterprise 。

在安装 sqlServer2014 之前， 做好两个非常重要的准备工作。 

1. 安装 .net framework 3.5.1 ， 这个可以直接在“服务器管理器”中完成， 如下图，比较简单不再赘述。


2. 安装 windows server 2008 的 sp1 补丁。 下载地址： windows server 2008 sp1


这两点搞好了， 安装sqlServer2014就顺风顺水了， 安装过程也比较简单， 不再赘述。


上面只是sqlServer2014的安装要求， 但要想使用 Alwayson 的功能， 必须还安装两个玩意：

1. 域控制器。  请参考： 点击打开链接

2. Windows故障转移群集。 请参考： 点击打开链接

官方要求链接：点击打开链接


所以， 想用上Alwayson， 至少得准备 3 台机：

一台 域控制器所在的服务器，两台DB服务器

注意：域控服务器不能用来做DB服务器： https://msdn.microsoft.com/zh-cn/subscriptions/downloads/ff878487.aspx

如果完善一点， 应该要3台DB服务器， 因为Windows故障转移群集正常来说需要3台。

呵呵， 用虚拟机的话， 你的内存有点不够使了吧。


试验过程可以关防火墙， 但服务器生产环境上 应该开3个端口：

TCP/IP: 数据库端口(默认1433),5022 udp:    1434

SQL SERVER 2012 AlwaysOn - 维护篇 03

SQL SERVER 2012 AlwaysOn - 维护篇 03

搭建 AlwaysOn 是件非常繁琐的工作，需要从两方面考虑，操作系统层面和数据库层面，AlwaysOn 非常依赖于操作系统，域控，群集，节点等概念；

DBA 不但要熟悉数据库也要熟悉操作系统的一些概念；否则理解的会不深刻，一旦AlwaysOn 出现故障，首先根据错误日志，来排查是操作系统问题还是数据库问题；

部署AlwaysOn 分三部分：

1,操作系统层面； https://www.cnblogs.com/lvzf/p/10565298.html

2,数据库层面；    https://www.cnblogs.com/lvzf/p/10566598.html

3,维护AlwaysOn;   https://www.cnblogs.com/lvzf/p/10569857.html

本篇文章详细介绍- AlwaysOn 维护

接上文 SQL SERVER 2012 AlwaysOn - 数据库层面 02 下面开始对AlwaysOn 维护进行介绍；

1，新增数据库

可用性组添加数据库 Test

数据库初始化过程省略，详细请看上面【数据库层面 02 】 初始化过程

点击：AlwaysOn 高可用性 – 可用性组-可用性数据库-添加数据库

image

选中 Test 数据库 点击 【下一步】

image

选中 - 【仅联接】，点击 【下一步】

image

点击【全部联接】 联接 DB128，DB129 数据库实例；

image

image

image

image

下图显示 Test 数据库已经加入到可用性组 FlowCluster

image

 

2，可用性组故障转移

把可用性组从 DB124 转移到 DB128，可用性组的所有数据库做为一个整体转移 FlowCluster – 右键 – 故障转移 – 如下图：

image

选中 DB128，把主副本转移到 DB128 数据库服务器上，如下图：

image

image

 

image

 

image

故障转移成功；DB124 转移到 DB128
DB124 由原来的【主要角色】 转变成【辅助角色】
DB128 由原来的【辅助角色】转变成【主要角色】

image

image

Note:
-  前端程序写操作，如果直接联接【侦听器】， 那么故障转移后 会自动把连接转移到新的主角色；

-  前端程序写操作，如果直接联接主服务器角色，那么故障转移后，写操作字符连接配置文件需要修改到新的主角色；

-  如果前后端做了读写分离，直接联接【侦听器】，自动分发读写操作到指定的服务器，只读操作分发到只读数据库服务器；

 

 

部署AlwaysOn 分三部分：

1,操作系统层面； https://www.cnblogs.com/lvzf/p/10565298.html

2,数据库层面；    https://www.cnblogs.com/lvzf/p/10566598.html

3,维护AlwaysOn;   https://www.cnblogs.com/lvzf/p/10569857.html

SQL SERVER 2012 AlwaysOn– 数据库层面 02

SQL SERVER 2012 AlwaysOn– 数据库层面 02

搭建 AlwaysOn 是件非常繁琐的工作，需要从两方面考虑，操作系统层面和数据库层面，AlwaysOn 非常依赖于操作系统，域控，群集，节点等概念；

DBA 不但要熟悉数据库也要熟悉操作系统的一些概念；否则理解的会不深刻，一旦AlwaysOn 出现故障，首先根据错误日志，来排查是操作系统问题还是数据库问题；

部署AlwaysOn 分三部分：

1,操作系统层面； https://www.cnblogs.com/lvzf/p/10565298.html

2,数据库层面；    https://www.cnblogs.com/lvzf/p/10566598.html

3,维护AlwaysOn;   https://www.cnblogs.com/lvzf/p/10569857.html

 

本篇文章详细介绍- 数据库层面的部署；

接上文 SQL SERVER 2012 AlwaysOn - 操作系统层面 01 下面开始对AlwaysOn 数据库层面的部署

 

1，搭建AlwaysOn - 可用性组

1.1 安装 SQLSERVER 2012( - sp2)

点击【全新 SQLSERVER 独立安装…….】不要点击【新的 SQLSERER 故障转移群集安
装 】做 AlwaysOn 可用性组 不需要 SQLSERER 群集

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

 

image

image

image

image

安装 SP2 补丁包

image

image

image

image

image

image

 

 

1.2 配置 AlwaysOn

因为生产环境数据库较大，为了不影响业务运行，短时间内能创建 AlwaysOn ， 我们采用备份+还原方式配置 AlwaysOn ；

各个节点担当的角色如下：
主：   192.168.140.124
辅同：192.168.140.128
辅异：192.168.140.129

启用 AlwaysOn 可用性组 （三个节点做同样的操作）

image

 

右键 SQLSERVER 服务 – 属性-AlwaysOn 高可用性 – 启用 AlwaysOn 可用性组 ； 

image

 

- 重启 SQLSERER 服务（三个节点做同样的操作）

- AlwaysOn 初始化数据库

 

- DB124 创建数据库 Flow  

image

 

- 完整备份数据库[Flow] 

USE MASTER
GO
BACKUP DATABASE [Flow] TO DISK=''E:\Backup\Flow_full_20160122.bak'' WITH CHECKSUM,NOFORMAT,INIT,SKIP
GO

- 数据库[Flow]日志备份

USE MASTER
GO
BACKUP LOG [Flow] TO DISK=''E:\BackupLog\FlowLog_1.bak''
GO

- 把完整备份和日志备份拷贝到 DB128，DB129 服务器；

- DB128，DB129 还原数据库[Flow];( 注意：NORECOVERY 模式，非常重要 ) 

USE [master] 
GO
RESTORE DATABASE [Flow] FROM DISK = N''E:\Backup\Flow_full_20160122.bak'' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5 
GO

- DB128，DB129 还原日志[UCardFlow];( 注意：NORECOVERY 模式，非常重要 )

USE MASTER
GO
RESTORE LOG [Flow] FROM DISK = N''E:\BackupLog\FlowLog_1.bak'' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10 
GO

image

 

- 以 DB124 为主节点 创建 AlwaysOn

右键[AlwaysOn 高可用性] - 新建可用性组向导

image

image

点击 【下一步】,输入可用性组名称【FlowCluster】

image

点击【下一步】 选中 Flow 数据库

image

 

点击【下一步】添加副本，添加 DB128，DB129 副本

image

点击【端点】输入对应的 IP 地址

image

点击【备份首选项】 选中主副本

image

 

image

下一步，选中【仅联接】因为前期已经做完数据库初始化

image

下一步，出现警告（正在检查侦听器配置），不用理会，因为我们还没有配置侦听器；

image

下一步

image

 

点击【完成】
也可以点击【脚本】生成 SQL 脚本，下次利用脚本配置 AlwaysON 能快速完成

image

 

- 配置侦听器

DB124 – 可用性组侦听器-右键-添加侦听器

（因为我们前面没有配置侦听器，到这一步我们手动配置，其实道理一样）

 

image

输入侦听器 DNS 名称 DB150，端口 1433，IP 192.168.140.150

image

点击确定；

- 下图是整个 AODB 配置完成后 主服务器实例的情况；

image

查看 AlwaysOn 可用性组的详情

可用性组名称 – FlowCluster 右键 – 属性 如下图

image

我们是三个节点的 AlwaysOn ，其中 DB124 是主角色，DB128，DB129 是辅助角色
DB124 对外提供读写服务。DB128，DB129 对外提供只读服务，根据业务情况，选择具体
的只读服务器。其中 DB129 异步提交可以做为异地灾备服务器；

image

 

打开域控服务器 AD1074 DNS 记录，发现服务器 IP,以及群集，侦听器 IP 都记录在内

image

 

至此AlwaysOn 数据库层面配置完成；

 

部署AlwaysOn 分三部分：

1,操作系统层面； https://www.cnblogs.com/lvzf/p/10565298.html

2,数据库层面；    https://www.cnblogs.com/lvzf/p/10566598.html

3,维护AlwaysOn;   https://www.cnblogs.com/lvzf/p/10569857.html

今天的关于SQL Server在AlwaysOn中使用内存表的“踩坑”记录和sql always on的分享已经结束，谢谢您的关注，如果想了解更多关于AlwaysOn 进阶 Level 1：What is "SQL Server AlwaysOn"?、Alwayson(1)——SQLServer2014的安装要求、SQL SERVER 2012 AlwaysOn - 维护篇 03、SQL SERVER 2012 AlwaysOn– 数据库层面 02的相关知识，请在本站进行查询。

本文标签：

上一篇SQL Server 2016 Alwayson新增功能图文详解（sql server 2016 always on）

下一篇SQL Server 2012 sa用户登录错误18456的解决方法（sql2008r2用户sa登录失败错误18456）

相关文章