POSTGRESQL postgresql 升級的需求來自哪裡

說起POSTGRESQL 的升級問題，很多同學會問，升級POSTGRESQL 的動力是什麼，為什麼要升級POSTGREQL 資料庫。個人淺薄的愚見，一個資料庫的升級本身並不是一件簡單的事情，需要考慮的方面非常多，而一般如果每次升級資料庫不是為了解決核心的問題，一般是不會單純的由DB 來挑起整體資料庫升級的問題。

其實這三個問題可以合成一個問題，就是今天要說的問題

1  升級資料庫版本，是優先大版本還是小版本

這裡個人的觀點是，升級資料庫首先考慮小版本的升級，首先你在選擇一個資料庫版本中，會牽扯很多其他的部分，如開發，大資料，資料庫的特性等，語法，在這些基礎上，你跨越你當前的版本，去升級一個新的大版本，甚至要跨幾個版本去升級，你的需求點來自哪裡。

我特別害怕一個觀點，就是一句簡單的我要什麼什麼功能，新的版本效能有提升。這樣的想法和觀點，在大公司是不會被認可的，因為沒有人會因為你的一個IDEA 去冒著極大的風險，去升級資料庫。

而在當下，更多人關注的是大版本的升級，而不是當前版本的穩定性和BUG，這才是最讓人擔心的問題，諸如PG9.1.14 這裡的在資料庫的突然CRASH 的資料庫檔案缺失問題上的BUG 是需要被解決的，而不是我要去升級到PG15 來解決我當前系統由於9.1.14問題導致的系統不穩定的問題。

引擎在9.1.24 這個版本就發現9.1.14的BUG 並修復了這個BUG，所以盲目升級資料庫是我們當前最大的一個問題，只重視大版本，忽略小版本的BUG FIXED。

所以在我們遇到資料庫版本的問題，我們應該先查閱的是當前版本的小版本是否有對這個問題的改善或BUG FIXED，這才是我們思考問題的一個方式。

2  大版本升級中的隱患和問題

在PG的大版本升級中，會產生不少的問題我們可以歸結為如下的一些需要知曉的部分

1  資料遷移的問題

大部分同學都知道PG 的資料庫升級，尤其大版本升級是一件不容易的事情，主要的問題基於PG的資料庫版本中的資料檔案在每個版本都是不同的物理結構與變化。

所以在進行資料庫版本的變化的情況下，越大的資料庫的資料量是一個巨大的問題，同時一個頻繁進行工作的業務資料庫也是一個問題，停機的時間有多長，業務的資料如何不停機的同步到升級的資料庫，等等都是問題。

所以資料庫升級這個問題，可不是一個小的問題，也不是一個DBA 說說我透過邏輯複製槽進行增量複製那麼簡單的升級方案就可以搞定大版本的資料庫升級的方案。

2  資料庫功能改變對應用程式影響與周邊的問題

舉例 POSTGRESQL 15 中對於普通使用者在 public schema 上的改變，開發者是否知曉，DBA 是否知曉並作出相關的改變，如果不瞭解升級中可能出現的問題，而是直接升級，那麼估計連工作都難保證。

或者基於原有資料庫中的 stats staticists  在PG 15 中不見了，而多了引數進行調整，如果不知道的話，提取狀態資訊和之前的一些理解有區別，那監控基於這個的化又是一個新的話題了。

所以在對於資料庫大版本升級中，必須對新的版本有一定的試用或詳細的瞭解，以及測試才能逐步的進行升級，而不是腦子一熱就上去升級，然後可能資料庫還有然後，你就沒有然後了。

另外資料庫的運維方面的變化也是需要考慮的，一個企業的資料庫附帶的軟體也是一對，如備份軟體，以及監控軟體，你更換了更新的資料庫產品，那麼周邊的軟體是否能支援，這又是一個話題，這些軟體是否能支援你的資料庫，你自己心裡有點數嗎？

實際上在其他資料庫上會被提及的問題，在PG的升級上也會被提到。

3   你是否有強有力的學習能力，去HOLD 住新的知識的問題

這還是一個問題，一個新的資料庫是需要被瞭解和學習的，你在升級前，是否問過自己一個問題，一個新的資料庫如果上線了，你是否能快速的解決他可能發生的問題，如果你此時問自己這個問題的時候，就將自己變成了一個問題，那麼我勸你，還是悠著點，稍微等等吧，等那些先驅者升級了，採坑了，發文了，你在升級也不遲。

所以在升級一個資料庫前，你是否有一個強大的，冷靜的內心也是一個需要問自己的問題。

升級的誤區 盲目升級，在升級，在在升級

這還是一個問題，這個問題的所在就是，資料庫的升級並不是一個應該頻繁進行的操作，這和應用程式的迭代不同。

一個資料庫版本的升級，應該是深思熟慮的行為，你在做出這個決定的時候，應該瞭解升級會給你解決什麼問題，獲得什麼最大的利益，或解決當前你無法在忍受，或者你公司在某些專案上無法對當前的資料庫的一些問題進行解決，而需要更新的資料庫提供更好的解決方案等等。

如果不是上述不能解決的問題，或棘手的問題，資料庫一般是不會進行大版本升級的。