PostgreSQL 9.1 飛升之路

来源:https://www.cnblogs.com/dbadaily/archive/2022/07/04/postgresql-upgrade.html
-Advertisement-
Play Games

PostgreSQL upgrade 以升級 PostgreSQL 9.1 至 PostgreSQL 11 (跨越 9.2、9.3、9.4、9.5、9.6、10 六個大版本) 為例,本文將分享一下過去一年升級數十套 PostgreSQL 生產集群的實際經驗。 此步驟同樣適用於 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 等,可以選擇在初始化集群時導入或後續單獨導入。

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

Archive

需要註意的是,由於數據遷移過程中會產生大量 WAL log,搭建新集群時需要設置一下 archive_command 命令以避免產生不必要的 IO、備份等或避免 archiver 進程堵塞。在數據遷移完成後恢復 archive_command 為原有命令。

如設置為:

archive_command = 'cd .'

archive_command = '/bin/true'

Port

如果是在本機進行資料庫升級,在升級完成前,新集群需要使用臨時埠。

如:

port = 6432

PostgreSQL extensions

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

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

此處假設上述配置管理中未包含 CREATE DATABASECREATE 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;"

註意事項

  1. 如遇到 EXTENSION 不同版本所依賴軟體的相容問題,在不影響原資料庫的情況下,可能需要卸載或升級。

  2. 使用源碼安裝的擴展或擴展相關的依賴,可以通過在其安裝時源碼目錄執行 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 為例,在整個實例升級期間:主庫讀操作閃斷三次,不可寫;各從庫讀操作將閃斷一次。

具體如下:

  1. 為保證主庫絕對的只讀,升級開始前將主庫 vip 漂移至從庫。主庫讀操作將出現閃斷,寫操作將失敗。升級期間所有庫可讀,不可寫。
  2. 新舊庫切換瞬間會有秒級閃斷。
  3. 升級完成後,將主庫 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.

  1. The instance size is quite small
  2. 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.

  1. The database size is quite small
  2. You've got enough time to wait for the hours long dump
  3. 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.

  1. PostgreSQL database to be dumped contains one or more huge tables or time consuming tables
  2. 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 也可以優化一下,或者將更多手工操作步驟配置管理化。

慶祝

生活需要儀式感,工作也是。好好犒勞一下小伙伴們吧!

原文鏈接:
https://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


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 鏡像下載、功能變數名稱解析、時間同步請點擊 阿裡雲開源鏡像站 查看私有倉庫有哪些鏡像 如果私有倉庫帶有認證,在使用 curl 命令的時候需要帶上 -u 參數 使用方法: curl -XGET -u <倉庫用戶名>:<用戶名密碼> http://<倉庫ip地址>:<倉庫埠>/v2/_catalog curl ...
  • 一、通配符 匹配參數,匹配文件/目錄名字 : *.txt *.sh lidao{1,4}.txt | * | 所有 | | | | | {} | 生成序列 | | [] | 【a-z】匹配小寫字母,一個中括弧相當於一個字元 | | [^] | 取反排除 | | ? | 任何一個字元 | 1. 通配符 ...
  • Background NGINX 是一個通用且流行的應用程式。也是最流行的 Web 伺服器,它可用於提供靜態文件內容,但也通常與其他服務一起用作分散式系統中的組件,在其中它用作反向代理、負載均衡 或 API 網關。 分散式追蹤 distributed tracing 是一種可用於分析與監控應用程式的 ...
  • 1 存儲引擎 1、簡單描述一個Mysql的內部結構? MySQL的基本架構示意圖: 大體來說,MySQL可以分為server層和存儲引擎層兩部分。 ① server層包括連接器、查詢緩存、分析器、優化器、執行器等,涵蓋MySQL的大多數核心服務功能 ② 存儲引擎層:存儲引擎層負責數據的存儲和提取。其 ...
  • ###@Spark分區器(Partitioner) ####HashPartitioner(預設的分區器) HashPartitioner分區原理是對於給定的key,計算其hashCode,並除以分區的個數取餘,如果餘數小於0,則餘數+分區的個數,最後返回的值就是這個key所屬的分區ID,當key為 ...
  • 一鍵直達直播間 一、直播介紹 上兩期渡劫同學為大家分享了ChunJun數據還原的DDL模塊,想必大家對這一模塊有了比較深入的瞭解,本期無倦同學將會為大家分享ChunJun同步Hive事務表的相關內容,直播將從Hive事務表的結構及原理、ChunJun讀寫Hive事務表實戰、源碼解析及ChunJun文 ...
  • 一. 下載mysql 8.0.29軟體包 下載點我 二. 解壓,初始化安裝 1,打開下載後文件所在目錄,使用解壓軟體解壓,打開文件夾!(如圖,文件路徑不要出現中文!) 2,創建my.ini文件,創建前先開啟文件尾碼名顯示防止文件格式錯誤! 3,右鍵空白處,新建>文本文檔>選中文件>重命名>全選>文件 ...
  • 前言 上文介紹了ES的各種查詢; 本文介紹如何在ES進行MySQL中的分組和聚合查詢 實現用戶輸入拼音自動補全功能 實現MySQL和ES之間的數據自動同步; 一、分組聚合 在ES中對於聚合查詢,主要分為2大類:指標(Metric)聚合 與 桶(Bucket)聚合。 指標聚合:max、min、sum等 ...
一周排行
    -Advertisement-
    Play Games
  • 示例項目結構 在 Visual Studio 中創建一個 WinForms 應用程式後,項目結構如下所示: MyWinFormsApp/ │ ├───Properties/ │ └───Settings.settings │ ├───bin/ │ ├───Debug/ │ └───Release/ ...
  • [STAThread] 特性用於需要與 COM 組件交互的應用程式,尤其是依賴單線程模型(如 Windows Forms 應用程式)的組件。在 STA 模式下,線程擁有自己的消息迴圈,這對於處理用戶界面和某些 COM 組件是必要的。 [STAThread] static void Main(stri ...
  • 在WinForm中使用全局異常捕獲處理 在WinForm應用程式中,全局異常捕獲是確保程式穩定性的關鍵。通過在Program類的Main方法中設置全局異常處理,可以有效地捕獲並處理未預見的異常,從而避免程式崩潰。 註冊全局異常事件 [STAThread] static void Main() { / ...
  • 前言 給大家推薦一款開源的 Winform 控制項庫,可以幫助我們開發更加美觀、漂亮的 WinForm 界面。 項目介紹 SunnyUI.NET 是一個基於 .NET Framework 4.0+、.NET 6、.NET 7 和 .NET 8 的 WinForm 開源控制項庫,同時也提供了工具類庫、擴展 ...
  • 說明 該文章是屬於OverallAuth2.0系列文章,每周更新一篇該系列文章(從0到1完成系統開發)。 該系統文章,我會儘量說的非常詳細,做到不管新手、老手都能看懂。 說明:OverallAuth2.0 是一個簡單、易懂、功能強大的許可權+可視化流程管理系統。 有興趣的朋友,請關註我吧(*^▽^*) ...
  • 一、下載安裝 1.下載git 必須先下載並安裝git,再TortoiseGit下載安裝 git安裝參考教程:https://blog.csdn.net/mukes/article/details/115693833 2.TortoiseGit下載與安裝 TortoiseGit,Git客戶端,32/6 ...
  • 前言 在項目開發過程中,理解數據結構和演算法如同掌握蓋房子的秘訣。演算法不僅能幫助我們編寫高效、優質的代碼,還能解決項目中遇到的各種難題。 給大家推薦一個支持C#的開源免費、新手友好的數據結構與演算法入門教程:Hello演算法。 項目介紹 《Hello Algo》是一本開源免費、新手友好的數據結構與演算法入門 ...
  • 1.生成單個Proto.bat內容 @rem Copyright 2016, Google Inc. @rem All rights reserved. @rem @rem Redistribution and use in source and binary forms, with or with ...
  • 一:背景 1. 講故事 前段時間有位朋友找到我,說他的窗體程式在客戶這邊出現了卡死,讓我幫忙看下怎麼回事?dump也生成了,既然有dump了那就上 windbg 分析吧。 二:WinDbg 分析 1. 為什麼會卡死 窗體程式的卡死,入口門檻很低,後續往下分析就不一定了,不管怎麼說先用 !clrsta ...
  • 前言 人工智慧時代,人臉識別技術已成為安全驗證、身份識別和用戶交互的關鍵工具。 給大家推薦一款.NET 開源提供了強大的人臉識別 API,工具不僅易於集成,還具備高效處理能力。 本文將介紹一款如何利用這些API,為我們的項目添加智能識別的亮點。 項目介紹 GitHub 上擁有 1.2k 星標的 C# ...