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