SQL Server AlwaysON 同步模式的疑似陷阱

  • 时间:
  • 浏览:0

WAITFOR DELAY '00:00:00.900'

23

SELECT  COUNT(*)

遗憾的是,这一同步并有的是数据的实时同步,当主副本数据位于变化时,同步模式下的辅助副本何必 能立即取到变化的数据。

22

18

        SELECT  NEWID()

那先 守护进程在工作上个人所有所有独立,以达到更高的传输速率。Log Scanner负责传送日志块,而何必 停留Log Writer完成日志固化;辅助副本完成日志固化时候就会发送消息到主副本,告知数据原因传递完毕,而何必 停留重做完成。其设计目标,是尽原因地减少AlwaysOn所带来的额外操作对正常数据库操作的性能影响。

4

14

19

12

任何一十个 SQL Server里有的是个叫Log Writer的守护进程,当任何一十个 SQL用户提交一十个 数据修改事务时,

它会负责把记录本次修改的日志信息先记入一段内存中的日志缓冲区,怎么能让再写入物理日志文件(日志固化)。好多好多 对于任何一十个 数据库,日志文件里有的是有所有数据变化的记录。对于配置为AlwaysOn主副本的数据库,SQL Server会为它建立一十个 叫Log Scanner的工作守护进程。这一守护进程专门负责将日志记录从日志缓冲区原因日志文件里中读出,打包成日志块,发送给各个辅助副本。原因它的不间断工作,才使主副本上的数据变化,还没有不断地向辅助副本上传播。辅助副本上,同样会一十个 守护进程,完成相应的数据更新动作,它们是固化(Harden)和重做(Redo)固化守护进程会将主副本Log Scanner所发过来的日志块写入辅助副本的磁盘上的日志文件里(这一过程被称为"固化")。而重做守护进程,则负责从磁盘上读取日志块,将日志记录翻译成数据修改操作,在辅助副本的数据库上完成。当重做守护进程完成其工作时候,辅助副本上的数据库就会跟主副本一致了。AlwaysOn可是通过这一机制,保持副本之间的同步。重做守护进程每隔固定的时间点,会跟主副本通信,告知它被委托人的工作进度。主副本就都都都能不能知道两边数据的差距有多远。

2

7

5

SELECT  COUNT(*)

             PRIMARY KEY ,

16

使用连接服务器,这是一十个 非常好理解的测试方式,在我的环境里,给你发现,在辅助副本上要取到变化的数据,共要要900ms都都能不能保证,900ms以下,都没有保证,甚至在3000ms以下,没跳出过一次能同步的情况。

    @provider = N'SQLNCLI', @datasrc = N'192.168.3000.201';

10

9

20

CREATE TABLE tb_alwayson

24

go

EXEC sp_addlinkedsrvlogin 'Secondary ', 'false ', NULL, 'sa', 'sqlcn.com'

《SQL Server 2012实施与管理实战指南》中指AlwaysON同步过程如下:

1

Alwayson一十个 同步模式,同步和异步,即然是同步,理所当然的我认为他是实时的,好多好多 我配置了只读路由,来使用这一功能。

EXEC sp_addlinkedserver @server = N'Secondary', @srvproduct = N'',

没有这一同步模式到底是为社 个同步呢?

答案是可是的:它还没有保证事务日志是同步的,也可是还没有保证不丢失数据,但没有保证数据变化没有延时,这原因辅助副本在接收主副本传来的Trans log时,首先将其缓到本地Log Cache,接着强制硬化到本地Ldf,怎么能让随即向主副本告知给你commit了,但注意,此时的硬化到本地ldf何必 本地数据原因变化,这原因辅助副本将trans log硬化到本地的并肩,它是使用一十个 异步守护进程去redo那先 trans log产生的Page变化到Data文件的,这也就决定了这一Redo的操作不原因比硬化日志早的,好多好多 数据的延时可是肯定的了。

另外,微软你敢在官方联机文档与各种技术大会上把同步模式非数据实时同步提一下吗?

3

8

      name VARCHAR(3000)

SQL Server 2012 推出的最重要的功能之一Alwayson,是一十个 集时候Cluster和Mirror于一体的新功能,即防止了Cluster依赖共享存储的问题报告 ,又防止了镜像没有实时读以及转移后连接串没有再加转移IP的问题报告 ,看起来的确很实用。

FROM    Secondary.DemoDB.dbo.tb_alwayson

这可是同步模式,给你没有其他点儿防备

      id INT IDENTITY

11

怎么能让Alwayson多副本的功能为实现读写分离提供了原因,试想一下,当主副本压力比较大的时候,不是还没有将读操作引向辅助副本呢?答案一般来讲是肯定的,请注意,是一般!

    )

        ( name )

17

实验如下:

事实原因很清楚了,同步的原理决定了数据的延时,想用AlwaysON做读写分离的他们 们,考虑好你所能容忍的延时时间吧!

13

    (

INSERT  INTO tb_alwayson

FROM    tb_alwayson

15

21

原文:

USE DemoDB

6