2014-09-26 397 views
0

我現在正在使用PostgreSQL幾個月。現在,我們通常使用實時數據庫來處理幾乎所有事情(在實時數據庫表中創建新列,執行更新和插入查詢等)。但是現在我們想要活下去,我們必須以不同的方式做事。最好的方法是擁有測試數據庫和實時數據庫。PostgreSQL在線和測試數據庫

現在我創建了一個實時數據庫的副本,所以我們有一個測試數據庫來運行測試。問題在於數據在24小時後仍然舊,所以我們實際上需要每24小時創建一次全新的副本,這對於手動操作來說並不聰明。

所以我的問題是,是否有人在這裏誰知道一個正確的方法來處理這個問題?

我認爲最理想的方法是: - 將實時數據庫中的表格選擇複製到測試數據庫(跳過表格,如用戶)。 - 可以添加列,重命名它們,甚至刪除它們,當我們部署新版本的網站時,將這些更改從測試數據庫傳輸到實時數據庫(淨necassary,但是會是一個很好的功能)。

+1

使用您確實爲實時系統實施的備份/恢復功能,每天在半夜恢復測試系統一次。 – 2014-09-26 15:36:11

+0

我剛剛在dba.SE上回答了一個非常類似的問題。見http://dba.stackexchange.com/q/77711/7788 – 2014-09-26 16:44:41

回答

0

如果你的數據庫結構正在改變,你可以做不是想自動。你吹走開發工作和數據。你想要它手動。


我曾經管理一個團隊,也有類似的情況:多的TiB數據庫,每日更新,並需要做測試和開發針對了最新數據。這是我們解決它的方式:

在我們的數據庫中,我們定義了一個函數,稱爲TODAY()。在我們的現場系統中,這是一個NOW()的包裝。在我們的測試系統中,它調用了一個只有一行是我們可以設置的日期的單列表。這意味着我們的測試系統是一個時間機器,可以假裝任何日期是當前的。

這意味着我們寫的每個函數或過程都必須具有時間意識。我應該關心未來計劃的事件嗎?未來有多遠?這使得我們的功能非常強大,並且使它變得非常簡單,可以根據各種各樣的歷史數據進行測試。這有助於捕獲大量我們從未想過會發生的錯誤,但我們看到確實發生在我們的歷史數據中。這就像數據庫的函數式編程!

我們仍然會安排大約每個月左右的實時備份數據庫更新。這有更多的數據和測試我們的備份/恢復程序的好處。我們的DBA會運行一個「測試後同步」腳本,爲開發人員設置權限,所以我們肯定比我們在測試系統上運行的任何東西都能在活動中工作。這是幫助我們構建部署數據庫腳本的原因。

+0

謝謝你的明確答案。所以你在哪裏編寫使用TODAY()而不是NOW()的腳本。在您的實時數據庫中,TODAY()僅僅是NOW()的包裝,而在您的測試數據庫中,TODAY()函數只是另一個日期?你還可以設置日期範圍嗎?這確實是一個很好的解決方案 – 2014-10-01 11:55:43