數據庫架構升級清單

Question

不得不升級數據庫模式使安裝新版軟件變得更加棘手。這樣做的最佳做法是什麼？

我正在尋找一個清單或行動項目時間表，如

• 8:30關閉應用程序
• 8:45修改架構
• 9:15安裝新的應用程序
• 9:30重新啓動db

等，顯示如何最大限度地降低風險和停機時間。如

• 打了退堂鼓升級的，如果事情，而在數據庫運行
• 從開發促進測試到生產服務器
出差錯
• 最大限度降低對現有的應用程序
• 「熱」的更新問題

特別感興趣。

Answer 1

我有很多這方面的經驗。我的應用程序是高度迭代的，並且架構變化經常發生。我大約每2到3周做一次產品發佈，每個產品從我的FogBugz列表中清除50到100件產品。我們在過去幾年中所做的每個發佈都需要更改架構以支持新功能。

這樣做的關鍵是在實際製作服務器之前，在測試環境中多次實踐這些更改。

我保留從模板中複製的部署清單文件，然後對每個版本進行大量編輯，使用任何不同尋常的東西。

我有兩個腳本，我在數據庫上運行，一個用於模式更改，一個用於可編程性（過程，視圖等）。更改腳本是手動編寫的，而具有procs的腳本是通過Powershell腳本編寫的。當所有內容都被關閉時（您必須選擇一個讓用戶數量最少的時間）運行更改腳本，並且它是通過手動運行命令，以防萬一出現奇怪現象。我遇到的最常見的問題是添加一個由於重複行而失敗的唯一約束。

在準備集成測試周期時，我會在測試服務器上查看我的清單，就好像該服務器是生產服務器一樣。然後，除此之外，我去獲取生產數據庫的一個實際副本（這是換出離線備份的好時機），並且我在恢復的本地版本上運行腳本（這也很好，因爲它證明了我的最新的備份是健全的）。我在這裏用一塊石頭殺了很多鳥。

所以，這4個數據庫總計：

1. 開發：所有更改必須在更改腳本進行，從未與工作室。
2. 測試：集成測試在這裏發生的生產
3. 複製：最後一刻部署實踐
4. 生產

你真的需要，當你做對生產得到它的權利。退出模式更改非常困難。

就修補程序而言，我只會修補程序，從不修改程序，除非它是一個非常孤立的變化，對於業務至關重要。

Answer 2

我想你已經考慮過斯科特·安布勒的讀物了？ http://www.agiledata.org/essays/databaseRefactoring.html

Answer 3

這是我剛剛在工作中討論的一個話題。主要的問題是，除非你的框架很好地處理了數據庫遷移，例如rails和它們的遷移腳本，那麼這是由你自己決定的。

我們現在的做法有明顯的缺陷，我願意接受其他建議。

1. 有一個模式轉儲與靜態數據，需要在那裏保持最新和版本控制。
2. 每次執行模式更改操作時，ALTER，CREATE等將其轉儲到文件並將其放入版本控制中。
3. 請確保您更新了原始的sql數據庫轉儲。
4. 在推動生活時，確保您或您的腳本將sql文件應用於數據庫。
5. 清理版本控制中舊的sql文件。

這絕不是最佳的，並且不是作爲「備份」數據庫的目的。這只是簡單地讓生活更輕鬆，並讓開發人員保持在同一頁面上。至於自動將sql文件應用到數據庫中，可能有一些很酷的設置可以用capistrano來設置。

Db特定的版本控制將非常棒。有可能是這樣做，如果沒有可能應該有。

Answer 4

而且如果斯科特·安布勒紙磨礪你的食慾，我可以推薦他的普拉莫德ĴSadolage本書，叫做「數據庫重構」 - http://www.ambysoft.com/books/refactoringDatabases.html

也有很多有用的建議和信息在敏捷數據庫羣雅虎 - http://tech.groups.yahoo.com/group/agileDatabases/

Answer 5

兩個快速筆記：

1. 不言而喻......所以我會說了兩遍。
   確認您擁有有效的備份。
   確認您擁有有效的備份。

2. @mk。檢查數據庫版本控制Jeff's blog post（如果您還沒有）