SQL Server 2012 推出的最重要的功能之一Alwayson，是一個集之前Cluster和Mirror于一體的新功能，即解決了Cluster依賴共享存儲的問題，又解決了鏡像不能實時讀以及轉移后連接串需要添加轉移IP的問題，看起來的確很實用。
而且Alwayson多副本的功能為實現讀寫分離提供了可能，試想一下，當主副本壓力比較大的時候，是否可以將讀操作引向輔助副本呢？答案一般來講是肯定的，請注意，是一般！
Alwayson有兩個同步模式，同步和異步，即然是同步，理所當然的我認為他是實時的，所以我 配置了只讀路由 ，來使用這個功能。
遺憾的是，這個同步并不是數據的實時同步，當主副本數據發生變化時，同步模式下的輔助副本并不能立即取到變化的數據。
實驗如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
EXEC
sp_addlinkedserver @server = N
'Secondary'
, @srvproduct = N
''
,
????
@provider = N
'SQLNCLI'
, @datasrc = N
'192.168.200.201'
;
?
EXEC
sp_addlinkedsrvlogin
'Secondary '
,
'false '
,
NULL
,
'sa'
,
'sqlcn.com'
?
USE DemoDB
go
?
CREATE
TABLE
tb_alwayson
????
(
??????
id
INT
IDENTITY
?????????????
PRIMARY
KEY
,
??????
name
VARCHAR
(200)
????
)
?
INSERT
?
INTO
tb_alwayson
????????
(
name
)
????????
SELECT
?
NEWID()
?
SELECT
?
COUNT
(*)
FROM
???
tb_alwayson
WAITFOR DELAY
'00:00:00.900'
SELECT
?
COUNT
(*)
FROM
???
Secondary.DemoDB.dbo.tb_alwayson
|
使用連接服務器，這是一個非常好理解的測試辦法，在我的環境里，你會發現，在輔助副本上要取到變化的數據，大概要900ms才能保證，900ms以下，都沒法保證，甚至在300ms以下，沒出現過一次能同步的情況。
這就是同步模式，讓你沒有一點點兒防備 。
?
那么這個同步模式到底是怎么個同步呢？
答案是這樣的：它可以保證事務日志是同步的，也就是可以保證不丟失數據，但不能保證數據變化沒有延時，這是由于輔助副本在接收主副本傳來的Trans log時，首先將其緩到本地Log Cache，接著強制硬化到本地Ldf，然后隨即向主副本告知你可以commit了，但注意，此時的硬化到本地ldf并非本地數據已經變化，這是因為輔助副本將trans log硬化到本地的同時，它是使用一個異步進程去redo這些trans log產生的Page變化到Data文件的，這也就決定了這個Redo的操作是不可能比硬化日志早的，所以數據的延時就是肯定的了。
?
《SQL Server 2012實施與管理實戰指南》中指AlwaysON同步過程如下：
任何一個SQL Server里都有個叫Log Writer的線程，當任何一個SQL用戶提交一個數據修改事務時，
它會負責把記錄本次修改的日志信息先記入一段內存中的日志緩沖區，然后再寫入物理日志文件（日志固化）。
所以對于任何一個數據庫，日志文件里都會有所有數據變化的記錄。
對于配置為AlwaysOn主副本的數據庫，SQL Server會為它建立一個叫Log Scanner的工作線程。
這個線程專門負責將日志記錄從日志緩沖區或者日志文件里中讀出，打包成日志塊，發送給各個輔助副本。
由于它的不間斷工作，才使主副本上的數據變化，可以不斷地向輔助副本上傳播。
在
輔助副本上
，同樣會有兩個線程，完成相應的數據更新動作，它們是
固化（Harden）和重做（Redo）
。
固化線程會將主副本Log Scanner所發過來的日志塊寫入輔助副本的磁盤上的日志文件里（這個過程被稱為"固化"）。
而重做線程，則負責從磁盤上讀取日志塊，將日志記錄翻譯成數據修改操作，在輔助副本的數據庫上完成。
當重做線程完成其工作以后，輔助副本上的數據庫就會跟主副本一致了。AlwaysOn就是通過這種機制，保持副本之間的同步。
重做線程每隔固定的時間點，會跟主副本通信，告知它自己的工作進度。主副本就能夠知道兩邊數據的差距有多遠。
這些線程在工作上各自獨立，以達到更高的效率。 Log Scanner負責傳送日志塊，而無須等待Log Writer完成日志固化；輔助副本完成日志固化以后就會發送消息到主副本，告知數據已經傳遞完畢，而無須等待重做完成。 其設計目標，是盡可能地減少AlwaysOn所帶來的額外操作對正常數據庫操作的性能影響。
事實已經很清楚了，同步的原理決定了數據的延時，想用AlwaysON做讀寫分離的朋友們，考慮好你所能容忍的延時時間吧！
另外，微軟你敢在官方聯機文檔與各種技術大會上把同步模式非數據實時同步提一下嗎？
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
