公司的測試環境和生產環境都是9.2.4版本，而開發環境是9.0.18版本。 PS： 不知道公司里的其它同事，是如何做資料庫遷移的，利用第三方可視化工具備份資料庫，然後恢復到其它高版本的環境？反正我沒成功過。 我是用cmd命令調用PostgreSQL的pg_dump+pgsql工具操作才成功的。 在自 ...
公司的測試環境和生產環境都是9.2.4版本，而開發環境是9.0.18版本。
PS：
不知道公司里的其它同事，是如何做資料庫遷移的，利用第三方可視化工具備份資料庫，然後恢復到其它高版本的環境？反正我沒成功過。
我是用cmd命令調用PostgreSQL的pg_dump+pgsql工具操作才成功的。
在自己電腦上，切換到PostgreSQL的bin目錄
cd /d C:\Program Files\PostgreSQL\9.6\bin
備份指定資料庫，確認後輸入密碼(口令)完成備份
pg_dump -h 192.168.23.62 -U postgres GL > d:\gl.bak
還原到指定資料庫，確認後輸入密碼(口令)完成還原
psql -h 192.168.42.3 -U postgres -d GL < d:\gl.bak
其中-U後面跟著的是資料庫賬戶名，這裡我用的具有管理員許可權的賬戶。
而-d後面跟著的是要備份/恢復的資料庫名稱。
再後面就是要備份/恢復的資料庫備份文件路徑了。
OK，啰嗦這麼多，進入正文：
現在想要為開發環境的PostgreSQL資料庫進行版本升級，按照以往的Microsoft SQL Server (MSSQL) 經驗，我都是下載更高版本的安裝包/或更新補丁包，一路下一步升級完成版本更新，整個過程無須創建另外一個資料庫引擎實例什麼的，而是在原有的資料庫引擎實例的基礎上進行無縫升級。
所以，當我把PostgreSQL 9.2.4安裝包文件postgresql-9.2.4-1-windows-x64.exe扔到開發環境中，點擊運行進行安裝時，一臉懵逼....
居然沒有更新升級操作，只有全新安裝(等於在同一個伺服器上安裝了兩個埠號不一樣，版本不一樣的PostgreSQL資料庫引擎實例)？？？這很不科學，我不信，我不聽...
沒辦法我還是讓它完成安裝，之後在官網文檔找解釋，然後我扒到了這個說明：https://www.postgresql.org/docs/9.2/static/pgupgrade.html
官網介紹可以使用目標更新版本的pg_upgrade工具命令進行升級。
命令格式如下：
pg_upgrade -b oldbindir -B newbindir -d olddatadir -D newdatadir [option...]
我沒有完全按照官網的流程來走，比如我沒有執行以下命令，因為我沒有名為postgres的Windows系統賬戶：
RUNAS /USER:postgres "CMD.EXE" SET PATH=%PATH%;C:\Program Files\PostgreSQL\9.2\bin;
而是另外建了一個名為pg_upgrade的bat批處理文件，然後右鍵以管理員身份運行這個bat批處理文件。
pg_upgrade.bat文件內容是：
set Path = %Path%;C:\Program Files\PostgreSQL\9.2\bin cd /d "C:\Program Files\PostgreSQL\9.2\bin" "C:\Program Files\PostgreSQL\9.2\bin\pg_upgrade.exe" --old-datadir "C:\Program Files\PostgreSQL\9.0\data" --new-datadir "C:\Program Files\PostgreSQL\9.2\data" --old-bindir "C:\Program Files\PostgreSQL\9.0\bin" --new-bindir "C:\Program Files\PostgreSQL\9.2\bin"
但是運行後，發生錯誤，其中命令提示符(控制台)顯示的錯誤是：
> Performing Consistency Checks > ----------------------------- > Checking cluster versions ok > > *failure* > Consult the last few lines of "pg_upgrade_server_start.log" or "pg_upgrade_server.log" for > the probable cause of the failure. > > connection to database failed: could not connect to server: Connection refused (0x0000274D/10061) > Is the server running on host "localhost" (::1) and accepting > TCP/IP connections on port 50432? > could not connect to server: Connection refused (0x0000274D/10061) > Is the server running on host "localhost" (127.0.0.1) and accepting > TCP/IP connections on port 50432? > > could not connect to old postmaster started with the command: > "C:\Program Files\PostgreSQL\9.0\bin\pg_ctl" -w -l "pg_upgrade_server.log" -D "C:\Program Files\PostgreSQL\9.0\data" -o "-p 50432 -b " start
pg_upgrade_server_start.log關鍵錯誤如下：
command: "C:\Program Files\PostgreSQL\9.0\bin\pg_ctl" -w -l "pg_upgrade_server.log" -D "C:\Program Files\PostgreSQL\9.0\data" -o "-p 50432 -b " start >> "pg_upgrade_server_start.log" 2>&1 Access is denied. waiting for server to start........ stopped waiting
經過第一次百度，找到了這個鏈接：https://zhidao.baidu.com/question/2011319586576805908.html
根據這個鏈接的指導，我選取一些認為沒有按照步驟做的地方，認真檢查一遍，並且修改過來（PS：當時看到“未使用管理員許可權運行命令提示符（CMD）”卻沒有在意，因為我是以管理員身份運行的，我認為我給了它最大許可權去運行，這也就導致我花費較長的時間才解決這個資料庫升級的問題）。
1.確保9.0和9.2的Windows服務已經停了。
postgresql-x64-9.0和postgresql-x64-9.2這兩個服務。
2.在C:\Program Files\PostgreSQL\9.0\data和C:\Program Files\PostgreSQL\9.2\data目錄下找到pg_hba.conf文件，把這兩邊的pg_hba.conf文件配置里的"md5"改成"trust"，註意這裡要小寫，我之前寫成首字母大寫Trust，坑逼...
PostgreSQL 9.0 pg_hba.conf原配置：
PostgreSQL 9.0 pg_hba.conf改後配置：
PostgreSQL 9.2 pg_hba.conf原配置：
PostgreSQL 9.2 pg_hba.conf改後配置：
這裡需要註意的是，高亮的那條0.0.0.0/0是原配置里沒有，我是等到後面折騰出新問題加上去的。
之所以要加上去的原因是，埠監聽問題，外部總是無法連接到9.2這個實例。所以你現在提前加上去最好。
至於最後面那兩條不用改，因為它們是被#號註釋掉的，不會起作用，所以沒影響，當然你太閑非要改，也沒人攔你。
3.把Path變數賦值順序對調一下。
set Path = C:\Program Files\PostgreSQL\9.2\bin;%Path% cd /d "C:\Program Files\PostgreSQL\9.2\bin" "C:\Program Files\PostgreSQL\9.2\bin\pg_upgrade.exe" --old-datadir "C:\Program Files\PostgreSQL\9.0\data" --new-datadir "C:\Program Files\PostgreSQL\9.2\data" --old-bindir "C:\Program Files\PostgreSQL\9.0\bin" --new-bindir "C:\Program Files\PostgreSQL\9.2\bin"
這是看百度知道里的第二點解釋，所以才這樣做的。
重新以管理員身份運行這個改動後的pg_upgrade.bat文件。
依舊是報剛纔那些錯誤。
再次百度無果，於是FQ上谷歌找答案，看到了這兩個鏈接：
https://www.postgresql.org/message-id/[email protected]
其中一個鏈接有解釋：
大體意思就是在Windows Server上以系統管理員身份運行pg_upgrade工具更新會有BUG，而這個BUG出現在PostgreSQL 9.2,9.3,9.4這幾個版本。
補救辦法，就是另外新建一個非管理員賬戶，然後在以系統管理員賬戶登錄Windows後，以非管理員賬戶運行這些命令。
所以我新建了一個名為postgres的非管理員(普通)賬戶，然後Win+R鍵打開運行視窗，輸入命令：
RUNAS /USER:postgres "CMD.EXE"
輸入該賬戶的密碼後，以postgres用戶身份打開命令提示符視窗，然後在該視窗內，運行pg_upgrade.bat
cd /d C:\
pg_upgrade.bat
這次，報另外一個錯誤：
There seems to be a postmaster servicing the old cluster.
Please shutdown that postmaster and try again.
再次GOOGLE，找到這個鏈接：
https://www.postgresql.org/message-id/20130119150242.GE2857%40momjian.us
大體意思就是，到PostgreSQL安裝目錄下的data目錄下，把postmaster.pid文件刪掉即可。
我留意到，這個文件是在PostgreSQL的Windows服務啟動後生成的，停止這個Windows服務就會被刪除(消失)。
可能是我之前的pg_upgrade操作不當，導致這個postmaster.pid沒有來得及被PostgreSQL清理掉。
而pg_upgrade的工作需要在PostgreSQL的Windows服務(資料庫引擎實例)停止狀態下進行。
所以當pg_upgrade運行檢測到postmaster.pid文件存在後，誤以為Windows服務還啟動著，然後拋出這個錯誤，但其實Windows服務已經是停止的了。
到9.0和9.2的data目錄下刪掉postmaster.pid文件後，繼續運行pg_upgrade.bat，這次等待十幾分鐘，終於運行成功。
Performing Consistency Checks ----------------------------- Checking cluster versions ok Checking database user is the install user ok Checking database connection settings ok Checking for prepared transactions ok Checking for reg* system OID user data types ok Checking for contrib/isn with bigint-passing mismatch ok Checking for invalid "line" user columns ok Checking for large objects ok Creating dump of global objects ok Creating dump of database schemas ok Checking for presence of required libraries ok Checking database user is the install user ok Checking for prepared transactions ok If pg_upgrade fails after this point, you must re-initdb the new cluster before continuing. Performing Upgrade ------------------ Analyzing all rows in the new cluster ok Freezing all rows on the new cluster ok Deleting files from new pg_clog ok Copying old pg_clog to new server ok Setting next transaction ID and epoch for new cluster ok Deleting files from new pg_multixact/offsets ok Setting oldest multixact ID on new cluster ok Resetting WAL archives ok Setting frozenxid and minmxid counters in new cluster ok Restoring global objects in the new cluster ok Restoring database schemas in the new cluster ok Setting minmxid counter in new cluster ok Creating newly-required TOAST tables ok Copying user relation files ok Setting next OID for new cluster ok Sync data directory to disk ok Creating script to analyze new cluster ok Creating script to delete old cluster ok Checking for large objects ok Upgrade Complete ---------------- Optimizer statistics are not transferred by pg_upgrade so, once you start the new server, consider running: analyze_new_cluster.bat Running this script will delete the old cluster's data files: delete_old_cluster.bat
然後它提示建議我們要運行analyze_new_cluster.bat和delete_old_cluster.bat。
但我只運行analyze_new_cluster.bat，至於delete_old_cluster.bat命令你自己看著運行。
輸入命令：
cd /d C:\Program Files\PostgreSQL\9.2\bin analyze_new_cluster.bat
等待完成後，用Navicat Premium連接到9.2，查看資料庫是否都在，全部都在。
算是完成了99%了，剩下1%是奇葩的埠號問題。
相信大家也看到前面提到的埠監聽問題，當時走到這一步後，在保持9.0的Windows服務(埠5432)停止的狀態下，啟動9.2的Windows服務(埠5433)。
然後在客戶端用Navicat Premium通過(埠5433)連接9.2死活連接不上，改成5432埠後連接成功了。
但連接後，顯示的PostgreSQL版本有問題，居然是9.0版本，詭異...
這不科學，難道把9.0的資料庫遷移到9.2後，發生版本錯亂了嗎？
查原因(沒查到)，改配置文件和註冊表中的PostgreSQL埠配置，甚至把9.0的埠配置改成其它的埠號(比如9876)，都無法解決問題。
後面搞得無論用5432還是5433埠，都無法連接，鬱悶...
之後靜下心來，仔細比較9.0和9.2的pg_hba.conf文件的差異，發現9.0有0.0.0.0/0這一行配置項，而9.2沒有，於是在9.2的pg_hba.conf中加進去。
然後重啟9.2的Windows服務，結果通過5433埠成功連接上去了，並且這次顯示的PostgreSQL版本是正確的，9.2.4版本。
檢查資料庫是否有遷移後漏掉的，或者數據編碼有沒有問題，都沒有問題，這次的遷移算是成功的。
然後改動9.2目錄下的data目錄里的postgresql.conf文件(C:\Program Files\PostgreSQL\9.2\data\postgresql.conf)，找到port項，把埠號改成和9.0一樣的(PostgreSQL預設埠號是5432).
再次改動pg_hba.conf文件(C:\Program Files\PostgreSQL\9.2\data\pg_hba.conf)，把trust改回原來的md5格式。
重新用Navicat Premium通過5432埠連接，檢查是否正常連接，連接成功就沒問題了。
PS：
全部完成之後，我把9.0全部刪掉，數據也不要了。
因為已經遷移到9.2，所以不再需要保留9.0上的舊數據。
當然如果你還要保留9.0上的舊數據也行，你開心就好。
