数据库教程FGMT57‑PostgreSQL数据库升级与迁移

## 前言与大纲介绍

数据库的生命周期运维工作中，版本升级与跨环境数据迁移属于高风险核心操作，业务系统能否持续稳定运行，很大程度取决于升级迁移方案设计、前置检查、操作执行以及回滚预案是否完备。PostgreSQL数据库在企业业务场景广泛落地，随着业务迭代、硬件更新、安全漏洞修复、架构重构等需求，数据库升级与迁移工作会频繁出现在运维排期之中。很多运维人员在执行升级迁移操作时，容易忽略预检查环节、参数适配、业务侧兼容性验证，直接执行操作，最终引发业务中断、数据损坏、对象丢失等重大故障。风哥教程本文，围绕PostgreSQL升级与迁移全流程技术体系展开讲解，覆盖方案选型、底层原理、实操步骤、校验方法、故障回滚，帮助数据库运维人员建立标准化的升级迁移实施流程，规避上线风险。

本套风哥教程整体内容分为四大模块，第一部分为本前言与大纲介绍，梳理全文学习框架与实验环境信息；第二部分为理论知识模块，讲解PostgreSQL升级分类、迁移技术分类、各类方案底层实现原理、适用场景与风险点；第三部分为核心实战操作模块，基于64G内存8CPU服务器硬件规格，在主机fgedu-net-cn1、fgedu-net-cn2完成多套升级、迁移场景落地，包含大量可直接复制执行的操作系统命令与SQL语句；第四部分为总结模块，梳理操作要点、常见坑点与运维规范。

本文实验环境基础信息：两台服务器主机名分别为fgedu-net-cn1、fgedu-net-cn2，操作系统采用Linux企业发行版，数据库实例名fgedudb，数据库用户名fgedu，数据存放根目录统一为/fgedudb，硬件规格统一配置64G内存、8CPU。所有数据库参数调优均基于该硬件规格设计，后续所有实战命令均适配/fgedudb目录路径，所有数据库对象使用fgedudb库、fgedu用户。在正式动手操作之前，风哥建议读者先完整阅读全部理论章节，充分理解不同升级迁移方案的优缺点，再动手执行实战步骤，避免盲目操作带来数据风险。

## 一、PostgreSQL升级与迁移理论基础

### 1.1 PostgreSQL升级分类定义

PostgreSQL升级主要划分为小版本升级与大版本升级两类，两类升级底层逻辑、操作复杂度、停机时长、风险等级存在巨大差异。小版本也叫补丁版本，版本号的最后一位数字发生变更，这类升级仅修复BUG、安全漏洞，**内部存储文件格式完全保持不变**，系统表结构、WAL日志格式、页面存储结构均不会改动。小版本升级核心特点：数据文件无需转换，升级操作简单，停机窗口短，风险较低。通常用于生产环境漏洞修复、稳定性缺陷修复，不需要改动业务应用代码，业务侧几乎无感知。

大版本升级是主版本号发生变更，大版本之间，PostgreSQL会对系统表、数据页存储结构、WAL日志格式、索引存储、内置函数行为进行调整，**新旧版本的数据文件无法直接兼容读取**，旧版本的数据文件不能直接在新版本实例启动加载。大版本升级操作复杂度更高，停机时间更长，需要严格的前置兼容性检查，部分场景业务应用需要少量适配改造。大版本升级常用实现手段包含pg_upgrade原地升级、逻辑导出导入迁移。

>风哥 itpux-com

原地升级，即在原有服务器主机上，保留原有数据，将数据库实例升级至目标版本，硬件主机不发生变更。迁移操作和升级操作存在区别，迁移侧重**数据跨主机、跨存储、跨机房搬迁**，版本可以保持不变，也可以迁移的同时同步完成版本升级。简单概括：升级是版本变更，迁移是数据位置变更，二者可以单独实施，也可以组合实施，也就是迁移+升级一体化方案。

### 1.2 pg_upgrade工具底层原理

pg_upgrade是PostgreSQL内置的大版本原地升级工具，其核心思路并不是直接改写全部原有数据文件，而是复用原有用户数据文件，只重建新版本对应的系统目录、系统表元数据，从而大幅缩短停机时间。pg_upgrade执行时，会对比新旧两个版本的系统对象元数据，验证数据页、WAL、数据类型、索引、扩展插件兼容性，确认兼容之后，将旧版本用户表、索引、序列、TOAST数据文件硬链接或者拷贝至新版本数据目录，再基于新版本模板重建系统表，不需要逐条读取表数据进行INSERT写入，这也是pg_upgrade对比逻辑导入导出速度优势巨大的根本原因。

pg_upgrade提供两种工作模式：拷贝模式与硬链接--link模式。拷贝模式会复制全部数据文件，原有旧版本数据完整保留，升级失败时回滚简单，但会占用双倍存储空间；硬链接模式使用文件系统硬链接指向原有数据文件，不额外占用大量磁盘空间，但是硬链接模式存在限制，升级完成执行清理旧库操作后，旧数据文件会被删除，回滚操作难度更高，一旦升级异常，如果没有提前做独立备份，会存在数据丢失风险，生产环境选择--link模式必须提前完成全量备份。

pg_upgrade前置检查项包含：操作系统用户权限、磁盘空间、扩展插件兼容性、系统表自定义类型、外部表、自定义函数、存储过程、触发器、索引类型、数据库编码、LC_COLLATE字符排序规则。字符集与排序规则不匹配是大版本升级最常见失败原因，排序规则一旦前后不一致，会导致索引顺序错乱，查询结果异常，该问题在升级完成后很难修复，所以预检查阶段必须重点校验。

### 1.3 PostgreSQL迁移技术体系

PostgreSQL数据迁移方案分为物理迁移与逻辑迁移两大类，两类方案底层原理、停机时间、适用场景各不相同。

物理迁移，直接迁移数据库底层的数据文件、WAL日志文件，物理层面复制数据库存储内容。物理迁移代表工具为pg_basebackup，也可以使用文件系统快照、存储快照完成物理拷贝。物理迁移的特点：迁移速度快，不解析SQL，不处理表记录，直接复制二进制数据，适合TB级大容量数据库；缺点是迁移前后数据库大版本必须保持一致，不能跨大版本迁移，迁移完成后目标实例和源实例完全一致，包含所有系统元数据。物理迁移常用于同版本跨主机搬迁、主备集群重建。

逻辑迁移，通过读取数据库逻辑对象，导出表、视图、函数、序列、权限、数据记录，再导入目标数据库，核心工具为pg_dump、pg_dumpall、pg_restore。逻辑迁移读取数据库的逻辑元数据与业务数据，生成SQL脚本或者自定义归档格式，导入目标实例重建全部对象。逻辑迁移优势：支持跨大版本迁移，支持对象过滤，可以只迁移部分库、部分表，能够在迁移过程中清理冗余对象，重建索引，消除存储碎片；缺点是数据量大的时候迁移耗时久，需要业务停机或者使用在线逻辑复制降低停机窗口，迁移过程中需要校验约束、触发器、外键，容易出现对象依赖报错。

>风哥教程 113257174

在线逻辑复制迁移，基于PostgreSQL逻辑复制插件，源库持续捕获WAL日志的DML变更，实时同步到目标数据库，前期完成全量逻辑数据初始化，同步追平增量数据后，再做业务切流。该方案最大优势是大幅缩短业务停机窗口，仅切换业务连接的几秒到几分钟停机，适合业务不能长时间停机的核心生产系统。逻辑复制的局限性：DDL语句不会自动同步，需要人工在目标端执行DDL；部分对象类型不支持同步，例如大对象、部分自定义数据类型，迁移前需要梳理业务对象清单。

### 1.4 升级迁移方案选型原则

风哥在大量生产实施案例中总结选型判断标准，第一看业务允许停机窗口；第二看数据库数据体量；第三看是否需要跨大版本；第四看是否需要过滤部分数据库对象；第五看磁盘存储资源；第六看业务应用兼容性。

如果仅小版本安全补丁更新，优先选择小版本升级，停机短，风险最低。大版本原地升级，数据库数据量巨大，业务停机窗口有限，磁盘充足可以考虑pg_upgrade拷贝模式；磁盘紧张，并且已经做独立全量备份，可评估硬链接模式。跨主机同时跨大版本迁移，可选逻辑导出导入，数据量大、业务不能长时间停机，优先逻辑复制在线迁移。仅同版本跨主机搬迁数据库，TB级海量数据，优先pg_basebackup物理迁移。

任何生产环境升级迁移，无论方案简单或者复杂，**必须搭建和生产环境一致的测试环境，完整演练全流程操作，包含故障回滚演练**。测试环境硬件配置尽量对齐生产，64G内存8CPU规格，参数配置和生产保持一致，演练中记录每一步耗时、报错，形成标准化操作手册，生产严格按照手册执行，禁止现场即兴操作。

### 1.5 64G内存8CPU实例基础参数理论说明

风哥教程本文所有实战环境数据库参数，均基于64G内存，8CPU服务器硬件规格进行配置，PostgreSQL内存参数设计原则，操作系统预留内存、共享内存、会话内存、WAL内存需要合理分配，避免内存溢出或者内存资源浪费。

shared_buffers：PostgreSQL专用数据缓冲区，64G服务器推荐设置为服务器物理内存的25%，也就是16GB，shared_buffers是数据库缓存数据页的核心内存区域。

work_mem：单条排序、哈希连接、哈希聚合操作使用内存，8CPU环境，业务并发不高场景设置64MB，高并发业务下调至32MB，work_mem是每个操作单独分配，不可设置过大，并发高时容易耗尽内存。

maintenance_work_mem：索引创建、VACUUM操作使用内存，推荐设置4GB，大表建索引时可以临时调大。

effective_cache_size：规划器估算可用缓存，推荐48GB，用于优化器选择索引扫描策略。

max_connections：最大连接数，默认偏大，生产建议设置500，搭配连接池使用。

wal_buffers：WAL缓冲区，设置16MB。

max_wal_size：WAL最大段文件大小，设置4GB。

min_wal_size：1GB。

checkpoint_completion_target：0.9，平滑检查点IO，降低业务IO抖动。

wal_level设置为replica，开启WAL日志输出，物理流复制、逻辑复制都依赖该参数。

>风哥数据库教程 itpux-com

## 二、PostgreSQL升级与迁移实战操作

### 2.1 实战环境准备与前置检查

实验环境主机：fgedu-net-cn1作为源数据库主机，fgedu-net-cn2作为目标迁移主机。两台服务器操作系统预先部署好依赖包，用户创建操作系统用户fgedudb，数据目录/fgedudb，目录权限严格管控。所有操作，数据库相关命令都使用fgedudb操作系统账号执行，禁止root账号直接启停数据库。

#### 2.1.1 操作系统层面环境检查，fgedu-net-cn1主机操作

登录fgedu-net-cn1主机，切换fgedudb用户

```bash

su - fgedudb

# 查看主机名校验

hostname

# 检查磁盘空间，/fgedudb挂载目录剩余空间

df -h /fgedudb

# 检查内存

free -h

# 检查CPU

lscpu

# 检查操作系统打开文件数限制

ulimit -n

# 检查进程最大数

ulimit -u

```

生产环境升级迁移前，磁盘剩余空间建议预留不少于当前数据库总容量的30%，如果使用pg_upgrade拷贝模式，需要预留100%空间，硬链接模式预留30%。ulimit参数如果过小，数据库启动失败或者大查询报错，需要修改limits.conf，修改后重新登录用户生效。

检查数据库实例状态

```bash

# 查看数据库进程

ps -ef|grep postgres

# 连接数据库查看版本，实例为fgedudb

psql -U fgedu -d fgedudb -p 5432

```

进入psql交互终端，执行一系列数据库内部预检查SQL

```sql

--查看数据库大小

SELECT pg_size_pretty(pg_database_size('fgedudb'));

--查看所有用户表、索引大小

SELECT relname,pg_size_pretty(pg_relation_size(relid)) FROM pg_stat_user_tables order by pg_relation_size(relid) desc limit 20;

--检查无效索引

SELECT schemaname,relname,indexrelname FROM pg_stat_user_indexes WHERE idx_scan=0;

--检查外键约束

SELECT conname,conrelid::regclass,confrelid::regclass FROM pg_constraint WHERE contype='f';

--检查自定义类型、枚举类型

SELECT typname FROM pg_type WHERE typisdefined;

--检查扩展插件

SELECT extname,extversion FROM pg_extension;

--查看排序规则

SELECT datcollate,datctype FROM pg_database WHERE datname='fgedudb';

```

网上搜索风哥教程可以学习全套数据库教程

这里需要重点记录扩展插件清单、排序规则，目标库必须安装相同扩展，排序规则必须完全一致，否则大版本升级会失败。预检查阶段，清理无效大索引、无效对象，提前删除无用测试表，减少升级迁移耗时。

#### 2.1.2 数据库全量备份操作，fgedu-net-cn1主机

无论升级还是迁移，**全量备份是不可跳过的强制操作**，备份文件存储在独立磁盘，不要放在/fgedudb数据盘。使用pg_dumpall导出全局对象（角色、表空间），pg_dump导出业务库fgedudb。

```bash

#导出全局账号权限

pg_dumpall -U fgedu -p 5432 > /fgedudb/backup/fgedudb_global.sql

#导出业务库，自定义归档压缩格式

pg_dump -U fgedu -d fgedudb -F c -f /fgedudb/backup/fgedudb_full.dump

```

备份完成，校验备份文件完整性，尝试在测试环境恢复备份，确认备份文件没有损坏。

### 2.2 PostgreSQL小版本升级实战（fgedu-net-cn1主机）

小版本升级，数据文件格式不变，操作流程：备份数据库→停止数据库进程→替换数据库二进制程序→启动数据库→执行升级校验。

1. 停止数据库实例，fgedudb用户执行

```bash

pg_ctl -D /fgedudb/fgedudb_data stop -m fast

```

-m fast模式，断开现有会话，回滚未提交事务，正常关闭数据库，生产环境优先使用fast，业务紧急故障场景才使用immediate。

2. 替换新版本PostgreSQL二进制安装文件，原有二进制程序备份

```bash

mv /fgedudb/pgsql /fgedudb/pgsql_old

#解压新版本二进制包到/fgedudb/pgsql目录

tar -zxvf pgsql-new.tar.gz -C /fgedudb/

#修改目录属主

chown -R fgedudb:fgedudb /fgedudb/pgsql

```

3. 配置环境变量，修改fgedudb用户.bash_profile，更新PATH指向新的bin目录

```bash

vi ~/.bash_profile

export PATH=/fgedudb/pgsql/bin:$PATH

source ~/.bash_profile

```

4. 启动数据库实例

```bash

pg_ctl -D /fgedudb/fgedudb_data start

```

5. 登录数据库校验版本，验证业务对象

```bash

psql -U fgedu -d fgedudb

SELECT version();

--检查表、索引、自定义类型、扩展插件是否正常访问

SELECT count(*) FROM test_table;

```

小版本升级不需要执行任何数据转换脚本，数据文件直接复用，升级完成后，执行VACUUM ANALYZE更新统计信息，优化执行计划。

```sql

VACUUM ANALYZE;

```

### 2.3 pg_upgrade原地大版本升级实战（fgedu-net-cn1主机）

上51CTO搜索风哥可以学习全套数据库教程

本场景在fgedu-net-cn1原地执行大版本升级，使用pg_upgrade工具，分为预检查、正式升级、升级后验证三个阶段。

1. 在主机部署新版本PostgreSQL二进制，创建新版本空数据目录，初始化新版本实例，注意初始化时字符集、排序规则必须和源库保持一致。

```bash

#新建新版本数据目录

mkdir -p /fgedudb/fgedudb_new_data

chown fgedudb:fgedudb /fgedudb/fgedudb_new_data

#初始化新实例

initdb -D /fgedudb/fgedudb_new_data -U fgedu --lc-collate="zh_CN.UTF-8" --lc-ctype="zh_CN.UTF-8" -E UTF8

```

2. 停止源数据库实例

```bash

pg_ctl -D /fgedudb/fgedudb_data stop -m fast

```

3. 执行pg_upgrade预检查，只做检查，不执行任何修改，这一步是生产环境强制操作

```bash

pg_upgrade -b /fgedudb/pgsql_old/bin -B /fgedudb/pgsql_new/bin \

-d /fgedudb/fgedudb_data -D /fgedudb/fgedudb_new_data \

-U fgedu --check

```

-b代表旧版本bin路径，-B新版本bin路径，-d旧数据目录，-D新数据目录。预检查输出报告，如果存在报错，必须全部修复，才能继续执行正式升级。

4. 预检查全部通过，执行正式升级，这里使用拷贝模式

```bash

pg_upgrade -b /fgedudb/pgsql_old/bin -B /fgedudb/pgsql_new/bin \

-d /fgedudb/fgedudb_data -D /fgedudb/fgedudb_new_data \

-U fgedu

```

如果磁盘空间不足，并且提前完成独立全量备份，可以增加--link参数使用硬链接模式。

```bash

pg_upgrade -b /fgedudb/pgsql_old/bin -B /fgedudb/pgsql_new/bin \

-d /fgedudb/fgedudb_data -D /fgedudb/fgedudb_new_data \

-U fgedu --link

```

升级脚本执行完成后，输出两个脚本，analyze_new_cluster.sh与delete_old_cluster.sh。

5. 切换数据目录，启动新版本数据库

```bash

#备份旧数据目录名称

mv /fgedudb/fgedudb_data /fgedudb/fgedudb_data_old

mv /fgedudb/fgedudb_new_data /fgedudb/fgedudb_data

#启动新版本实例

pg_ctl -D /fgedudb/fgedudb_data start

```

6. 执行analyze脚本，生成统计信息

```bash

sh ./analyze_new_cluster.sh

```

7. 升级后校验

```bash

psql -U fgedu -d fgedudb

SELECT version();

--校验所有业务表访问，约束，索引，函数，扩展

SELECT count(*) FROM fgedu.test_table;

SELECT extname FROM pg_extension;

```

业务验证全部确认正常，确认业务稳定运行一段时间之后，才可以执行delete_old_cluster.sh清理旧版本数据文件，**该脚本会删除旧库数据，执行前再次确认备份完好**。

### 2.4 pg_basebackup物理迁移实战，同版本迁移fgedu-net-cn1迁移至fgedu-net-cn2

物理迁移适合同版本数据库跨主机搬迁，源fgedu-net-cn1，目标fgedu-net-cn2，数据库版本保持不变。

1. fgedu-net-cn1源库配置，修改postgresql.conf开启wal_level=replica，pg_hba.conf增加目标主机访问权限，重载配置

```sql

SELECT pg_reload_conf();

```

2. fgedu-net-cn2目标主机，安装相同版本PostgreSQL二进制，创建/fgedudb目录，创建fgedudb操作系统用户

```bash

useradd fgedudb

mkdir -p /fgedudb/fgedudb_data

chown fgedudb:fgedudb /fgedudb/fgedudb_data

```

3. 在fgedu-net-cn2执行pg_basebackup拉取源库全量物理备份

```bash

su - fgedudb

pg_basebackup -h fgedu-net-cn1 -U fgedu -p 5432 -D /fgedudb/fgedudb_data -P -X stream

```

-P显示进度，-X stream流式传输WAL日志，保证备份一致性。备份完成，目标端生成完整数据目录。

4. 修改目标端postgresql.conf参数，按照64G内存8CPU规格配置shared_buffers=16GB，maintenance_work_mem=4GB等参数。

5. 目标主机启动数据库实例

```bash

pg_ctl -D /fgedudb/fgedudb_data start

```

6. 登录目标库校验数据，对比源库表行数、对象数量，确认数据完整。

### 2.5 逻辑导出导入迁移实战，跨版本迁移fgedu-net-cn1至fgedu-net-cn2

逻辑迁移，使用pg_dump + pg_restore，支持跨大版本迁移。

1. fgedu-net-cn1导出数据，前面已经演示pg_dumpall导出全局账号，pg_dump导出fgedudb库归档文件。

2. 将备份文件传输至fgedu-net-cn2主机

```bash

scp /fgedudb/backup/fgedudb_full.dump fgedudb@fgedu-net-cn2:/fgedudb/backup/

scp /fgedudb/backup/fgedudb_global.sql fgedudb@fgedu-net-cn2:/fgedudb/backup/

```

3. fgedu-net-cn2主机，部署目标版本数据库，初始化实例，创建数据库fgedudb。

```bash

createdb -U fgedu fgedudb

```

4. 先导入全局角色权限

```bash

psql -U fgedu -d postgres -f /fgedudb/backup/fgedudb_global.sql

```

5. 使用pg_restore导入业务库数据

```bash

pg_restore -U fgedu -d fgedudb /fgedudb/backup/fgedudb_full.dump

```

导入完成，核对表数量、记录数、索引、存储过程，排查导入报错日志，修复依赖问题。

### 2.6 逻辑复制在线迁移实战，业务低停机窗口方案

逻辑复制在线迁移，源fgedu-net-cn1，目标fgedu-net-cn2。

1. 源库postgresql.conf设置wal_level=logical，max_replication_slots=8，max_wal_senders=8，重启实例生效。

2. 创建逻辑复制发布端

```sql

--源库fgedu-net-cn1

CREATE PUBLICATION pub_fgedudb FOR ALL TABLES;

```

3. 目标库创建订阅，先执行全量逻辑初始化，然后持续同步增量WAL变更。

```sql

--目标库fgedu-net-cn2

CREATE SUBSCRIPTION sub_fgedudb

CONNECTION 'host=fgedu-net-cn1 port=5432 dbname=fgedudb user=fgedu'

PUBLICATION pub_fgedudb;

```

4. 持续监控复制延迟，追平数据，校验两边数据一致性。

```sql

--目标端查看订阅状态

SELECT subname,subenabled,last_msg_send_time,last_msg_receipt_time FROM pg_subscription;

```

数据完全同步，业务流量切换至目标主机，完成割接。

### 2.7 升级迁移后一致性校验与回滚操作

无论任何方案，迁移升级完成，必须执行多层校验。第一层：对象校验，表、视图、函数、序列、扩展、权限；第二层：数据行数校验，关键业务表count比对；第三层：业务接口测试，应用连接读写；第四层：性能压测，对比升级前后QPS、TPS、延迟指标。

回滚预案，小版本升级回滚：停止实例，恢复旧版本二进制程序，启动实例。pg_upgrade原地升级，如果没有使用--link模式，直接切换回旧数据目录启动旧版本实例；--link模式回滚依赖提前的逻辑全量备份，重新导入备份。逻辑迁移回滚：业务切回源库，保留源库实例不关闭，割接前源库持续对外提供服务，确认目标库稳定运行一段时间，再下线源库。物理迁移回滚，业务切回原有主机。风哥 itpux-com

## 三、风哥针对本文总结

风哥针对本文总结PostgreSQL升级迁移核心运维要点，升级迁移属于高危变更，所有操作遵循备份优先、测试先行、分步执行、留足回滚的原则。小版本升级风险最低，只修复漏洞，数据文件不变；大版本原地pg_upgrade升级可以大幅缩短停机时间，但是排序规则、扩展插件、自定义类型是高频失败点，必须完成预检查，硬链接模式要谨慎使用，清理旧数据不可恢复。

物理迁移使用pg_basebackup，迁移速度快，但是仅限同版本；逻辑导出导入支持跨版本，大数据场景耗时较长；逻辑复制在线迁移可以实现业务短停机割接，但DDL同步需要人工维护，存在对象类型限制。64G内存8CPU服务器参数配置，shared_buffers、work_mem、maintenance_work_mem等参数需要在升级迁移完成后，根据业务负载做二次微调，升级后必须更新统计信息，防止执行计划异常引发业务性能问题。风哥教程 113257174

实施流程规范：第一步，需求评估，方案选型；第二步，搭建测试环境完整演练，包含回滚演练；第三步，生产前置检查，清理无效对象，全量备份；第四步，执行升级或者迁移操作；第五步，数据一致性校验、业务功能验证；第六步，观察业务稳定运行，确认无异常，再清理旧环境；第七步，记录变更文档，归档操作日志、校验报告。风哥数据库教程 itpux-com

常见故障坑点：字符排序规则不一致导致升级失败；磁盘空间预估不足中途中断；ulimit资源限制导致数据库无法启动；忘记同步扩展插件，升级后对象访问报错；逻辑迁移对象依赖顺序问题，外键、视图导入报错；逻辑复制DDL变更没有同步，两端表结构不一致。网上搜索风哥教程可以学习全套数据库教程

数据库运维人员不要只停留在复制命令执行层面，需要理解底层存储原理，能够看懂报错日志，具备故障定位与快速回滚能力。变更操作所有步骤需要记录日志，每一步操作前后都做状态检查，一旦出现异常，立刻停止后续操作，启动回滚预案，优先保障业务数据安全。上51CTO搜索风哥可以学习全套数据库教程

风哥最后提醒，任何生产环境数据库变更，禁止无演练直接上线，风险评估、备份、回滚三者缺一不可，数据库升级迁移的核心目标，不只是完成版本更新或者数据搬迁，而是保障业务数据零丢失、业务中断时间可控。