公司核心交易資料庫，使用sql 2012 alwayson的1主4從，有2臺（8.14，8.15）從庫伺服器，已經使用3年多，過保替換，新買的2臺伺服器已經安裝好，一開始方案如下：
伺服器（8.14）替換方案：1， 需提前修改程式連線8.14的配置和dbms，改成8.15伺服器並重啟相關服務
2， 監控幾天未有程式使用8.14資料庫伺服器
3， 凌晨2點—5點，在alwayson集群中刪除8.14伺服器
4， 修改原8.14（1.14）成新ip，修改8.84的ip成（8.14）
5， 配置新的8.14機器加入8.13的故障轉移集群
6， 新8.14還原3個資料庫和日誌
7， 配置新8.14的3個資料庫加入alwayson集群
8， 測試新8.14的可用性
自己想了想，這個機會，可以用dns解決以前程式連ip的故障問題，一旦程式連的8.14伺服器出現故障，連線8.14程式要全部修改重啟，太麻煩，故障一發生，一定是個大事故，想用這個機會用dns解決，到時真的出問題
只需要修改dns解析ip就可以。
後來跟開發和測試溝通， 測試覺得涉及到程式太多，修改起來的確麻煩，開發那邊覺得，公司內網的dns解析穩定性不可靠，乙個開發負責人說他以前的有老東家準備用dns網域名稱來做，後來取消了，不可靠。
這麼多人反對，用dns方案來替換不行。
後來大家討論： 能否用虛ip來解決這個程式修改的問題，這樣以前用8.14，8.15 這樣的ip就不用改任何程式，把這個類似的8.14等ip提成虛ip，因為windows沒有虛ip的說法，就是直接加上乙個ip。
：
測試報告線下測試機：
192.168.60.36（主）
192.168.60.133/60.152/60.247 （備機）
配置sql server alwayson 1主3從
測試刪除節點：
1， 刪除備機60.133的sql server alwayson集群 （1分鐘內）
2， 刪除備機60.133的windows集群 （1分鐘內）
3， 修改60.133的ip
4， 在60.247增加60.133的新ip
5， 其他機器連60.133資料庫正常
測試下來，用虛ip方案是可行了，後來又連續測試了一周，沒有什麼異常。後來和開發測試討論，方案如下：
8.15舊機器替換刪除8.15節點：
1， 刪除備機8.15的sql server alwayson集群 （1分鐘）
2， 刪除備機8.15的windows集群 （1分鐘）
3， 修改8.14的ip （3分鐘）
4， 在8.14增加8.15的新ip （3分鐘）
5， 測試連8.15資料庫是否正常 （10分鐘）
新加節點8.85
提前配置好賬號密碼（已處理），提前幾個小時還原最新的完整資料庫備份（3個），提前半小時備份最新的3個資料庫日誌
1， 新加備機8.85到windows集群 （1分鐘）
2， 還原最新的8.13的3個資料庫日誌 （15分鐘）
3， 配置8.85到sql server alwayson集群 （15分鐘）
4， 刪除8.14的8.15 ip （3分鐘）
5， 在8.85新加8.15 ip （3分鐘）
6， 測試連8.15資料庫是否正常 （10分鐘）
定在週日凌晨的1:00--5:00,這個時間，2臺機器替換下來，花了大約2個小時，替換過程比較順利。
總結：1，以前我們老是說linux的虛ip，在windows中很少去做這個，這次把實機的ip變成乙個可以虛的ip，根據需要在不同的伺服器增加，刪除。達到減少伺服器不可用時間，又能快速解決問題。
2，用虛ip來解決這個伺服器替換，的確是乙個比較省時省力的辦法。
資料庫的髒讀 不可重複讀和虛讀
髒讀dirty reads 當事務讀取還未被提交的資料時，就會發生這種事件。舉例來說 transaction 1 修改了一行資料，然後 transaction 2 在 transaction 1 還未提交修改操作之前讀取了被修改的行。如果 transaction 1 回滾了修改操作，那麼 trans...
vb讀mysql庫亂碼解決的方法
很多vb mysql的朋友可能都會碰到乙個問題,使用中文去access mysql庫的時候,會出現亂碼.如果是向庫里去write,則寫庫語句無法執行,如果是read中文,則取出來的是 有幾個漢字就有幾個 在csdn上搜vb mysql亂碼的文章,筆者沒有看到一篇文章直接說明了詳細解決辦法.或許筆者沒...
資料庫幻讀解決方案
有時候我們會有業務場景去解決資料庫幻讀現象 比如某條記錄的某幾個屬性合起來需要在記錄裡唯一 這個時候我們需要做的是新增乙個校驗欄位對他做唯一約束,值是這幾個欄位的拼接 這裡為什麼用校驗欄位而不用原字段呢？有時候我們在做刪除的時候只做邏輯刪除 這時候唯一約束就好導致失效的記錄讓有效的記錄無法插入,而校...