上個月月底的時候因為要搬遷機房，需要將一個數據信息數據庫先搬到我們的機房，然後將客戶的數據庫
從原來的機房A搬到機房B，原來我們的數據信息庫（DataInfo）是放在機房A的，但是為了以後方便和防止信息洩露
就放到我們的托管機房，這裡叫機房C
在搬遷機房的時候，盡量減少宕機時間，數據不能丟，搬遷機房真是一門學問。。。
雖然這麽忙，但我還是把寫文章的時間騰出來，把干貨分享給大家o(∩_∩)o
因為很多系統都在讀寫機房A的數據信息庫（DataInfo），我在上個月底的時候用備份文件初始化的方式搭建好復制把機房A的
機房A的數據信息庫（DataInfo）新插入的數據實時復制到機房C，先讓一部分系統能讀取機房C的數據信息庫（DataInfo），
等以後搬遷完所有系統之後再統一全部改連接地址
當然這篇文章不是講我這次的搬遷過程，在搭建好復制之後，由於我沒有設置訂閱庫的登錄用戶的權限為只讀，導致前幾天開發那邊
同時把新數據插入到訂閱庫，導致復制失敗（主鍵重復），分發命令積壓（大概26w+條命令未分發），然後一大堆後續工作。。。。。。
復制的坑其實挺多的，因為我們不可能24小時用肉眼盯著復制監視器，所以我們需要一些監控手段，
當遇到復制出錯的時候可以盡快知道然後進行修復
監控考慮的條件：
（1）單個點監控、多個點監控
（2）購買、自己開發
（3）比較實時、不是很實時
（4）數據庫服務器是否負載過高
我這裡只考慮最簡單的一種：單個點的，不需要很實時，負載不高，如果服務器負載過高有可能連郵件也發不出了
然後就考慮到使用SQLSERVER自帶的數據庫郵件來發告警郵件
當然，如果需要同時滿足實時、多個點監控、成本足夠可以考慮購買成熟的解決方案
例如：微軟的System Center 2012 R2
又或者
自己公司開發監控程序，支持短信告警更加及時
