從0開始搭建SQL Server AlwaysOn 第三篇（配置AlwaysOn）
從0開始搭建SQL Server AlwaysOn 第三篇（配置AlwaysOn）
第一篇
http://www.rzrgm.cn/lyhabc/p/4678330.html
第二篇
http://www.rzrgm.cn/lyhabc/p/4682028.html
第三篇
http://www.rzrgm.cn/lyhabc/p/4682986.html
第四篇
http://www.rzrgm.cn/lyhabc/p/6136227.html
搭建非域AlwaysOn win2016+SQL2016
http://www.rzrgm.cn/lyhabc/p/6498712.html
SQL Server AG集群啟動不起來的臨時自救大招
http://www.rzrgm.cn/lyhabc/p/6953255.html
這一篇是從0開始搭建SQL Server AlwaysOn 的第三篇，這一篇才真正開始搭建AlwaysOn，前兩篇是為搭建AlwaysOn 做準備的
步驟
這一篇依然使用step by step的方式介紹怎麼搭建AlwaysOn
請先使用本地用戶Administrator登錄這兩個集群節(jié)點并執(zhí)行下面的操作，先不要用域用戶DCADMIN登錄
1、兩個集群節(jié)點都需先安裝.NET Framework 3.5(在Windows Server 2012 R2中使用添加功能來安裝)。
2、各個集群節(jié)點本地都要準備好相關軟件，在各個節(jié)點上獨立安裝SQL Server 2012（不能使用群集方式安裝），保證各個節(jié)點中使用相同的安裝目錄結構和排序規(guī)則！
選擇全新SQL Server獨立安裝，不要選擇新的SQL Server故障轉移集群安裝
至于安裝過程，默認下一步下一步就可以了，跟單機安裝SQL Server沒有區(qū)別，這里就忽略安裝過程了
注意：因為本人的安裝包已經(jīng)自帶SP1補丁包，為了后續(xù)避免踩坑，如果沒有安裝SP1或以上補丁包的，請先安裝
注意：如果一開始使用域用戶DCADMIN來登錄集群節(jié)點機器，并安裝SQL Server的時候會遇到一個坑，SQL Server安裝程序會連接故障轉移集群，但是實際上單機安裝SQL Server根本不需要連接故障轉移集群
本人排查了很久都找不到原因，為什么SQL Server安裝程序會連接故障轉移集群，下面是SQL Server安裝日志
如果一開始就使用集群節(jié)點本地用戶Administrator登錄來安裝SQL Server就不會踩到這個坑
3、注銷集群節(jié)點計算機，然后使用域用戶DCADMIN登錄，然后設置SQL Server的啟動賬戶為域用戶DCADMIN
打開服務管理器，先修改SQL代理的啟動賬戶為域用戶DCADMIN，然后再修改SQL 引擎的啟動賬戶為域用戶DCADMIN
點擊“位置”，修改查找位置，選中abc.com
點擊“高級”
點擊“立即查找”，選中DCADMIN
點擊“確定”
輸入域用戶DCADMIN的密碼
重啟一下SQL代理服務
重啟之后可以看到登錄用戶為DCADMIN@abc.com
同樣，SQL引擎服務也需要同樣的設置
這樣，SQL引擎服務和SQL代理服務都用域用戶DCADMIN啟動
另一個集群節(jié)點的SQL Server也需要做同樣的操作
注意：在集群節(jié)點脫離域之后，SQL引擎服務和SQL代理服務都要用本地服務帳號來啟動，不能再用域用戶來啟動
4、將DCADMIN域用戶加入到兩個集群節(jié)點的SQL Server登錄用戶中，服務器角色選擇sysadmin
先用sa登錄SQL Server
添加登錄用戶，跟SQL 服務添加啟動賬戶的步驟一樣，將DCADMIN域用戶添加為登錄用戶
給予sysadmin權限
兩個集群節(jié)點都可以用DCADMIN域用戶來登錄SQL Server
5、回到SQL Server配置管理器，啟用AlwaysOn可用性組
注意：集群節(jié)點一定要能進行通信，如果集群節(jié)點之間斷開通信，那么啟用AlwaysOn的時候會報錯
重啟SQL Server
如果AlwaysOn啟用成功，在服務器屬性里可以看到啟用HADR為True
6、在其中一個集群節(jié)點的SQL Server中驗證各節(jié)點的投票數(shù) ，在其中一個集群節(jié)點的SQL Server上執(zhí)行
使用下面SQL語句
SELECT * FROM sys.dm_hadr_cluster_members;
SELECT * FROM SYS.[dm_hadr_cluster]
7、再次確保各節(jié)點已經(jīng)關閉防火墻，如果防火墻沒有關閉，那么在創(chuàng)建可用性組的時候會彈出下面錯誤
無法將數(shù)據(jù)庫“test”聯(lián)接到可用性副本“xxx”的可用性組“xx”
針對主副本的連接未處于活動狀態(tài)。無法處理該命令（錯誤：35250）
8、我們使用自行初始化數(shù)據(jù)庫的方式，所以這一步需要新建一個測試庫和測試表并插入一些測試數(shù)據(jù)（這些動作就不演示了），然后對數(shù)據(jù)庫做一個完整備份 和 日志備份
然后把完整備份文件和日志備份文件搬到WIN-5PMSDHUI0KQ機器上依次進行還原，完整備份-》還原完整備份-》日志備份-》還原日志備份
腳本
--在win-7107jjj2bcc上執(zhí)行 CREATE DATABASE [test] USE [test] CREATE TABLE [test1]([id] INT,[name] VARCHAR(100)) INSERT INTO [test1] SELECT 1,'test'
--在win-7107jjj2bcc上執(zhí)行 DECLARE @CurrentTime VARCHAR(50), @FileName VARCHAR(200) SET @CurrentTime = REPLACE(REPLACE(REPLACE(CONVERT(VARCHAR, GETDATE(), 120 ),'-','_'),' ','_'),':','') --(test 數(shù)據(jù)庫完整備份) SET @FileName = 'c:\DBBackup\test_FullBackup_' + @CurrentTime+'.bak' BACKUP DATABASE [test] TO DISK=@FileName WITH FORMAT ,COMPRESSION --(test 數(shù)據(jù)庫日志備份) SET @FileName = 'c:\DBBackup\test_logBackup_' + @CurrentTime+'.bak' BACKUP log [test] TO DISK=@FileName WITH FORMAT ,COMPRESSION
--在WIN-5PMSDHUI0KQ上執(zhí)行 USE [master] RESTORE DATABASE [test] FROM DISK = N'C:\DBBackup\test_FullBackup_2015_07_30_093949.bak' WITH FILE = 1, MOVE N'test' TO N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\test.mdf', MOVE N'test_log' TO N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\test_log.ldf', NOUNLOAD,NORECOVERY, REPLACE, STATS = 5 GO --注意一定要用NORECOVERY來還原備份 USE [master] RESTORE DATABASE [test] FROM DISK = N'C:\DBBackup\test_logBackup_2015_07_30_105949.bak' WITH FILE = 1, NOUNLOAD,NORECOVERY, REPLACE, STATS = 5 GO
自行初始化數(shù)據(jù)庫的好處是：如果我們的輔助副本是跨機房的我們都可以控制初始化的時間，也就是備份和還原的時間，不需要SQL Server來幫我們備份還原數(shù)據(jù)庫
在WIN-5PMSDHUI0KQ上還原日志備份之后的樣子
9、在“Alwayson高可用性”節(jié)點上右鍵選擇“新建可用性組向導
這一步開始在任意一個AlwaysOn節(jié)點進行操作，使用域用戶DCADMIN登錄Windows！！
注意：加入到AlwaysOn可用性組的數(shù)據(jù)庫必須符合下面要求
（1）數(shù)據(jù)庫的恢復模式必須是“完整”恢復模式
（2）數(shù)據(jù)庫已進行了一次完整備份
（3）需要是用戶庫，系統(tǒng)庫不能加入可用性組
（4）數(shù)據(jù)庫可以讀寫，只讀庫不能加入到可用性組
（5）數(shù)據(jù)庫處于多用戶模式
（6）數(shù)據(jù)庫沒有使用AUTO_CLOSE
（7）不屬于任何其他的可用性組
（8）數(shù)據(jù)庫沒有配置數(shù)據(jù)庫鏡像
一個可用性組最大支持100個數(shù)據(jù)庫
10、點擊“下一步”，輸入一個從未使用過的高可用性組名稱 testAG
11、點擊下一步，選擇要添加的數(shù)據(jù)庫
12、點擊“下一步”，使用添加副本來將其他節(jié)點添加到可用性組中，并選擇自動故障轉移節(jié)點和同步提交節(jié)點，因為我們只有兩個節(jié)點
我們將輔助副本設置為可讀，能夠自動故障轉移，同步提交模式
13、點擊“端點”tab頁面設置端點
注意：端點URL使用IP的方式，不要用FQDN長名的方式，因為服務器通常會有兩個網(wǎng)卡，一個public網(wǎng)卡，一個private網(wǎng)卡，端點建議使用private網(wǎng)卡地址
這樣在端點直接傳送的數(shù)據(jù)就會經(jīng)由private網(wǎng)卡來傳送，使用TCP://test.abc.com:5022 這種FQDN長名的方式是不能保證端點數(shù)據(jù)通過private網(wǎng)卡來傳送
SQL Server服務賬戶使用域用戶DCADMIN來進行身份驗證，避免使用證書的方式
14、“備份首選項”和“偵聽器”不需要設置，保持默認就行，可用性偵聽器我們后面再添加，可以直接點擊“下一步”
點擊“是”
15、選擇初始數(shù)據(jù)同步，這里選擇“僅聯(lián)接”模式
16、點擊“下一步”來驗證配置，對應偵聽器配置警告可以忽略，后期來添加偵聽器
因為使用的是“僅聯(lián)接”數(shù)據(jù)庫初始化方式，驗證跳過像可用磁盤空間這樣的檢查
17、點擊“下一步”來檢查并確認之前的配置信息，若無誤，點擊“完成”。另外，此處也可保存建立可用性組腳本，以便分步診斷故障之用。
18、所有摘要均成功完成，顯示綠色對勾。如果出現(xiàn)黃色警告，則需進行進一步判斷是否成功。若出現(xiàn)紅色錯誤，表示AG創(chuàng)建不成功
注意：如果大家使用奇數(shù)集群節(jié)點，并且仲裁配置使用的是節(jié)點多數(shù)，那么在創(chuàng)建可用性組完畢的時候，WSFC仲裁投票配置會顯示警告
點擊警告鏈接會彈出下面的對話框，這個警告其實可以不用理會
19、查看服務器和數(shù)據(jù)庫的變化
主副本
數(shù)據(jù)庫變?yōu)橐淹?/p>
輔助副本
輔助副本這時候是可讀的，在主副本上對test1表做的更改都能同步到輔助副本上的test1表
再看一下故障轉移集群管理器
可用性組變?yōu)橐粋€集群角色
點擊顯示面板可以顯示可用性面板
20、在創(chuàng)建可用性組后，在“可用性組偵聽器”上右鍵添加偵聽器來創(chuàng)建偵聽器，選擇靜態(tài)IP的網(wǎng)絡模式（盡量不要選擇DHCP網(wǎng)絡模式），
輸入一個從未使用過的名稱（該名稱將被用來創(chuàng)建網(wǎng)絡名稱資源）和訪問端口
點擊確定
創(chuàng)建成功
在域控的DNS管理器上會注冊一條A記錄
在AD里的Computers容器里會添加一個故障轉移集群虛擬網(wǎng)絡名稱賬戶
在故障轉移集群管理器里的角色節(jié)點，可以看到客戶端訪問名稱和IP地址，客戶端通過這個訪問名稱進行訪問數(shù)據(jù)庫
使用偵聽器名稱進行登錄SQL Server
當然也可以用listener IP來連接SQL Server
在輔助副本添加登錄用戶，讓主副本上的登錄用戶也可以讀取輔助副本數(shù)據(jù)
步驟1：查看主庫上該賬號的sid [test]為庫名
SELECT * FROM [test]..sysusers
比如：dalogin 0x99AD266AFD26F841B3E49EF9633B0D4B
步驟2：在副本數(shù)據(jù)庫上創(chuàng)建對應賬號，其中 sid對應的值是主庫上所查到的sid的值
CREATE LOGIN [dalogin] WITH PASSWORD=N'xxxxxxx',
SID =0x99AD266AFD26F841B3E49EF9633B0D4B, DEFAULT_DATABASE=[test],
CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
報表賬號設置
在主副本中，執(zhí)行：
use 庫名
go
grant exec to 報表賬號連接所用的用戶 或grant exec on 存儲過程 to 報表賬號連接所用的用戶
可用性組的基本管理
注意：盡量用SSMS的UI或TSQL語句來操作可用性組，不要用故障轉移集群管理器來操作
故障轉移
首先使用 偵聽器名稱來登錄SQL Server，查看當前是在主副本是在哪個機器
手動故障轉移
選中testAG這個可用性組，右鍵-》故障轉移
點擊“下一步”
點擊“下一步”
連接到 WIN-5PMSDHUIOKQ這臺輔助副本機器
點擊“完成”
開始進行故障轉移
再一次執(zhí)行查詢
已經(jīng)故障轉移到WIN-5PMSDHUIOKQ這臺機
查看一下testAG可用性組的屬性
執(zhí)行下面SQL語句，將WIN-7107JJJ2BCC機器設置為可讀副本
USE [master] GO ALTER AVAILABILITY GROUP [testAG] MODIFY REPLICA ON N'WIN-7107JJJ2BCC' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)) GO
執(zhí)行下面SQL語句測試一下
在當前主副本執(zhí)行
insert into test1 select 3, 'test3'
可以看到數(shù)據(jù)已經(jīng)同步過來WIN-7107JJJ2BCC機器，并且數(shù)據(jù)庫可讀
可讀輔助副本是只讀的，如果要對它進行數(shù)據(jù)更改則會報錯
print 'servername: '+@@SERVERNAME insert into [test].[dbo].[test1] select 4, 'test4'
AlwaysOn集群相關DMV視圖
--通過這兩個視圖可以查詢AlwaysOn延遲 SELECT b.replica_server_name , a.* FROM sys.dm_hadr_database_replica_states a INNER JOIN sys.availability_replicas b ON a.replica_id = b.replica_id --可用性組所在Windows故障轉移集群 SELECT * FROM sys.dm_hadr_cluster; SELECT * FROM sys.dm_hadr_cluster_members ; SELECT * FROM sys.dm_hadr_cluster_networks; SELECT * FROM sys.dm_hadr_instance_node_map; SELECT * FROM sys.dm_hadr_name_id_map --可用性組 SELECT * FROM sys.availability_groups; SELECT * FROM sys.availability_groups_cluster; SELECT * FROM sys.dm_hadr_availability_group_states ; SELECT * FROM sys.dm_hadr_automatic_seeding SELECT * FROM sys.dm_hadr_physical_seeding_stats --可用性副本 SELECT * FROM sys.availability_replicas; SELECT * FROM sys.[availability_read_only_routing_lists] SELECT * FROM sys.dm_hadr_availability_replica_cluster_nodes; SELECT * FROM sys.[dm_hadr_availability_replica_cluster_states] SELECT * FROM sys.[dm_hadr_availability_replica_states] --可用性數(shù)據(jù)庫 SELECT * FROM sys.availability_databases_cluster; SELECT * FROM sys.dm_hadr_database_replica_cluster_states; --自動修復頁面時間，取決于secondary輔助副本需要多久時間追上LSN SELECT * FROM sys.[dm_hadr_auto_page_repair] --查看是否有發(fā)生自動修復作業(yè) SELECT * FROM sys.[dm_hadr_database_replica_states] --可用性組listener SELECT * FROM sys.availability_group_listener_ip_addresses; SELECT * FROM sys.availability_group_listeners; SELECT * FROM sys.dm_tcp_listener_states; --添加只讀路由列表 ALTER AVAILABILITY GROUP [agtest2] MODIFY REPLICA ON N'WIN-5PMSDHUI0KQ' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS= READ_ONLY)); ALTER AVAILABILITY GROUP [agtest2] modify REPLICA ON N'WIN-5PMSDHUI0KQ' WITH (SECONDARY_ROLE(READ_ONLY_ROUTING_URL=N'TCP://192.168.66.157:1433')) ALTER AVAILABILITY GROUP [agtest2] MODIFY REPLICA ON N'WIN-4AE61RVA6UV' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS= READ_ONLY)); ALTER AVAILABILITY GROUP [agtest2] modify REPLICA ON N'WIN-4AE61RVA6UV' WITH (SECONDARY_ROLE(READ_ONLY_ROUTING_URL=N'TCP://192.168.66.158:1433'))
總結
AlwaysOn搭建步驟就介紹到這里，希望大家跟著我來體驗一下AlwaysOn的強大
同樣的，添加一個輔助副本的操作： 加域、加入故障轉移集群、更改仲裁配置、添加輔助副本
按照文章的來操作相信添加輔助副本也不難
還有一個就是遇到問題多看看SQL Server errorlog和WSFC的事件日志
對于更多信息可以參考《SQLSERVER2012實施與管理實戰(zhàn)指南》書本
地址： http://product.dangdang.com/1419881008.html
相關文章
http://www.rzrgm.cn/stswordman/p/3821538.html
http://www.rzrgm.cn/stswordman/p/3850570.html
http://www.rzrgm.cn/stswordman/p/3936584.html
http://www.rzrgm.cn/stswordman/p/3252549.html#3229105
http://blogs.msdn.com/b/psssql/archive/2012/09/07/how-it-works-sql-server-alwayson-lease-timeout.aspx
http://blogs.msdn.com/b/alwaysonpro/archive/2014/11/26/diagnose-unexpected-failover-or-availability-group-in-resolving-state.aspx
https://msdn.microsoft.com/zh-cn/library/ff878308%28v=sql.120%29.aspx?f=255&MSPPError=-2147217396
http://www.bubuko.com/infodetail-930336.html 創(chuàng)建了一個弱事件，但它位于錯誤對象上 下載補丁解決 (https://www.microsoft.com/en-us/download/details.aspx?id=36468)
http://blogs.msdn.com/b/alwaysonpro/archive/2013/10/30/errors-while-trying-to-create-an-availability-group-listener.aspx 19471錯誤
創(chuàng)建偵聽器錯誤19471，19476 問題
http://blogs.msdn.com/b/alwaysonpro/archive/2013/10/30/errors-while-trying-to-create-an-availability-group-listener.aspx
http://blogs.msdn.com/b/alwaysonpro/archive/2014/03/25/create-listener-fails-with-message-the-wsfc-cluster-could-not-bring-the-network-name-resource-online.aspx
如有不對的地方，歡迎大家拍磚o(∩_∩)o
2015-11-13補充
兩個節(jié)點的AlwaysOn ，用共享文件夾做見證磁盤
當自動故障切換的時候，有時候出現(xiàn)，輔助副本正在解析的現(xiàn)象，之前以為是仲裁丟失（WSFC與文件共享見證失去聯(lián)系），導致WSFC掛掉，后來發(fā)現(xiàn)原因是WSFC控制面板里的角色屬性里面的最大故障數(shù)的問題而導致的
推薦將指定時段內的最大故障數(shù)設置為10
LogDate ProcessInfo Text 2015-11-13 15:28:56.140 spid46s State information for database 'test' - Hardended Lsn: '(36:424:1)' Commit LSN: '(36:408:1)' Commit Time: 'Nov 13 2015 3:26PM' 2015-11-13 15:28:56.140 spid46s The availability group database "test" is changing roles from "SECONDARY" to "RESOLVING" because the mirroring session or availability group failed over due to role synchronization. This is an informational message only. No user action is required. 2015-11-13 15:28:56.140 spid48s AlwaysOn Availability Groups connection with primary database terminated for secondary database 'test' on the availability replica 'NODE1' with Replica ID: {40bfe7bb-407e-46a3-911b-147a468abedf}. This is an informational message only. No user action is required. ---------------------------------------------------------------- 2015-11-13 15:28:56.140 spid29s The state of the local availability replica in availability group 'testAG' has changed from 'SECONDARY_NORMAL' to 'RESOLVING_NORMAL'. The state changed because the availability group state has changed in Windows Server Failover Clustering (WSFC). For more information, see the SQL Server error log, Windows Server Failover Clustering (WSFC) management console, or WSFC log. 2015-11-13 15:28:56.140 spid29s AlwaysOn: The local replica of availability group 'testAG' is going offline because the corresponding resource in the Windows Server Failover Clustering (WSFC) cluster is no longer online. This is an informational message only. No user action is required. ----------------------------------------------------------------- 2015-11-13 15:26:46.160 spid48s The recovery LSN (36:336:1) was identified for the database with ID 7. This is an informational message only. No user action is required. 2015-11-13 15:26:46.160 spid48s Error: 35285, Severity: 16, State: 1. 2015-11-13 15:26:46.160 spid48s AlwaysOn Availability Groups connection with primary database established for secondary database 'test' on the availability replica 'NODE1' with Replica ID: {40bfe7bb-407e-46a3-911b-147a468abedf}. This is an informational message only. No user action is required. 2015-11-13 15:26:46.150 spid48s The recovery LSN (36:336:1) was identified for the database with ID 7. This is an informational message only. No user action is required. 2015-11-13 15:26:46.150 spid48s Error: 35285, Severity: 16, State: 1. 2015-11-13 15:26:46.140 spid48s AlwaysOn Availability Groups connection with primary database established for secondary database 'test' on the availability replica 'NODE1' with Replica ID: {40bfe7bb-407e-46a3-911b-147a468abedf}. This is an informational message only. No user action is required. 2015-11-13 15:26:42.610 spid46s A connection for availability group 'testAG' from availability replica 'NODE2' with id [4F4BAEC0-1FB9-4CB3-829A-85C35D8A06D4] to 'NODE1' with id [40BFE7BB-407E-46A3-911B-147A468ABEDF] has been successfully established. This is an informational message only. No user action is required. 2015-11-13 15:26:42.110 spid46s State information for database 'test' - Hardended Lsn: '(36:336:1)' Commit LSN: '(36:320:21)' Commit Time: 'Nov 13 2015 3:13PM' 2015-11-13 15:26:42.110 spid46s The availability group database "test" is changing roles from "RESOLVING" to "SECONDARY" because the mirroring session or availability group failed over due to role synchronization. This is an informational message only. No user action is required. 2015-11-13 15:26:42.080 spid29s The state of the local availability replica in availability group 'testAG' has changed from 'RESOLVING_NORMAL' to 'SECONDARY_NORMAL'. The state changed because the availability group state has changed in Windows Server Failover Clustering (WSFC). For more information, see the SQL Server error log, Windows Server Failover Clustering (WSFC) management console, or WSFC log. 2015-11-13 15:15:53.960 spid43s State information for database 'test' - Hardended Lsn: '(36:336:1)' Commit LSN: '(36:320:21)' Commit Time: 'Nov 13 2015 3:13PM' 2015-11-13 15:15:53.960 spid43s The availability group database "test" is changing roles from "SECONDARY" to "RESOLVING" because the mirroring session or availability group failed over due to role synchronization. This is an informational message only. No user action is required. 2015-11-13 15:15:53.950 spid30s AlwaysOn Availability Groups connection with primary database terminated for secondary database 'test' on the availability replica 'NODE1' with Replica ID: {40bfe7bb-407e-46a3-911b-147a468abedf}. This is an informational message only. No user action is required. 2015-11-13 15:15:53.950 spid29s The state of the local availability replica in availability group 'testAG' has changed from 'SECONDARY_NORMAL' to 'RESOLVING_NORMAL'. The state changed because the availability group state has changed in Windows Server Failover Clustering (WSFC). For more information, see the SQL Server error log, Windows Server Failover Clustering (WSFC) management console, or WSFC log. 2015-11-13 15:15:53.950 spid29s AlwaysOn: The local replica of availability group 'testAG' is going offline because the corresponding resource in the Windows Server Failover Clustering (WSFC) cluster is no longer online. This is an informational message only. No user action is required. 2015-11-13 15:14:47.610 spid23s The recovery LSN (36:328:2) was identified for the database with ID 7. This is an informational message only. No user action is required. 2015-11-13 15:14:47.610 spid23s Error: 35285, Severity: 16, State: 1. 2015-11-13 15:14:47.600 spid23s AlwaysOn Availability Groups connection with primary database established for secondary database 'test' on the availability replica 'NODE1' with Replica ID: {40bfe7bb-407e-46a3-911b-147a468abedf}. This is an informational message only. No user action is required. 2015-11-13 15:14:47.600 spid30s 1 transactions rolled forward in database 'test' (7:0). This is an informational message only. No user action is required. 2015-11-13 15:14:47.600 spid30s The recovery LSN (36:328:2) was identified for the database with ID 7. This is an informational message only. No user action is required. 2015-11-13 15:14:47.600 spid30s Error: 35285, Severity: 16, State: 1. 2015-11-13 15:14:47.590 spid30s AlwaysOn Availability Groups connection with primary database established for secondary database 'test' on the availability replica 'NODE1' with Replica ID: {40bfe7bb-407e-46a3-911b-147a468abedf}. This is an informational message only. No user action is required. 2015-11-13 15:14:47.550 spid30s Starting up database 'test'. 2015-11-13 15:14:47.550 spid30s State information for database 'test' - Hardended Lsn: '(36:328:1)' Commit LSN: '(0:0:0)' Commit Time: 'Jan 1 1900 12:00AM'
2015-12-9補充
卸載集群
1、先逐個逐出節(jié)點
2、銷毀集群，集群最后一個節(jié)點不能逐出只能銷毀集群，有兩種方法，1用命令 2在界面上右鍵-》銷毀集群
方法一：集群node（隨便一個集群node）上執(zhí)行下面命令，不能在DC上執(zhí)行，因為DC沒有安裝故障轉移集群，sqltestdemo1為集群名，方法一刪除得徹底一點
Get-Cluster sqltestdemo1 | Remove-Cluster -Force -CleanupAD
方法二：集群-》更多操作-》銷毀集群
3、銷毀集群后在每個集群上的powershell里運行下面命令，以清除一些垃圾
Clear-ClusterNode
4、在域控的AD用戶和計算機界面里面把集群虛擬名稱刪除掉
5、重新啟用和禁用alwayson，在alwayson的各個節(jié)點上都要操作一遍
刪除可用性組
1、刪除輔助副本
USE [master] GO ALTER AVAILABILITY GROUP [HAGroup01] REMOVE REPLICA ON N'SQLSVR2'; GO
2、刪除可用性數(shù)據(jù)庫
USE [master] GO ALTER AVAILABILITY GROUP [HAGroup01] REMOVE DATABASE [SQLDB02]; GO
3、刪除偵聽器
USE [master] GO ALTER AVAILABILITY GROUP [HAGroup01] REMOVE LISTENER N'SQLAG01'; GO
4、刪除可用性組
USE [master] GO DROP AVAILABILITY GROUP [HAGroup01]; GO
5、在域控的AD用戶和計算機界面里面把偵聽器虛擬名稱刪除掉
alwayson注意問題
http://www.rzrgm.cn/lyhabc/articles/5310781.html
關于AlwaysOn備份
msdn上和《SQL Server2012實施與管理實戰(zhàn)指南》上都沒有說到主副本所支持的備份類型
經(jīng)過測試，主副本跟單實例的SQL Server一樣，完整備份、差異備份、日志備份都支持
輔助副本只支持copy-only的完整備份、日志備份，不支持差異備份
故障切換判斷條件
第一步
lookalive 5秒/次 telnet 1433端口 超時30秒
第二步
isalive 60秒/次 sp_server_diagnoist存儲過程 超時60秒 超時后再執(zhí)行3次以防誤判，大概5分鐘開始進行切換
SQL Server 2012引入了AlwaysOn和sp_server_diagnoist存儲過程，比select @@servername判斷更準確
防止sqlserver壓力大導致的誤判
《SQL Server2012實施和管理實戰(zhàn)指南》 P42 P50 P53
副本之間 10秒/次 相互ping，如果不通，比如輔助副本不通，會顯示為disconnect，會話超時
AlwaysOn注意問題：http://www.rzrgm.cn/lyhabc/articles/5310781.html
關于仲裁：http://www.tech-coffee.net/understand-failover-cluster-quorum/
浙公網(wǎng)安備 33010602011771號