利用日誌傳送來實現數據庫的可用性

這不是一個新技術，SQL SERVER2000時就已經有了，2005中沒有什麼太大的改進，，仍是由三項操做組成：

1．  在主服務器中備份事務日誌

2．  而後將備份的事務日誌文件複製到輔助服務器中

3．  在輔助服務器中還原日誌備份

 

你們看到了這個過程仍是很簡單的，也就是在實現的應用中，對你所正在使用聽數據庫進行一個事務日誌備份。備份成功後，複製到輔助服務器，這個過程不該該是管理員手動執行，而應該是經過調度來實現。而後再作一個調度，在輔助服務器上進行還原。但日誌傳送到此就結束了，它並不會由於主要服務器故障而實現自動轉移，這是實現不了的，這個轉移工做已經要由手動來實現。這點和複製是同樣的。若是是經過應用程序來鏈接的話，還要改源代碼來實現轉移。這和羣集和鏡像是不同的。

 

日誌傳送所使用的角色：

主服務器和數據庫  （生產用服務器及所使用到的數據庫）

輔助服務器和數據庫  （用於存放備份的服務器及相應數據庫）

監視服務器     用於監視主要服務器和輔助服務器的通信，以及主服務器的運行狀態，

               應該是一個專門的服務器，那若是機器不夠能夠和輔助服務器在一塊兒。

               能夠監視主服務器是否作了備份，這個備份是否複製，輔助服務器什麼候還原等等，那麼這個地方，監視到出現問題怎麼辦，能夠給管理員發郵件以通知管理員。這要結合做業來實現。

 

 

主服務器和輔助服務器的關係：能夠不是一：一的關係，能夠多個主要服務器對應一個輔助服務器，用於存放多個主要服務器上的備份，以節約硬件資源

 

這三個角色如何進行工做的，所有是經過SQL Server AGET來實現的，因此必定要確保在全部角色上都要運行代理服務，分別執行如下做業：

主要服務器： 備份做業

輔助服務器： 複製做業，還原做業

監視服務器：警報做業

但這一系列的做業，不須要咱們一一建立，只要咱們配置好日誌傳送以後，系統會自動建立。固然前提是數據庫恢復模型應該是徹底或是大容量日誌

 

下面咱們就來看一下具體的實施步驟：

1．  肯定主服務器，輔助服務器和監視服務器

2．  爲事務日誌備份建立文件共享，是好是一個文件服務器（咱們就在主要服務器上）

3．  制定主數據庫的備份計劃

4．  能夠爲主服務器配置一個或是多個輔助服務器，注意：輔助服務器上數據庫不能寫，可是能夠查詢，

5．  配置一個監視服務器，有兩種方法，可使用存儲過程，也可使用SSMS

 

有了上面的理論介紹，下面就能夠動手了：

咱們的目的很明確就是

配置日誌傳送

監視日誌傳送

實現手動的轉移到輔助服務器

清除日誌傳送

 

步驟1：建立共享文件夾用於存放相關文件

         咱們在SERVER1上建立兩個共享文件夾,在 server2上建立一個共享文件夾，如上圖所示：

其中  primarydata\logs 用於存放主服務器備份文件的。主服務器代理用戶必須是域用戶。

      Secondarydata\logs 系統會將 PRIMARY\logs中的日誌複製到此供輔助服務器使用。

      Databaseback   用於存放生產數據庫的副本

 

步驟2： 備份主服務器上的數據庫，注意一個數據庫只能有一個日誌傳送

         咱們以 dufei 數據庫爲例：輔助服務器上不能有同名數據庫。

        backup database dufei to disk='c:\databasebackup\dufei.bak'

這個文件夾是主服務器上的一個共享文件夾

咱們爲了測試方便，咱們在此建立一個表，並插入一條記錄：

 

USE DUFEI

GO

CREATE TABLE YG

(

ID CHAR(4),

UNAME VARCHAR(10),

SEX CHAR(2)

)

INSERT INTO YG VALUES ('0001','嶽雷','男')

GO

BACKUP LOG DUFEI TO DISK='C:\DATABASEBACKUP\DUFEI.BAK'

GO

步驟3：  開始在主服務器上配置日誌傳送

下面是添加輔助服務器：

咱們這裏選擇第二種初始化輔助數據庫的方法：

但這個時候肯定鍵是不能用的，是由於咱們的操做尚未結束。咱們還要複製日誌文件到SECONDARYDATA\logs文件夾下。

下面的操做就是指定還原事務日誌的模式：

有兩種模式，這兩種模式差異是很大的。

 

到此時三步就已經完成了。  備份----複製----還原。

 

最後咱們再來指定監視服務器。

到這裏爲止，日誌傳送就配置結束了：點擊肯定

測試：到SERVER2上能夠看到DUFEI數據庫已經建立成功了，而且嶽雷這條記錄也出如今輔助數據庫中。

而且在SERVER2的共享文件夾中能夠看到相應的日誌文件也複製過來了。

 

與複製的目的是同樣的，結果也相同，都不能實現自動的轉移，但事務複製要求參與的表必需要有主鍵，而日誌傳送不須要。

 

日誌文件應該是兩分鐘複製一次，但咱們也沒有必要每次都打開文件夾來查看，咱們能夠利用監視功能來監視服務器的運行情況。並定義一個警報來對你的日誌傳送進行監控，若是發生了故障，則經過操做員。但默認狀況下，警報確定是用不了的，咱們要設置一下，如：

咱們在監視服務器上：會發生自動多出兩個警報

若是但願這兩個警報能正常工做，咱們要設置一下，過程以下：

1．  定義操做員：

2．  配置警報：

此時，再啓用網卡，則一切又OK了！

1．  查看日誌傳送情況Z

在監視服務器上：

 

能夠測試一下，咱們在主服務器上建立一個表，或是更新一條記錄，會很快的反映到輔助服務器。

最近咱們來看一下如何手動的實現故障轉移

1．  咱們手動中止主要服務器上的SQL SERVER服務，刪除相應的DUFEI數據庫所對應的MDF文件  再次啓動服務器，會發現DUFEI數據庫已經不能用了。

2．  在輔助服務器上，禁用代理，運行命令

此時，輔助服務器上的DUFEI數據庫就再也不是隻讀了。！

但要注意的是：監視服務器上的代理做業也應該禁用，否則會不停的發出警報。

 

好，咱們的實驗就到此結束了！

 

最後能夠清除日誌傳送：

關於日誌傳送就介紹到此！