我的 Firefish 實例搭建於去年的 11 月,使用的數據庫版本自然不是最新的,確切的說,是 PGroonga 12,一個基於 5 年前的 Postgres 的遠古版本。為了避免今後的兼容性問題和安全問題,同時為了更好的性能,今天這數據庫是非升級不可。

升級一個用 Docker 跑起來的數據庫和升級其他的 Docker 容器有很大不同,並不是拉取一個新的鏡像就可以宣告結束。因為 Postgres 幾乎每個大版本都有 Breaking Changes,新老版本產生的持久化文件並不兼容,如果直接拉取一個新的鏡像運行,數據庫是無法啟動的,必須要採用一定的手段進行數據的遷移。
Postgres 有官方的升級工具pg_upgrade1,這一次我不採用,因為我的數據庫跑了一年多,而且用的還是 5 年前的老版本,用這個工具我不確定會不會出問題。這次遷移,大致思路是先導出 SQL,再將導出的 SQL 導入新版本。
升級前的部署概況
以下是一些升級前需要了解的配置信息:
| 項目 | 配置 |
|---|---|
| 實例部署方式 | Docker Compose |
| 數據庫容器名稱 | firefish_db |
| 升級前的數據庫容器鏡像 | groonga/pgroonga:3.1.9-alpine-12-slim |
| 數據庫用戶 | example-firefish-user |
| 數據庫名稱 | firefish |
Docker Compose 的數據庫部分如下:
| |
導出當前數據庫
對數據庫進行升級之前,首先下線 Firefish 的編排:
| |
單獨啟動數據庫容器,導出當前數據庫為 SQL:
| |
由於 Firefish 的數據庫比較大,導出過程可能需要很長一段時間,比如我的個人實例就用了十幾分鍾。
導出文件的處理
可能是由於新版的 Postgres 認證方式有所變更,如果直接向新數據庫導入之前導出的backup.sql文件,就會改變新數據庫的 Authentication Scheme,導致之後 Firefish 連接數據庫時認證失敗。要避免這個問題需要對目前的backup.sql進行一些處理,只抽取出其中的firefish數據庫的部分,而不是直接導入所有數據。2
| |
編輯一個 Shell 腳本為以上內容,保存至script.sh,用以處理目前的backup.sql:
| |
如果一切順利,當前目錄下就會出現一個名為upgrade.sql的文件,可以打開它看一下,確保其被正確導出。
向新數據庫導入現有數據
修改docker-compose.yml:
| |
注意數據庫目錄映射配置由./db:/var/lib/postgresql/data變為./database:/var/lib/postgresql/data,這麼做是為了給新的數據庫一個 Fresh Start,同時也保存老的持久化數據,即使出現問題,也可以隨時用回老的數據庫。
拉取並啟動新容器:
| |
向新數據庫導入upgrade.sql:
| |
取決於數據庫的大小,導入過程也會持續較長的時間。
收尾工作
導入完成,啟動整個編排:
| |
導入後的首次啟動不建議帶-d參數,建議不帶參數啟動,確保啟動過程沒有問題後再以-d參數啟動。
最後,登入剛剛啟動的 Firefish 實例,檢查是否有任何數據損失,沒有問題的話就大功告成啦🎉

評論已停用,直到您接受功能性 Cookie。