Home

DB2 DPF 跨机器重定向还原迁移

1191字 预计阅读时间：6分钟 数据库

这篇文章记录 DB2 DPF 环境在跨机器迁移时，如何通过“联机备份 + 重定向还原 + 日志前滚”的方式完成数据库恢复。它适合目标集群节点布局已经变化，但仍希望把原数据库完整迁移过去的场景。

实验环境

  • 源环境 A：db2dpfa，承载节点 0-7
  • 目标机器 B：承载节点 0-3，其中 Node 0 为编目节点
  • 目标机器 C：承载节点 4-7
  • 数据库名：GXCXXTDB

整体迁移思路

整个过程可以分成 5 个阶段：

  1. 在源端做联机备份并传输备份文件
  2. 在目标端准备 db2nodes.cfg 和基础目录
  3. 做重定向还原
  4. 提取联机备份日志并执行前滚
  5. 验证数据库状态和业务数据

第一阶段：源端备份与文件传输

1. 执行联机备份

源端可以使用同步或异步两种方式备份，文中的建议是更偏向第二种异步方式。

# 同步方式
db2 "BACKUP DATABASE GXCXXTDB ON ALL DBPARTITIONNUMS ONLINE TO /db2data/backup COMPRESS INCLUDE LOGS"
# 异步方式
db2_all "db2 BACKUP DB GXCXXTDB ONLINE TO /db2data/backup COMPRESS INCLUDE LOGS"

2. 分发备份文件

把不同节点生成的备份文件按目标机器实际承载关系拷贝过去。

例如：

scp /db2data/backup/GXCXXTDB.0.db2inst1.NODE000{0,1,2,3}.CATN0000.*.001 db2dpfa:/db2data/backup
scp /db2data/backup/GXCXXTDB.0.db2inst1.NODE000{4,5,6,7}.CATN0000.*.001 db2dpfb:/db2data/backup

这里的关键不是“拷过去就行”，而是要保证每个逻辑节点的备份文件最终落在正确的目标物理机器上。

第二阶段：目标端基础配置

1. 修改 db2nodes.cfg

目标端两台机器都要同步调整 ~/sqllib/db2nodes.cfg，让逻辑节点和新的物理节点关系匹配。

0 db2dpfb 0
1 db2dpfb 1
2 db2dpfb 2
3 db2dpfb 3
4 db2dpfc 0
5 db2dpfc 1
6 db2dpfc 2
7 db2dpfc 3

2. 确认 SSH 免密

db2_all 后面会大量依赖跨节点执行命令，因此 db2inst1 用户在两台机器之间必须能免密登录。

第三阶段：执行重定向还原

1. 先生成重定向脚本

在目标集群的编目节点上执行：

db2 RESTORE DB GXCXXTDB FROM /db2data/backup TAKEN AT 20260204165528 REDIRECT GENERATE SCRIPT my_restore.sql

这里的时间戳一定要以 Node 0 的备份时间戳为准。特别是在异步备份时，各节点时间戳可能并不完全一致。

2. 编辑重定向脚本

这一步是整个迁移里最容易出错的地方，重点检查：

  • 表空间容器路径是否要改
  • 新路径在目标端两台机器上是否真实存在
  • db2inst1 是否对新路径有写权限
  • NEWLOGPATH 是否指向了正确的目标日志目录

如果需要提前准备日志目录，可以这样批量创建：

db2_all 'mkdir -p /share/db2inst1/db2inst1/NODE000$DB2NODE/SQL00002/SQLOGDIR/'
db2_all 'chown -R db2inst1:db2iadm1 /share/db2inst1'
db2_all 'ls -d /share/db2inst1/db2inst1/NODE000$DB2NODE/SQL00002/SQLOGDIR/'

3. 先恢复 Node 0

在目标编目节点执行：

db2 -tvf my_restore.sql

只要看到重定向脚本里的 RESTORE DATABASE ... CONTINUE 成功，通常就说明 Node 0 已经打通。

4. 并行恢复其余节点

剩余节点可以通过 db2_all 触发：

db2_all "<<-0< db2 RESTORE DB GXCXXTDB FROM /db2data/backup NEWLOGPATH /share/db2inst1/db2inst1/NODE000\$DB2NODE/SQL00002/SQLOGDIR/ WITHOUT PROMPTING"

第四阶段：日志提取与前滚

由于使用的是联机备份，恢复后数据库会处于 Rollforward Pending 状态。

1. 为每个节点准备日志目录

db2_all "mkdir -p /db2data/backup/logs/node\$DB2NODE"

2. 从备份集中提取日志

db2_all "db2 RESTORE DB GXCXXTDB LOGS FROM /db2data/backup LOGTARGET /db2data/backup/logs/node\$DB2NODE WITHOUT PROMPTING"

3. 把日志放回活动日志目录

db2_all "cp /db2data/backup/logs/node\$DB2NODE/S*.LOG /share/db2inst1/db2inst1/NODE000\$DB2NODE/SQL00002/SQLOGDIR/"

这里一定要先核对数据库配置和日志路径，不要凭印象写目录，否则很容易前滚失败。

4. 执行全库前滚

在 Node 0 发起：

db2 "ROLLFORWARD DATABASE GXCXXTDB TO END OF LOGS AND STOP"

第五阶段：验证结果

1. 激活数据库

db2_all "db2 activate db GXCXXTDB"

2. 检查表空间状态

db2 "SELECT DBPARTITIONNUM, TBSP_NAME, TBSP_STATE FROM TABLE(MON_GET_TABLESPACE('',-2)) ORDER BY DBPARTITIONNUM"

正常情况下，所有分区上的表空间状态都应该恢复到 NORMAL。

3. 验证业务数据

db2 "SELECT DBPARTITIONNUM(ID) AS NODE_ID, COUNT(*) AS ROW_COUNT FROM MIGRATE_TEST GROUP BY DBPARTITIONNUM(ID) ORDER BY NODE_ID"

常见坑点

SQL1035N

如果数据库还在使用中，就会影响还原或日志提取。操作前务必先确认：

  • db2 force applications all
  • db2 deactivate db

SQL2542N

这类问题通常和备份时间戳或文件实际存放位置不匹配有关。尤其是 DPF 环境里，节点和机器映射关系错了就会直接失败。

\$DB2NODE 变量展开错误

在 db2_all 中使用时，必须做转义，否则变量会在本地 Shell 先被错误展开。

总结

这类 DPF 跨机器迁移，真正难的地方不是单条命令，而是三件事要同时对齐：

  1. 节点与机器映射
  2. 表空间与日志路径
  3. 联机备份后的日志恢复链路

只要这三层关系没配错，重定向还原本身就会顺很多。

数据库