主頁 > 資料庫 > PostgreSQL 9.1 飛升之路

PostgreSQL 9.1 飛升之路

2022-07-14 09:20:42 資料庫

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 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;"

注意事項

  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

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/499143.html

標籤：PostgreSQL

上一篇：PostgreSQL 的視窗函式 OVER, WINDOW, PARTITION BY, RANGE

下一篇：PostgreSQL的查詢技巧: 零除, GENERATED STORED, COUNT DISTINCT, JOIN和陣列LIKE

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C＃(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • GPU虛擬機創建時間深度優化

    **?桔妹導讀：**GPU虛擬機實體創建速度慢是公有云面臨的普遍問題，由于通常情況下創建虛擬機屬于低頻操作而未引起業界的重視，實際生產中還是存在對GPU實體創建時間有苛刻要求的業務場景。本文將介紹滴滴云在解決該問題時的思路、方法、并展示最終的優化成果。 從公有云服務商那里購買過虛擬主機的資深用戶，一 ......

    uj5u.com 2020-09-10 06:09:13 more
  • 可編程網卡芯片在滴滴云網路的應用實踐

    **?桔妹導讀：**隨著云規模不斷擴大以及業務層面對延遲、帶寬的要求越來越高，采用DPDK 加速網路報文處理的方式在橫向縱向擴展都出現了局限性。可編程芯片成為業界熱點。本文主要講述了可編程網卡芯片在滴滴云網路中的應用實踐，遇到的問題、帶來的收益以及開源社區貢獻。 #1. 資料中心面臨的問題 隨著滴滴 ......

    uj5u.com 2020-09-10 06:10:21 more
  • 滴滴資料通道服務演進之路

    **?桔妹導讀：**滴滴資料通道引擎承載著全公司的資料同步，為下游實時和離線場景提供了必不可少的源資料。隨著任務量的不斷增加，資料通道的整體架構也隨之發生改變。本文介紹了滴滴資料通道的發展歷程，遇到的問題以及今后的規劃。 #1. 背景 資料，對于任何一家互聯網公司來說都是非常重要的資產，公司的大資料 ......

    uj5u.com 2020-09-10 06:11:05 more
  • 滴滴AI Labs斬獲國際機器翻譯大賽中譯英方向世界第三

    **桔妹導讀：**深耕人工智能領域，致力于探索AI讓出行更美好的滴滴AI Labs再次斬獲國際大獎，這次獲獎的專案是什么呢？一起來看看詳細報道吧！ 近日，由國際計算語言學協會ACL（The Association for Computational Linguistics）舉辦的世界最具影響力的機器 ......

    uj5u.com 2020-09-10 06:11:29 more
  • MPP (Massively Parallel Processing)大規模并行處理

    1、什么是mpp？ MPP (Massively Parallel Processing)，即大規模并行處理，在資料庫非共享集群中，每個節點都有獨立的磁盤存盤系統和記憶體系統，業務資料根據資料庫模型和應用特點劃分到各個節點上，每臺資料節點通過專用網路或者商業通用網路互相連接，彼此協同計算，作為整體提供 ......

    uj5u.com 2020-09-10 06:11:41 more
  • 滴滴資料倉庫指標體系建設實踐

    **桔妹導讀：**指標體系是什么？如何使用OSM模型和AARRR模型搭建指標體系？如何統一流程、規范化、工具化管理指標體系？本文會對建設的方法論結合滴滴資料指標體系建設實踐進行解答分析。 #1. 什么是指標體系 ##1.1 指標體系定義 指標體系是將零散單點的具有相互聯系的指標，系統化的組織起來，通 ......

    uj5u.com 2020-09-10 06:12:52 more
  • 單表千萬行資料庫 LIKE 搜索優化手記

    我們經常在資料庫中使用 LIKE 運算子來完成對資料的模糊搜索，LIKE 運算子用于在 WHERE 子句中搜索列中的指定模式。 如果需要查找客戶表中所有姓氏是“張”的資料，可以使用下面的 SQL 陳述句： SELECT * FROM Customer WHERE Name LIKE '張%' 如果需要 ......

    uj5u.com 2020-09-10 06:13:25 more
  • 滴滴Ceph分布式存盤系統優化之鎖優化

    **桔妹導讀：**Ceph是國際知名的開源分布式存盤系統，在工業界和學術界都有著重要的影響。Ceph的架構和演算法設計發表在國際系統領域頂級會議OSDI、SOSP、SC等上。Ceph社區得到Red Hat、SUSE、Intel等大公司的大力支持。Ceph是國際云計算領域應用最廣泛的開源分布式存盤系統， ......

    uj5u.com 2020-09-10 06:14:51 more
  • es~通過ElasticsearchTemplate進行聚合~嵌套聚合

    之前寫過《es~通過ElasticsearchTemplate進行聚合操作》的文章，這一次主要寫一個嵌套的聚合，例如先對sex集合，再對desc聚合，最后再對age求和，共三層嵌套。 Aggregations的部分特性類似于SQL語言中的group by，avg，sum等函式,Aggregation ......

    uj5u.com 2020-09-10 06:14:59 more
  • 爬蟲日志監控 -- Elastc Stack（ELK）部署

    傻瓜式部署，只需替換IP與用戶 導讀： 現ELK四大組件分別為：Elasticsearch（核心）、logstash（處理）、filebeat（采集）、kibana（可視化） 下載均在https://www.elastic.co/cn/downloads/下tar包，各組件版本最好一致，配合fdm會 ......

    uj5u.com 2020-09-10 06:15:05 more
最新发布
  • day02-2-商鋪查詢快取

    功能02-商鋪查詢快取 3.商鋪詳情快取查詢 3.1什么是快取？ 快取就是資料交換的緩沖區（稱作Cache），是存盤資料的臨時地方，一般讀寫性能較高。 快取的作用： 降低后端負載 提高讀寫效率，降低回應時間 快取的成本： 資料一致性成本 代碼維護成本 運維成本 3.2需求說明 如下，當我們點擊商店詳 ......

    uj5u.com 2023-04-20 08:33:24 more
  • MySQL中binlog備份腳本分享

    關于MySQL的二進制日志（binlog），我們都知道二進制日志（binlog）非常重要，尤其當你需要point to point災難恢復的時侯，所以我們要對其進行備份。關于二進制日志（binlog)的備份,可以基于flush logs方式先切換binlog，然后拷貝&壓縮到到遠程服務器或本地服務器 ......

    uj5u.com 2023-04-20 08:28:06 more
  • day02-短信登錄

    功能實作02 2.功能01-短信登錄 2.1基于Session實作登錄 2.1.1思路分析 2.1.2代碼實作 2.1.2.1發送短信驗證碼 發送短信驗證碼： 發送驗證碼的介面為：http://127.0.0.1:8080/api/user/code?phone=xxxxx<手機號> 請求方式：PO ......

    uj5u.com 2023-04-20 08:27:27 more
  • 快取與資料庫雙寫一致性幾種策略分析

    本文將對幾種快取與資料庫保證資料一致性的使用方式進行分析。為保證高并發性能，以下分析場景不考慮執行的原子性及加鎖等強一致性要求的場景，僅追求最終一致性。 ......

    uj5u.com 2023-04-20 08:26:48 more
  • sql陳述句優化

    問題查找及措施 問題查找 需要找到具體的代碼，對其進行一對一優化，而非一直把關注點放在服務器和sql平臺 降低簡化每個事務中處理的問題，盡量不要讓一個事務拖太長的時間 例如檔案上傳時，應將檔案上傳這一步放在事務外面 微軟建議 4.啟動sql定時執行計劃 怎么啟動sqlserver代理服務-百度經驗 ......

    uj5u.com 2023-04-20 08:26:35 more
  • 云時代，MySQL到ClickHouse資料同步產品對比推薦

    ClickHouse 在執行分析查詢時的速度優勢很好的彌補了MySQL的不足，但是對于很多開發者和DBA來說，如何將MySQL穩定、高效、簡單的同步到 ClickHouse 卻很困難。本文對比了 NineData、MaterializeMySQL（ClickHouse自帶）、Bifrost 三款產品... ......

    uj5u.com 2023-04-20 08:26:29 more
  • sql陳述句優化

    問題查找及措施 問題查找 需要找到具體的代碼，對其進行一對一優化，而非一直把關注點放在服務器和sql平臺 降低簡化每個事務中處理的問題，盡量不要讓一個事務拖太長的時間 例如檔案上傳時，應將檔案上傳這一步放在事務外面 微軟建議 4.啟動sql定時執行計劃 怎么啟動sqlserver代理服務-百度經驗 ......

    uj5u.com 2023-04-20 08:25:13 more
  • Redis 報”OutOfDirectMemoryError“（堆外記憶體溢位)

    Redis 報錯“OutOfDirectMemoryError（堆外記憶體溢位) ”問題如下： 一、報錯資訊： 使用 Redis 的業務介面 ，產生 OutOfDirectMemoryError（堆外記憶體溢位），如圖： 格式化后的報錯資訊： { "timestamp": "2023-04-17 22: ......

    uj5u.com 2023-04-20 08:24:54 more
  • day02-2-商鋪查詢快取

    功能02-商鋪查詢快取 3.商鋪詳情快取查詢 3.1什么是快取？ 快取就是資料交換的緩沖區（稱作Cache），是存盤資料的臨時地方，一般讀寫性能較高。 快取的作用： 降低后端負載 提高讀寫效率，降低回應時間 快取的成本： 資料一致性成本 代碼維護成本 運維成本 3.2需求說明 如下，當我們點擊商店詳 ......

    uj5u.com 2023-04-20 08:24:03 more
  • day02-短信登錄

    功能實作02 2.功能01-短信登錄 2.1基于Session實作登錄 2.1.1思路分析 2.1.2代碼實作 2.1.2.1發送短信驗證碼 發送短信驗證碼： 發送驗證碼的介面為：http://127.0.0.1:8080/api/user/code?phone=xxxxx<手機號> 請求方式：PO ......

    uj5u.com 2023-04-20 08:23:11 more

Copyright © 2010-2020 有解無憂