PG数据库升级步骤说明(pg_dumpall和pg_upgrade)

简介:

一、数据库升级9.4到9.5


1.pg_dump导入导出(数据量不大时使用)

postgres用户登录

$ pg_dumpall > db_export.out


$ env|grep LANG

LANG=en_US.UTF-8



如果数据库字符集为en_US.UTF-8,系统字符集为zh_CN.UTF-8


导入步骤为

postgres用户登录

$export LANG=en_US.UTF-8

$psql -f db_export.out postgres


2.pg_upgrade(pg_upgrade方式)

升级版本:9.4 --》9.5

升级前提:9.4数据库中有完整数据,9.5安装完成后仅需要initdb就可以


1)升级前一致性检查


postgres用户登录执行以下命令:

[root@pgdb01 pgdata]# su - postgres

[postgres@pgdb01 ~]$ pwd

/home/postgres


使用9.5新版本bin路径的pg_upgrade执行检查。


[postgres@pgdb01 ~]$ /opt/pg/9.5/bin/pg_upgrade -c -d /pgdata94 -D /pgdata -b /opt/pg/9.4/bin -B /opt/pg/9.5/bin

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 presence of required libraries                 ok

Checking database user is the install user                  ok

Checking for prepared transactions                          ok


*Clusters are compatible*

[postgres@pgdb01 ~]$

 

2).执行升级


升级方式:复制数据文件方式,9.4旧版本PGDATA中数据复制到9.5新版本PGDATA,执行速度慢,两个数据目录独立,保存双份数据;

          硬链接方式,升级时命令行加上--link参数,不复制数据仅建立连接,执行速度快,仅保存一份数据。


(注意:两个数据库执行这个步骤时,全部为停止状态)


[postgres@pgdb01 ~]$ /opt/pg/9.5/bin/pg_upgrade -d /pgdata94 -D /pgdata -b /opt/pg/9.4/bin -B /opt/pg/9.5/bin

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

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

Copying old pg_multixact/offsets to new server              ok

Deleting files from new pg_multixact/members                ok

Copying old pg_multixact/members to new server              ok

Setting next multixact ID and offset for 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

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


Upgrade Complete

----------------

Optimizer statistics are not transferred by pg_upgrade so,

once you start the new server, consider running:

    ./analyze_new_cluster.sh


Running this script will delete the old cluster's data files:

    ./delete_old_cluster.sh

[postgres@pgdb01 ~]$


[postgres@pgdb01 ~]$ ll

total 1208

-rwx------. 1 postgres postgres     749 Apr  9 18:52 analyze_new_cluster.sh

-rwx------. 1 postgres postgres      30 Apr  9 18:52 delete_old_cluster.sh

[postgres@pgdb01 ~]$ 


3).使用新版本启动脚本启动数据库


[postgres@pgdb01 ~]$ exit

logout

[root@pgdb01 pgdata]# /etc/init.d/postgresql start

Starting PostgreSQL: ok

[root@pgdb01 pgdata]# su - postgres

[postgres@pgdb01 ~]$ psql

psql (9.5.2)

Type "help" for help.


postgres=# \l

                                      List of databases

        Name        |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges   

--------------------+----------+----------+-------------+-------------+-----------------------

 a_authentication   | vincent  | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 

 a_resources        | vincent  | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 

 postgres           | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 

 a_server           | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | postgres=CTc/postgres+

                    |          |          |             |             | =Tc/postgres         +

                    |          |          |             |             | acent=CTc/postgres

 template0          | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +

                    |          |          |             |             | postgres=CTc/postgres

 template1          | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | postgres=CTc/postgres+

                    |          |          |             |             | =c/postgres

a_security      | uccc     | UTF8     | en_US.UTF-8 | en_US.UTF-8 | a=CTc/uccc        +

                    |          |          |             |             | =Tc/uccc             +

                    |          |          |             |             | a=CTc/uccc

(7 rows)


postgres=# \q


4).生产新的统计数据


[postgres@pgdb01 ~]$ ./analyze_new_cluster.sh 

This script will generate minimal optimizer statistics rapidly

so your system is usable, and then gather statistics twice more

with increasing accuracy.  When it is done, your system will

have the default level of optimizer statistics.


If you have used ALTER TABLE to modify the statistics target for

any tables, you might want to remove them and restore them after

running this script because they will delay fast statistics generation.


If you would like default statistics as quickly as possible, cancel

this script and run:

    "/opt/pg/9.5/bin/vacuumdb" --all --analyze-only


vacuumdb: processing database "a_authentication": Generating minimal optimizer statistics (1 target)

vacuumdb: processing database "a_resources": Generating minimal optimizer statistics (1 target)

vacuumdb: processing database "postgres": Generating minimal optimizer statistics (1 target)

vacuumdb: processing database "a_server": Generating minimal optimizer statistics (1 target)

vacuumdb: processing database "template1": Generating minimal optimizer statistics (1 target)

vacuumdb: processing database "a_security": Generating minimal optimizer statistics (1 target)

vacuumdb: processing database "a_authentication": Generating medium optimizer statistics (10 targets)

vacuumdb: processing database "a_resources": Generating medium optimizer statistics (10 targets)

vacuumdb: processing database "postgres": Generating medium optimizer statistics (10 targets)

vacuumdb: processing database "a_server": Generating medium optimizer statistics (10 targets)

vacuumdb: processing database "template1": Generating medium optimizer statistics (10 targets)

vacuumdb: processing database "a_security": Generating medium optimizer statistics (10 targets)

vacuumdb: processing database "a_authentication": Generating default (full) optimizer statistics

vacuumdb: processing database "a_resources": Generating default (full) optimizer statistics

vacuumdb: processing database "postgres": Generating default (full) optimizer statistics

vacuumdb: processing database "a_server": Generating default (full) optimizer statistics

vacuumdb: processing database "template1": Generating default (full) optimizer statistics

vacuumdb: processing database "a_security": Generating default (full) optimizer statistics


Done

[postgres@pgdb01 ~]$ 


5).旧版本数据清理


可以在新数据库运行一段时间后,执行delete_old_cluster.sh 脚本,删除旧版本PGDATA目录

[postgres@pgdb01 ~]$ more delete_old_cluster.sh 

#!/bin/sh


rm -rf '/pgdata94'

[postgres@pgdb01 ~]$


本文转自 pgmia 51CTO博客,原文链接:http://blog.51cto.com/heyiyi/1762076


相关文章
|
3月前
|
Cloud Native 关系型数据库 分布式数据库
客户说|知乎基于阿里云PolarDB,实现最大数据库集群云原生升级
近日,知乎最大的风控业务数据库集群,基于阿里云瑶池数据库完成了云原生技术架构的升级。此次升级不仅显著提升了系统的高可用性和性能上限,还大幅降低了底层资源成本。
|
3月前
|
存储 关系型数据库 数据库
高性能云盘:一文解析RDS数据库存储架构升级
性能、成本、弹性,是客户实际使用数据库过程中关注的三个重要方面。RDS业界率先推出的高性能云盘(原通用云盘),是PaaS层和IaaS层的深度融合的技术最佳实践,通过使用不同的存储介质,为客户提供同时满足低成本、低延迟、高持久性的体验。
|
6月前
|
数据库
【YashanDB知识库】数据库升级后用yasboot在线扩充备节点出现报错
本文来自YashanDB官网,讨论从22.2.4.1升级至23.2.2.100过程中遇到的在线扩容问题。使用yasboot增加备节点时出现“no replication addr in node 1-1”错误,尽管数据库中存在相关配置。原因是早期托管功能未支持扩容,导致OM无法获取新库配置。提供两种规避方法:一是手动修改`cod_domor.db`信息并调整配置文件;二是手动安装YashanDB并配置备机。最终已向研发反馈,将在扩容时优化配置检查逻辑。
|
5月前
|
人工智能 关系型数据库 分布式数据库
让数据与AI贴得更近,阿里云瑶池数据库系列产品焕新升级
4月9日阿里云AI势能大会上,阿里云瑶池数据库发布重磅新品及一系列产品能力升级。「推理加速服务」Tair KVCache全新上线,实现KVCache动态分层存储,显著提高内存资源利用率,为大模型推理降本提速。
|
6月前
|
SQL 存储 关系型数据库
在PG数据库中,not in 和except的区别
在PG数据库中,not in 和except的区别
|
7月前
|
SQL 弹性计算 安全
【上云基础系列04】基于标准架构的数据库升级
本文回顾了业务上云从基础到进阶的理念,涵盖基础版和全栈版架构。在“入门级:上云标准弹性架构基础版”的基础上,本文针对数据库升级,重点介绍了高可用数据库架构的升级方案,确保数据安全和业务连续性。最后,附有详细的“上云标准弹性架构”演进说明,帮助用户选择合适的架构方案。
|
8月前
|
前端开发 Java 数据库连接
Java后端开发-使用springboot进行Mybatis连接数据库步骤
本文介绍了使用Java和IDEA进行数据库操作的详细步骤,涵盖从数据库准备到测试类编写及运行的全过程。主要内容包括: 1. **数据库准备**:创建数据库和表。 2. **查询数据库**:验证数据库是否可用。 3. **IDEA代码配置**:构建实体类并配置数据库连接。 4. **测试类编写**:编写并运行测试类以确保一切正常。
293 2
|
8月前
|
存储 Java 数据库连接
时序数据库TDengine 3.3.5.0 发布:高并发支持与增量备份功能引领新升级
TDengine 3.3.5.0 版本正式发布,带来多项更新与优化。新特性包括提升 MQTT 稳定性和高并发性能、新增 taosX 增量备份与恢复、支持 JDBC 和 Rust 连接器 STMT2 接口、灵活配置 Grafana Dashboard 等。性能优化涵盖查询内存管控、多级存储迁移、强密码策略等,全面提升时序数据管理的效率和可靠性。欢迎下载体验并提出宝贵意见。
215 5
|
10月前
|
SQL Oracle 关系型数据库
PLSQL还原DMP数据库的详细步骤
PLSQL还原DMP数据库的详细步骤
808 6
|
10月前
|
存储 缓存 网络安全
南大通用GBase 8s 数据库 RHAC集群基本原理和搭建步骤
南大通用GBase 8s 数据库 RHAC集群基本原理和搭建步骤

热门文章

最新文章