PostgreSQL 9.1 飛升之路

2022 年 7 月 4 日
筆記
PostgreSQL

PostgreSQL upgrade

以升級 PostgreSQL 9.1 至 PostgreSQL 11 (跨越 9.2、9.3、9.4、9.5、9.6、10 六個大版本) 為例，本文將分享一下過去一年升級數十套 PostgreSQL 生產集群的實際經驗。

此步驟同樣適用於 PostgreSQL 9.1 之後的大版本升級。

準備工作

數據庫升級周知

提前通過郵件或 IM 周知升級信息和相關注意事項，以便相關同學能夠提前安排工作並在升級期間進行上線支持。尤其是需要停服務的應用，需要提前周知終端用戶停服時間窗口。

檢查已有日誌有無報錯

有沒有遇到過這樣的情景？

數據庫升級後，開發同學發現應用有報錯，比如訪問某個表沒有權限，甚至是某些應用訪問不了數據庫，抱怨都是數據庫升級的問題。此時，把問題 fix 就完事了么？當然不是，還要查明原因，到底是哪個步驟出問題了。查到最後，竟發現升級操作沒有問題。這時候可能會想起來查一下之前的數據庫日誌，如果你還沒有刪除的話。最後才知道，升級前就存在此問題。

或者數據庫升級後，你查看數據庫日誌，一看沒有某些表的訪問權限。此時你可能就抓瞎了，一頓操作，終於把問題 fix 了，時間也已經早已過了之前周知的時間窗口。事後再查日誌，才知道這是已有問題，與數據庫升級無關，白白浪費那麼多寶貴的升級時間。

所以有些報錯並非是數據庫升級造成的，而是升級之前就已經存在問題。此步驟就是儘早發現錯誤，提前排除與升級無關的錯誤。

可以通過如下命令檢查 PostgreSQL 日誌：

grep -i -E 'error:|fatal:|warning:' postgresql-*|less

如有報錯，查看報錯的上下文：

grep -A 2 -i -E 'error:|fatal:|warning:' postgresql-*|less

Merge ACL

如果集群沒有做配置管理(如 Ansible)，或者沒有機制保證集群各實例 pg_hba.conf 完全一致或符合一定規則，就需要人工檢查對比，避免後續出現主從切換後由於 ACL 不一致而訪問不了數據庫的情況。

pg_hba.conf 等配置文件建議做配置管理。人工對比的話，那麼多行，還集群的各個實例都要對比。寫個腳本對比合併吧，不直觀且腳本有 bug 不易發現，應用後續受到影響就為時已晚。有些實例還打開了所有子網的訪問權限(如 10.0.0.0/8)，你不得不整個集群都打開所有訪問權限，然而 ACL 放開了，數據庫安全性就降低了。

高版本集群初始化

集群初始化

此處以配置管理自動化為例。

Ansible:

ansible-playbook playbooks/cluster.yml -i inv.ini -e 'server_group=cluster1' -D

Salt:

salt -E 'db[1-2].az1|db3.az2' state.sls cluster

postgres 數據庫

若在 postgres 數據庫存儲了信息，如一些元數據、procedure、view 等，可以選擇在初始化集群時導入或後續單獨導入。

如能集成在上述配置管理中最好。

Port

如果是在本機進行數據庫升級，在升級完成前，新集群需要使用臨時端口。

如：

port = 6432

PostgreSQL extensions

有些早期的 PostgreSQL extension 不是通過 CREATE EXTENSION 創建的，通過 \dx 是看不到的，pg_dump 產生的 SQL 中也沒有 CREATE EXTENSION，此時要額外執行 CREATE EXTENSION 語句。

新版本的對應的 PostgreSQL extensions 相關軟件已通過上述 ansible playbook 或 salt states 安裝。

此處假設上述配置管理中未包含 CREATE DATABASE 及 CREATE EXTENSION 。如已包含在配置管理自動化中，可跳過此步驟。

以 CentOS 為例，通過以下命令查看舊版本數據庫已安裝的擴展，如

rpm -qa|grep pg

通過以下命令查看各數據庫實例中通過 CREATE EXTENSION 安裝的擴展，如

\dx

通過對比上述兩個結果，找出未通過 CREATE EXTENSION 創建的擴展。

假設早期版本的 postgis extension 未通過 CREATE EXTENSION 創建。在新版本中通過如下方式手動創建。

psql -p 6432 -U postgres -c "CREATE ROLE alvin;"
psql -p 6432 -U postgres -c "CREATE DATABASE alvindb WITH OWNER = alvin;"
psql -p 6432 -d alvindb -U postgres -c "CREATE EXTENSION postgis;"

注意事項

如遇到 EXTENSION 不同版本所依賴軟件的兼容問題，在不影響原數據庫的情況下，可能需要卸載或升級。
使用源碼安裝的擴展或擴展相關的依賴，可以通過在其安裝時源碼目錄執行 make uninstall 進行卸載。

相關文章：PostGIS 擴展創建失敗原因調查。

停掉受影響的定時任務

有些集群會部署 VACUUM 的定時任務，備份定時任務，或其他任務。

數據庫升級期間，需要停掉受影響的定時任務，避免不必要的失敗或影響數據庫升級。

以 postgres 下定時任務為例。

可以手動一個一個實例查看，

su - postgres
crontab -l

也可以通過配置管理工具查看。

Ansible:

ansible -i inv.ini -m shell -a 'sudo -iu postgres crontab -l' cluster1

Salt:

salt -E 'db[1-2].az1|db3.az2' cmd.run 'sudo -iu postgres crontab -l'

持續觀察數據庫日誌

老集群和新集群每個機器單獨開一個窗口，通過如下命令持續觀察日誌。

此命令會自動取最新日誌。

cd log
ls -lth|head -2|grep post && tail -f $(ls -lth|head -2|grep post|awk '{print $NF}')|grep -i -E 'error:|fatal:|warning:'

同時觀察是否有寫操作和錯誤日誌

ls -lth|head -2|grep post && tail -f $(ls -lth|head -2|grep post|awk '{print $NF}')|grep -i -E 'error:|fatal:|warning:|insert |update |delete |copy '

關閉報警監控

關閉數據庫相關監控，避免不必要的報警。此處包括老集群和新集群的報警。

如果報警機制設置粒度比較細的話，盡量保留原集群必要的報警，防止升級過程中對原集群產生不良影響或在升級過程中原集群有報警。

通知開發同學作數據遷移準備

數據庫寫操作

如應用可接受停止寫操作，則需要開發同學將寫操作相關任務停掉或封掉寫操作相關接口。

如數據需要不斷寫入，則需要定製增量數據同步方案或選擇合適的數據庫升級方案。

可通過如下命令檢查日誌是否有新的寫入：

grep log_statement postgresql.conf
log_statement = 'mod'

cd pg_log
ls -lth|head -2|grep post && tail -f $(ls -lth|head -2|grep post|awk '{print $NF}')|grep -i -E 'insert |update |delete '

如仍有計劃外的寫入，可通過如下命令查看仍有寫入的 ip，然後根據 ip 查詢相應的 server group 反饋給開發同學進行確認。

grep -i -E 'insert |update |delete |copy ' postgresql-*.log|grep -Eo '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'|sort|uniq

數據庫讀操作

對於讀操作，原庫在數據遷移期間可提供只讀服務，但在新舊庫切換瞬間等時刻讀操作會有秒級閃斷。如讀操作也不能受影響且又沒有 load balancer 的話，可以考慮更優方案。

以使用 vip 為例，在整個實例升級期間：主庫讀操作閃斷三次，不可寫；各從庫讀操作將閃斷一次。

具體如下：

為保證主庫絕對的只讀，升級開始前將主庫 vip 漂移至從庫。主庫讀操作將出現閃斷，寫操作將失敗。升級期間所有庫可讀，不可寫。
新舊庫切換瞬間會有秒級閃斷。
升級完成後，將主庫 vip 漂移回主庫機器，主庫讀操作將出現閃斷。寫操作 vip 漂移完後將正常可寫。

觀察應用

觀察應用是否有報警或報錯。如有數據庫升級相關引起的報錯，需要及時反饋。

檢查已有數據庫連接

升級前檢查原數據庫集群每個實例實時連接情況，升級後觀察新集群實例中有無相應新連接。

PostgreSQL 9.2 and later versions

SELECT
    datname,
    usename,
    application_name,
    client_addr,
    client_hostname,
    state,
    COUNT(1) connections
FROM
    pg_stat_activity
WHERE pid <> pg_backend_pid()
GROUP BY
    datname,
    usename,
    application_name,
    client_addr,
    client_hostname,
    state
ORDER BY
    connections DESC,
    datname,
    usename,
    application_name,
    client_addr,
    client_hostname,
    state;

PostgreSQL 9.1

SELECT
    datname,
    usename,
    application_name,
    client_addr,
    client_hostname,
    COUNT(1) connections
FROM
    pg_stat_activity
WHERE procpid <> pg_backend_pid()
GROUP BY
    datname,
    usename,
    application_name,
    client_addr,
    client_hostname
ORDER BY
    connections DESC,
    datname,
    usename,
    application_name,
    client_addr,
    client_hostname;

主庫設置為只讀

實例級別只讀

如果需要升級整個實例，則可以將整個實例設置為只讀。

修改配置文件：

vi postgresql.conf

將 default_transaction_read_only 設置為 on :

default_transaction_read_only = on

reload 生效。已有連接不需要 terminate，即時生效。

psql -U postgres -d postgres -p 5432 -c 'SHOW default_transaction_read_only'
psql -U postgres -d postgres -p 5432 -c 'SELECT pg_reload_conf()'
psql -U postgres -d postgres -p 5432 -c 'SHOW default_transaction_read_only'

數據庫級別只讀

當需要將單個數據庫或多個數據庫從實例中遷移出來，需要在數據庫級別設置只讀。如一個實例中有多個數據庫，並且有數據庫比較大，如超過 1T，從性能、備份任務、磁盤空間等因素考慮，需要將數據庫遷移出來；或將不同部門或業務線的數據庫從共用實例中遷移出來。

執行如下 SQL 可以設置數據庫級別只讀：

ALTER DATABASE alvindb SET default_transaction_read_only = on;

但需要注意，只對新的連接生效，也就是遷移數據前需要 terminate 已有的連接。

PostgreSQL 9.2 and later versions

查看連接：

SELECT * FROM pg_stat_activity WHERE datname = 'alvindb' AND state = 'idle in transaction';
SELECT * FROM pg_stat_activity WHERE datname = 'alvindb' AND state = 'idle';
SELECT * FROM pg_stat_activity WHERE datname = 'alvindb';

terminate 連接：

SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'alvindb' AND state = 'idle in transaction';
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'alvindb' AND state = 'idle';
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'alvindb';

PostgreSQL 9.1

查看連接：

SELECT * FROM pg_stat_activity WHERE datname = 'alvindb' AND current_query = '<IDLE> in transaction';
SELECT * FROM pg_stat_activity WHERE datname = 'alvindb' AND current_query = '<IDLE>';
SELECT * FROM pg_stat_activity WHERE datname = 'alvindb';

terminate 連接：

SELECT pg_terminate_backend(procpid) FROM pg_stat_activity WHERE datname = 'alvindb' AND current_query = '<IDLE> in transaction';
SELECT pg_terminate_backend(procpid) FROM pg_stat_activity WHERE datname = 'alvindb' AND current_query = '<IDLE>';
SELECT pg_terminate_backend(procpid) FROM pg_stat_activity WHERE datname = 'alvindb';

主庫 vip 漂移至從庫(實例級別)

升級整個實例時，為保證主庫絕對的只讀，應用使用 vip 連接的可以將 vip 漂移至從庫。

vip 漂移完畢可通過如下命令，分別在主庫和從庫上查詢 vip 漂移後連接狀態：

netstat -tnp|grep 5432|grep 10.20.20.10
netstat -tnp|grep 5432|grep 10.20.20.10|wc -l

數據遷移

以下步驟在 screen 中執行。

此處數據遷移採用 Easy Dump shell 腳本工具，封裝了 pg_dump 的 16 種 case，設置好相關參數後，一行命令即可。

同時給出對應的 pg_dump 命令以供參考。

以下列出幾種常用 case (引自 Easy Dump 文檔原文)。

Dump all schema and data

If you need to dump all the databases and users in one of the following cases, just use this easiest way to dump a PostgreSQL instance.

The instance size is quite small
You have got enough time to wait for the hours long dump

Easy Dump command

bash pg_dump.sh -v -M ALL

PostgreSQL pg_dump command

time "${PGBIN}"/pg_dumpall -v -U "${DBUSER}" -h "${DBHOST}" -p "${DBPORT}" -s 2>>"${lv_dump_log}" | "${PGBIN}"/psql -U postgres -p "${DBPORT_TARGET}" -e &>>"${lv_restore_log}"

Dump all tables of a database

In some cases you need to dump the users separately and then dump the database.

The database size is quite small
You’ve got enough time to wait for the hours long dump
You are separating one database from a huge instance on which there are multiple databases or you just don’t need other databases

Easy Dump command

bash pg_dump.sh -v -M DB -d alvindb

PostgreSQL pg_dump command

time "${PGBIN}"/pg_dump -v -U "${DBUSER}" -h "${DBHOST}" -p "${DBPORT}" -d "${lv_dbname}" 2>>"${lv_dump_log}" | "${PGBIN}"/psql -U postgres -p "${DBPORT_TARGET}" -d "${lv_dbname}" -e &>>"${lv_restore_log}"

Dump all tables, specified tables are dumped in parallel

In some cases you need to dump a database and dump some of the tables in parallel.

PostgreSQL database to be dumped contains one or more huge tables or time consuming tables
You need to minimize the dump time to reduce the affect on the application

Easy Dump command

bash pg_dump.sh -v -M DB -d alvindb -T "public.tb_vacuum alvin.tb_alvindb_vacuum" -L -t 3

PostgreSQL pg_dump command

Firstly dump the database with exclusion.

You can use one -T option to specify table pattern. Please note that the table pattern is not regular expression and in rare cases like same table name exists in in various schemas it might not work as expected.

time "${PGBIN}"/pg_dump -v -U "${DBUSER}" -h "${DBHOST}" -p "${DBPORT}" -d "${lv_dbname}" -T "public|alvin.tb_vacuum|tb_alvindb_vacuum" 2>>"${lv_dump_log}" | "${PGBIN}"/psql -U postgres -p "${DBPORT_TARGET}" -d "${lv_dbname}" -e &>>"${lv_restore_log}"

You can also use multiple -T options to specify all tables to be excluded.

time "${PGBIN}"/pg_dump -v -U "${DBUSER}" -h "${DBHOST}" -p "${DBPORT}" -d "${lv_dbname}" -T "public.tb_vacuum" -T "alvin.tb_alvindb_vacuum" 2>>"${lv_dump_log}" | "${PGBIN}"/psql -U postgres -p "${DBPORT_TARGET}" -d "${lv_dbname}" -e &>>"${lv_restore_log}"

Then dump specified tables in parallel.

time "${PGBIN}"/pg_dump -v -U "${DBUSER}" -h "${DBHOST}" -p "${DBPORT}" -d "${DBNAME}" -t "public.tb_vacuum" 2>>"${lv_dump_log}" | "${PGBIN}"/psql -U postgres -p "${DBPORT_TARGET}" -d "${DBNAME}" -e &>>"${lv_restore_log}" &

time "${PGBIN}"/pg_dump -v -U "${DBUSER}" -h "${DBHOST}" -p "${DBPORT}" -d "${DBNAME}" -t "alvin.tb_alvindb_vacuum" 2>>"${lv_dump_log}" | "${PGBIN}"/psql -U postgres -p "${DBPORT_TARGET}" -d "${DBNAME}" -e &>>"${lv_restore_log}" &

數據遷移過程中檢查

查看監控

查看 CPU、load、IO 及網絡流量等。

查看 dump 進程

date && ps -ef|grep -E 'dump|psql'
date && ps -ef|grep 'dump'
date && ps -ef|grep 'psql'

查看數據庫實例大小

date && psql -p 6432 -U postgres -c '\l+'

通過腳本日誌查看數據遷移進度

tail -f *.log

檢查數據遷移中是否有錯誤

grep -i -E 'error:|fatal:|warning:' *.log

查看正在執行的 SQL

PostgreSQL 9.2 and later versions

psql -p 6432 -U postgres -c "SELECT * FROM pg_stat_activity WHERE application_name  = 'psql' and pid <> pg_backend_pid() ORDER BY backend_start" -x

PostgreSQL 9.1

目前一般沒有需要升級到 PostgreSQL 9.1 的，除非要遷移到 PostgreSQL 9.1 的庫。

psql -p 6432 -U postgres -c "SELECT * FROM pg_stat_activity WHERE application_name  = 'psql' and procpid <> pg_backend_pid() ORDER BY backend_start" -x

查看主從延遲

PostgreSQL 10 and later versions

SELECT
    application_name,
    pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn)) AS diff
FROM pg_stat_replication;

PostgreSQL 9.6 and earlier versions

目前一般沒有需要升級到 PostgreSQL 9.x 的。

SELECT
    application_name,
    pg_size_pretty(pg_xlog_location_diff(pg_current_xlog_location(), replay_location)::bigint) as diff
    FROM
    pg_stat_replication;

查看有無鎖 block 數據遷移

psql -p 6432 -U postgres -c "SELECT * FROM pg_locks WHERE not granted;" -x

查看有無 AUTOVACUUM

PostgreSQL 9.2 and later versions

psql -p 6432 -U postgres -c "SELECT * FROM pg_stat_activity WHERE query ~ 'auto' AND pid <> pg_backend_pid() ORDER BY backend_start" -x

PostgreSQL 9.1

目前一般沒有需要升級到 PostgreSQL 9.1 的，除非要遷移到 PostgreSQL 9.1 的庫。

psql -p 6432 -U postgres -c "SELECT * FROM pg_stat_activity WHERE current_query ~ 'auto' AND procpid <> pg_backend_pid() ORDER BY backend_start" -x

ANALYZE

為防止數據遷移後，由於統計信息等原因對查詢性能產生影響，需要進行 ANALYZE。

ANALYZE TABLES

如果數據遷移中，有多個表並行遷移的話，遷移完成的表可以先進行 ANALYZE。

time psql -U postgres -d alvindb -p 6432 -U postgres -c 'ANALYZE VERBOSE alvin.tb_test' && echo Done|mail -s "ANALYZE alvin.tb_test completed" "[email protected]" &

ANALYZE DATABASE

先 ANALYZE database postgres:

time psql -U postgres -d postgres -p 6432 -U postgres -c 'ANALYZE VERBOSE' && echo Done|mail -s "ANALYZE postgres completed" "[email protected]" &

整個數據庫數據遷移完成後，對整個數據庫進行 ANALYZE。

time psql -U postgres -d alvindb -p 6432 -U postgres -c 'ANALYZE VERBOSE' && echo Done|mail -s "ANALYZE alvindb completed" "[email protected]" &

新老集群切換

在主從無延遲後進行新老集群切換。

修改配置文件

修改如下配置文件

vi postgresql.conf

恢復如下參數

port = 5432
archive_command = 'xxx'

同時，也將如下配置文件中的 port 修改為相應的值。

recovery.conf

查看主從延遲

PostgreSQL 10 and later versions

SELECT
    application_name,
    pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn)) AS diff
FROM pg_stat_replication;

PostgreSQL 9.6 and earlier versions

目前一般沒有需要升級到 PostgreSQL 9.x 的。

SELECT
    application_name,
    pg_size_pretty(pg_xlog_location_diff(pg_current_xlog_location(), replay_location)::bigint) as diff
    FROM
    pg_stat_replication;

老集群減少 wal 日誌

無主從延遲後進行如下操作。

為了節省空間，減少老集群不必要的 wal 日誌，修改老集群如下配置文件

vi postgresql.conf

修改如下參數，如

wal_keep_segments = 1000

reload 生效，並最晚在下一步執行 CHECKPOINT 後自動刪除多餘的 wal 日誌。

psql -U postgres -d postgres -p 5432 -c 'select pg_reload_conf()'

執行 CHECKPOINT

為保證老集群能夠儘快停止和新集群能夠儘快啟動以提供服務，在切換前執行 CHECKPOINT ：

date && time psql -p 5432 -U postgres -c 'CHECKPOINT'
date && time psql -p 6432 -U postgres -c 'CHECKPOINT'

停舊實例並啟動新實例

運行如下命令，在停掉原實例後緊接着啟動新實例。

/usr/pg91/bin/pg_ctl stop -D /data/pg91 -mi && /usr/pg11/bin/pg_ctl stop -D /data/pg11 -mf && /usr/pg11/bin/pg_ctl start -D /data/pg11

如果只是遷移一個數據庫而非整個實例，則原實例不需要停掉，只把原數據庫名字改了即可。

檢查 archive log

確認 archiver 進程正常運行且無 archive 滯後，

cd pg_wal
ps -ef|grep postgres|grep 'archiver'|grep -v grep && ls -lt $(ps -ef|grep postgres|grep 'archiver'|grep -v grep|awk '{print $NF}')

可以手動在主庫執行如下命令，並在 archive 目錄中檢查 archiver 進程是否正常工作。

SELECT pg_switch_wal();

升級其他軟件

如果集群中使用的與數據庫版本相關的軟件，也需要相應升級。如 archive_command 中涉及的軟件和備份相關的軟件等。

主庫 vip 漂移回主庫

如升級開始時進行了 vip 漂移，此時需要將 vip 漂移回主庫。

vip 漂移完畢可通過如下命令，分別在主庫和從庫上查詢 vip 漂移後連接狀態：

netstat -tnp|grep 5432|grep 10.20.20.10
netstat -tnp|grep 5432|grep 10.20.20.10|wc -l

從庫可以 terminate 主庫 vip 的連接了：

查看連接：

SELECT * FROM pg_stat_activity WHERE datname = 'alvindb' AND state = 'idle in transaction';
SELECT * FROM pg_stat_activity WHERE datname = 'alvindb' AND state = 'idle';
SELECT * FROM pg_stat_activity WHERE datname = 'alvindb';

terminate 連接：

SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'alvindb' AND state = 'idle in transaction';
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'alvindb' AND state = 'idle';
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'alvindb';

檢查數據庫日誌

通過如下命令持續觀察日誌，確保升級後不出現新的報錯。

cd log
ls -lth|head -2|grep post && tail -f $(ls -lth|head -2|grep post|awk '{print $NF}')|grep -i -E 'error:|fatal:|warning:'

檢查數據庫連接

確保有新的數據庫連接到新的集群。如應用未自動連接到數據庫，則與開發同學確認是否需要重啟應用。

檢查監控

檢查並對比升級前後各種監控，如 qps、wal size per second 等確保業務恢復正常。

如果應用較多，對於其中訪問 qps 較低的應用，此方法不明顯，最好由業務方查看應用日誌或相關業務監控。

通知業務同學驗證

開發同學或測試同學進行驗證，確保應用正常運行。並觀察升級前後業務方面監控，如訂單量的監控等。

恢復定時任務

如定時任務腳本中有使用數據庫軟件的絕對路徑，則需要改成新版本的路徑，以免定時任務報錯。

腳本確認無問題後，可恢復定時任務或重新跑未完成的任務。

如使用配置管理工具，如 Ansible，修改相關配置後直接使用 Ansible 更新配置即可。

尤其是多個腳本 (vacuum、備份、定時清理數據等任務) 使用數據庫軟件的絕對路徑時，如 /usr/pg91/bin/，使用配置管理會避免遺漏，減少人工操作，質量更有保證。

打開報警監控

檢查原集群或新集群臨時端口是否有監控項需要清理。無問題後，恢復監控。

收尾工作

數據庫升級完成周知

通過郵件或 IM 周知。

信息更新

檢查是否有文檔或系統記錄與數據庫版本有關並需要手動更新的信息。或是否需要關閉相關的 ticket。

後續觀察監控及日誌

如有異常，及時調查並解決。

總結經驗

如在升級過程中遇到問題，詳細記錄並總結在以後的數據庫升級中如何優化或解決。

如已有配置管理，升級過程中如發現未考慮到的 case 也可以優化一下，或者將更多手工操作步驟配置管理化。

慶祝

生活需要儀式感，工作也是。好好犒勞一下小夥伴們吧！

原文鏈接：
//www.cnblogs.com/dbadaily/p/postgresql-upgrade.html
您瀏覽的網址與此鏈接不一致的話，則為未授權的轉載，為了更好的閱讀體驗，建議閱讀原文。

公眾號

關注 DBA Daily 公眾號，第一時間收到文章的更新。
通過一線 DBA 的日常工作，學習實用數據庫技術乾貨！

公眾號優質文章推薦

PostgreSQL VACUUM 之深入淺出

pg_dump 的十六般變化

寫了一個簡單易用的 shell 框架

華山論劍之 PostgreSQL sequence

GitLab supports only PostgreSQL now

MySQL or PostgreSQL?

PostgreSQL hstore Insight

Tags: PostgreSQL

PostgreSQL 9.1 飛升之路

PostgreSQL upgrade

準備工作

數據庫升級周知

檢查已有日誌有無報錯

Merge ACL

高版本集群初始化

集群初始化

postgres 數據庫

Archive

Port

PostgreSQL extensions

停掉受影響的定時任務

持續觀察數據庫日誌

關閉報警監控

通知開發同學作數據遷移準備

數據庫寫操作

數據庫讀操作

觀察應用

檢查已有數據庫連接

PostgreSQL 9.2 and later versions

PostgreSQL 9.1

主庫設置為只讀

實例級別只讀

數據庫級別只讀

PostgreSQL 9.2 and later versions

PostgreSQL 9.1

主庫 vip 漂移至從庫(實例級別)

數據遷移

Dump all schema and data

Dump all tables of a database

Dump all tables, specified tables are dumped in parallel

數據遷移過程中檢查

查看監控

查看 dump 進程

查看數據庫實例大小

通過腳本日誌查看數據遷移進度

檢查數據遷移中是否有錯誤

查看正在執行的 SQL

PostgreSQL 9.2 and later versions

PostgreSQL 9.1

查看主從延遲

PostgreSQL 10 and later versions

PostgreSQL 9.6 and earlier versions

查看有無鎖 block 數據遷移

查看有無 AUTOVACUUM

PostgreSQL 9.2 and later versions

PostgreSQL 9.1

ANALYZE

ANALYZE TABLES

ANALYZE DATABASE

新老集群切換

修改配置文件

查看主從延遲

PostgreSQL 10 and later versions

PostgreSQL 9.6 and earlier versions

老集群減少 wal 日誌

執行 CHECKPOINT

停舊實例並啟動新實例

檢查 archive log

升級其他軟件

主庫 vip 漂移回主庫

檢查數據庫日誌

檢查數據庫連接

檢查監控

通知業務同學驗證

恢復定時任務

打開報警監控

收尾工作

數據庫升級完成周知

信息更新

後續觀察監控及日誌

總結經驗

慶祝

公眾號

公眾號優質文章推薦

分享此文：

Related Posts

數據結構與算法：哈夫曼樹

數據結構 4 時間複雜度、B-樹 B+樹 具體應用與理解

數據結構 4 時間複雜度、B-樹 B+樹具體應用與理解

理論續航65公里新大洲本田聯名款電動單車開賣：4980元