版本升级

达梦数据库产品注重向下兼容性,虽然版本不断地更新升级,但在绝大多数情况下,使用高版本的执行码启动低版本的数据库时,会自动执行一系列更新升级动作。对于待升级的数据库,用户只需要保证它之前是正常退出的即可。

在数据库升降级操作前,建议先进行数据备份。

本章节中的升级步骤,是基于待升级的老库版本号等于或者高于V7.1.6.11的前提来写的。需要注意的是,DM进行的三项较大的功能改进(V8.1.1.15开始支持RLOG_PKG日志格式、V8.1.1.101开始支持回滚管理段、V8.1.1.171开始调整了数据页格式),使得待升级的库在跨这三个版本进行升级时需要进行额外的升级操作,下面进行详细的说明。

9.1 日志格式升级

从V8.1.1.15版本开始,DM对REDO日志格式进行了升级,与老的日志格式不兼容,因此要求数据库在执行升级操作前,必须是使用之前版本的执行码执行正常退出后的库,以此来保证所有数据都已经刷盘,否则使用新版本的执行码启动数据库时,无法根据老的REDO日志对故障重启的数据库执行重做REDO日志、归档文件修复等动作,无法正常完成数据库升级。

9.1.1 版本说明

支持DM7、DM8老版本的库升级到V8.1.1.15或更高的数据库版本。

DM8老版本的库正常退出后,允许直接启动升级到V8.1.1.15或者更高版本的DM8,但必须要严格遵守9.1.2 升级步骤中的升级步骤。

DM7老版本的库,针对不同版本有一些升级限制,具体说明如下:

● V7.1.6.11之后的版本(包括V7.1.6.11)

允许直接启动升级到V8.1.1.15或者更高版本的DM8,同样也需要严格遵守升级步骤。

● 低于V7.1.6.11的版本

需要先升级到V7.6.0.183或者更高版本的DM7,对日志版本号进行升级,然后才允许升级到V8.1.1.15或者更高版本的DM8。需要注意的是,V7.1.5.125以及更低版本的库,如果打开了日志加密,则不再支持升级到V8.1.1.15或更高的数据库版本。

低于V7.1.6.11的版本需要升级两次,这两次版本升级的步骤是完全相同的,“升级到V7.6.0.183或者更高版本的DM7”的步骤可以参考下文中描述的升级步骤,只是将升级步骤中的版本号替换为“V7.6.0.183或者更高版本的DM7”。

9.1.2 升级步骤

数据守护版本号从V1.0开始,目前已经支持到V4.0,如果是只升级到V3.0或者V3.0之前的版本,配置文件和dmwatcher.ctl控制文件都可以向下兼容,REDO日志格式也可以兼容,操作相对比较简单,这里不再对其进行说明。

此处只对升级到V4.0的操作步骤进行说明,V4.0取消了dmwatcher.ctl控制文件的大部分功能,将其转移到SYSOPENHISTORY系统表上,守护进程的判断逻辑也随之做了较大改动,因此升级到V4.0时需要严格按照本文说明的操作步骤执行,否则升级过程中可能会出现守护进程或者监视器异常。

在执行升级步骤之前,需要特别注意以下几项说明:

  1. V4.0和V3.0的数据库REDO日志格式不兼容,因此要求数据库在执行升级操作之前,必须是使用之前版本的服务器执行码按照数据守护的退出顺序正常退出的库,包括主库和备库,对DSC集群,要求所有节点都处于Ok状态并正常退出。
  2. 升级后老的归档日志文件不再可用,因此需要确保备库在升级前和主库的数据处于一致状态,否则升级完成后,主库无法再从老的归档文件中收集数据同步到备库上,这种情况下只能对升级后的主库进行备份,再还原到备库上。
  3. 升级后老的归档日志文件不再可用,因此必须在执行升级前先将归档日志文件全部从归档目录中移走,避免升级后再次降级时,误判归档日志文件不连续。
  4. 主备库在升级过程中,需要重建SYSOPENHISTORY系统表,备库通过重演REDO日志进行重建,在此期间守护进程、监视器无法获取到主备库有效的Open历史信息,有可能会出现强制退出,因此要求守护进程和监视器一定要放到最后启动,必须严格按照升级步骤执行。
  5. V4.0要求主备库的DB_MAGIC不能相同,升级前如果备库和主库的DB_MAGIC相同,则升级完成后主备库之间将无法正常同步数据,此时只能对升级后的主库进行备份,再还原到备库上完成升级。
  6. V4.0中异步备库的配置方式和V3.0不同,如果升级前有异步备库,升级后需要参考《DM8数据守护与读写分离集群V4.0》调整异步备库的配置方式。
  7. 如果升级中遇到操作不当导致备库没有同步升级,则可以先单独升级主库,对升级后的主库进行备份,再还原到备库上,完成备库升级。
  8. DSC数据守护的升级,同样要求所有节点都是Ok状态并正常退出,DM7不支持DSC数据守护,因此不涉及DCR Disk和Voting Disk的重新初始化。

数据守护环境必须严格按照升级步骤执行,否则升级过程无法正常完成。数据守护环境升级步骤如下:

  1. 确保主备库数据一致的情况下按照正确的退出顺序退出整个数据守护环境,包括主库、备库、守护进程和监视器。
  2. 手动修改主备库dm.ini中的ALTER_MODE_STATUS为1,如果是DSC集群,则每个节点的dm.ini都要修改。
  3. 使用V8.1.1.15或者更高版本的执行码,Mount方式启动所有主备库。
  4. 使用Disql强制Open所有备库,如果备库是DSC集群,则需要依次连接每个节点执行。
SQL> Alter database open force;

注意:备库必须在主库之前Open,否则备库无法重演主库升级产生的REDO日志,会导致备库无法完成升级。

  1. 使用Disql登录主库,依次执行以下语句,如果主库是DSC集群,则需要依次连接每个节点执行。

1)设置DSC备库的控制节点为归档目标节点。

如果不存在DSC备库,则可跳过此步骤,示例中的实例名是DSC备库的控制节点名称。

注意:DSC备库只有控制节点允许接收主库的REDO日志,因此此处的归档目标只能设置为DSC备库的控制节点,如果设置成普通节点,会导致DSC备库无法完成升级,用V8.1.1.15或者更高版本的执行码在未升级的DSC备库上执行操作可能会引发异常。

SQL> SP_SET_ARCH_STATUS('实例名', 0);

2)强制Open主库。

SQL> Alter database open force;
  1. 主备库全部Open完成后,可分别连接主备库查询是否都存在SYSOPENHISTORY表,验证主备库是否正确升级。

备库重演REDO日志可能有一定延时,可通过分别查询主备库的PKG_SEQ、LSN信息确认主备库数据一致的情况下,再查询备库上是否存在SYSOPENHISTORY系统表。

主备库数据一致的判断方式:备库重演到的PKG_SEQ为主库的GLOBAL_NEXT_SEQ减1,APPLY_LSN和主库的FILE_LSN相同,DB_MAGIC相同。如果不满足此条件,则需要分别在主备库上重复多次查询,主库可能GLOBAL_NEXT_SEQ和FILE_LSN还在增长,不一定第一次查询就能满足条件,如果查询结果确实无法匹配,只要能观察到备库的重演PKG_SEQ和APPLY_LSN在随主库增长,就可以尝试查询是否存在SYSOPENHISTORY表。

查询主库:

SQL> SELECT DB_MAGIC, GLOBAL_NEXT_SEQ, FILE_LSN FROM V$RLOG;

行号    DB_MAGIC  GLOBAL_NEXT_SEQ   FILE_LSN

………………………………………………………………………………………………………………………………………………………………………

1     460099052  4427         106610

 
SQL>SELECT * FROM SYSOPENHISTORY;

查询备库:

SQL> SELECT P_DB_MAGIC, PKG_SEQ_ARR, APPLY_LSN_ARR FROM V$RAPPLY_LSN_INFO;

行号    P_DB_MAGIC      PKG_SEQ_ARR APPLY_LSN_ARR

………………………………………………………………………………………………………………………………………………………………………

1     460099052      (4426)   (106610)


SQL>SELECT * FROM SYSOPENHISTORY;

执行到这个步骤,主库已经升级完成,如果备库上没有查到SYSOPENHISTORY系统表信息,或者查询动态视图时备库出现异常退出情况,则说明备库没有升级成功,有可能是前面执行的升级步骤不对,或者备库DB_MAGIC和主库相同,或者备库升级前和主库数据不完全一致导致无法同步数据,这种情况下,只能正常退出主库和所有备库,对主库进行备份后再还原到备库上,完成备库升级,然后从步骤(9)开始继续执行。

  1. 在步骤6查询结果正确的情况下,正常退出主库。
  2. 正常退出所有备库。
  3. 重新修改主备库dm.ini中的ALTER_MODE_STATUS为0,如果是DSC集群,则每个节点的dm.ini都要修改。
  4. 使用V8.1.1.15或者更高版本的执行码,Mount方式启动所有主备库。
  5. 启动所有主备库本地的守护进程。
  6. 启动监视器。

至此,整个数据守护环境升级完成,可以通过执行监视器show命令观察守护系统是否运行正常,主备库如果都运行在Open状态,则说明升级成功。

如果升级过程中遇到服务器、守护进程或者监视器异常退出,说明没有严格按照上述的升级步骤执行,此时主备库数据可能已经不一致,如果要继续完成升级,只能先单独将主库升级完成,再备份还原到备库上。

单独升级主库,再备份还原到备库的执行步骤如下:

  1. 使用V8.1.1.15或者更高版本的执行码,Mount方式启动主库。
  2. 依次执行以下语句Open主库。

如果主库是DSC集群,则需要依次连接每个节点执行。

SQL> SP_SET_ALL_ARCH_STATUS(1);

SQL> SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1);

SQL> ALTER DATABASE OPEN FORCE;

SQL> SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);
  1. 正常退出主库,完成主库升级。
  2. 对主库进行脱机备份,再重新还原到备库上。
  3. 使用V8.1.1.15或者更高版本的执行码,Mount方式启动所有主备库。
  4. 启动所有主备库本地的守护进程。
  5. 启动监视器。

至此,整个数据守护环境升级完成,可以通过执行监视器show命令观察守护系统是否运行正常,主备库如果都运行在Open状态,则说明升级成功。

9.2 回滚管理段升级

DM从V8.1.1.101版本开始支持回滚管理段,用于存放事务信息,在系统故障重启或者DSC故障处理时,通过扫描回滚管理段收集事务信息,以达到缩减事务收集时长的目的。

此版本增加了一个建库参数(PSEG_MGR_FLAG)表示是否仅使用回滚管理段记录事务信息,取值0、1,默认为0。取值含义说明如下:

● 0:除了使用回滚管理段记录事务信息外,在事务的首个回滚页上也记录事务信息。

● 1:仅使用回滚管理段记录事务信息,事务的首个回滚页上不再记录。

老版本的库升级时,一律采用PSEG_MGR_FLAG=0的方式进行升级,老版本库在升级时会自动创建回滚管理段,升级成功后,不允许再使用老执行码启动升级后的库。

9.2.1 版本说明

具体的升级版本限制说明如下:

● 升级前的老版本库是DM8,版本号等于或者高于V8.1.1.15

老版本库已支持升级后的日志格式,本次升级仅需要升级回滚管理段。

● 升级前的老版本库是DM8,版本号低于V8.1.1.15;或者升级前的老版本库是DM7

老版本库不支持升级后的日志格式,本次升级需要先升级日志格式,再升级回滚管理段。

对这个版本范围的老版本库,升级前首先需要满足9.1 日志格式升级的各项升级条件,然后还要满足回滚管理段的升级条件才能升级。

9.2.2 升级步骤

回滚管理段的升级必须满足以下两个条件:

  1. 要求升级前按照顺序正常退出整个数据守护环境,退出前主备库必须都是Open状态。
  2. 如果有DSC集群,则要求升级前不存在故障节点,并且所有节点均正常退出。

如果老库已支持升级后的日志格式(版本号等于或者高于V8.1.1.15),在满足这两个条件之后,直接使用V8.1.1.101或者更高版本的执行码启动整个数据守护环境(启动顺序没有严格要求,主备库的dmserver、dmwatcher、dmmonitor全部正常启动即可),主备库都能够正常Open、守护进程都处于Open状态、备库归档状态有效则说明升级成功。

需要注意的是,如果老库升级前已支持升级后的日志格式(版本号等于或者高于V8.1.1.15),则本次回滚管理段升级前后的日志格式是兼容的,因此不要求升级前备库和主库数据一致,也就是不要求备库归档状态有效,回滚管理段升级完成后,主库仍然可以正常同步日志到备库。

如果老库还未支持升级后的日志格式,则需要同时满足日志格式和回滚管理段的升级条件,具体执行升级时,要根据老库当前的版本号,严格按照9.1 日志格式升级中的方式进行升级,只需要将其中的V8.1.1.15替换为V8.1.1.101即可,V8.1.1.101可以同时完成日志格式和回滚管理段的升级。

9.3 数据页格式升级

DM从V8.1.1.171版本开始将修改数据页的节点信息(FRESH_EP)持久化到了数据页上,相应的对数据页上的页类型字段长度进行了缩减,同时将库版本号(DB_VERSION)由0x0007000B升级到了0x0007000C。

新增的FRESH_EP字段主要用在DMDSC集群中,通过持久化的方式能够准确获取到修改数据页的前序节点,从而能够构建出正确的日志包依赖关系,以准确检测到是否存在日志缺失,解决备库重演卡住或者重演超时主动关闭等一系列问题。

特别要说明的是,对DMDSC集群、DMDSC集群的备库、DMDSC集群还原恢复后的库,升级成功后不支持再回退到升级前的版本。

9.3.1 版本说明

具体的升级版本限制说明如下:

● 升级前的老版本库是DM8,版本号等于或者高于V8.1.1.101

老版本库已支持升级后的日志格式和回滚管理段,本次升级仅需要升级数据页格式。

● 升级前的老版本库是DM8,版本号等于或者高于V8.1.1.15

老版本库已支持升级后的日志格式,本次升级需要同时完成回滚管理段和数据页格式两项升级内容,因此升级前需要同时满足“9.2回滚管理段升级”和“9.3数据页格式升级”的各项升级条件才能够升级成功。

● 升级前的老版本库是DM8,版本号低于V8.1.1.15;或者升级前的老版本库是DM7

老版本库不支持升级后的日志格式,本次升级需要完成日志格式、回滚管理段和数据页格式三项升级内容。因此对这个版本范围的老版本库,升级前需要同时满足9.1 日志格式升级和“9.2回滚管理段升级”以及“9.3数据页格式升级”的各项升级条件才能够升级成功。

9.3.2 升级步骤

本小节内容仅适用于老库版本号等于或者高于V8.1.1.101的情况,如果是更低版本的老库升级,则需要同时参考9.1和9.2小节内容。

数据页格式的升级必须满足以下条件:

  1. 要求升级前按照正常的退出顺序退出整个数据守护环境,退出前主备库必须都是Open状态。
  2. 如果升级前的数据守护环境中没有DMDSC集群,则升级前不要求主备库数据完全一致(单节点环境下,日志包不存在依赖关系,不会影响到归档连续性校验),但是要求主备库必须都正常退出。
  3. 如果升级前的数据守护环境中包含有DMDSC集群,则升级前要求主备库数据必须完全一致(避免升级完成后使用到升级前的归档日志,无法准确判断日志依赖关系,引发备库重演卡住等问题),同时要求DMDSC集群升级前不存在故障节点,并且所有节点均正常退出。

满足以上条件后,直接使用V8.1.1.171或者更高版本的执行码启动整个数据守护环境(主备库启动顺序没有严格要求),主备库都能够正常Open、守护进程都处于Open状态、备库归档状态有效则说明升级成功。

注意,本次升级完成后,对DMDSC集群、DMDSC集群的备库、DMDSC集群还原恢复后的库,不允许再回退到升级前的版本。

微信扫码
分享文档
扫一扫
联系客服