记一次达梦DM8主备156到218版本升级报‘Upgrade is not allowed,please startup with origin dmserver and shutdown again

一、背景

        达梦数据库的版本升级基本步骤就是：①全库备份156旧版本的数据。②在另外一套新环境上安装156旧版本主备并进行还原。③停止新环境156旧版本主备集群。④替换新环境156版本dm8安装路径下的bin/整个文件夹为218新版本的bin/并覆盖。⑤启动218新版本达梦主备集群服务（若不涉及新环境，在旧环境直接升级的话，需要停完集群服务后替换完新BIN/启动集群即可。）

        那天晚上，基本是按照以上操作进行156到218升级操作，小伙伴执行第③步骤停止156版本集群的时候先关闭了备库实例而后再关闭的主库实例（即停集群4，5步骤反了），按照之前经验来说，监视器monitor和守护进程dmwatcher停止后，主备实例停止顺序可以不分先后能成功，但是照官方FAQ的却给出了明确的顺序，为何？后边我们具体说明为什么严格按照操作规范很重要，比如此次升级没按照顺序，恰好出问题了，当备库实例正常启动后，启动主库实例的时候恰好报错如下：

主库实例启动faild，Upgrade is not allowed,please startup with origin dmserver and shutdown again。

 附：

• 停集群：

1. 关闭监视器：systemctl stop DmMonitorServiceconfirm
2. 关闭主库守护进程：systemctl stop DmWatcherServicedmrw
3. 关闭备库守护进程：systemctl stop DmWatcherServicedmrw
4. 关闭主库实例：systemctl stop DmServicedmrw
5. 关闭备库实例：systemctl stop DmServicedmrw

• 启集群：

1. 启动主库实例：systemctl start DmServicedmrw
2. 启动备库实例：systemctl start DmServicedmrw
3. 启动主库守护进程：systemctl start DmWatcherServicedmrw
4. 启动备库守护进程：systemctl start DmWatcherServicedmrw
5. 启动监视器：systemctl start DmMonitorServiceconfirm

二、主备工作的基本原理

1、主备工作原理。

1、监视器monitor的作用

• 监控数据守护系统

        接收守护进程发送的消息，显示主、备数据库状态变化，以及故障切换过程中，数据库模式、状态变化的完整过程。

• 管理数据守护系统

        用户可以在监视器上输入命令，启动、停止守护进程的监控功能，执行主备库切换、备库故障接管等操作。

• 确认状态信息

        用于故障自动切换的数据守护系统中，主、备库进行故障处理之前，需要通过监视器进行信息确认，确保对应的备库或者主库是真的产生异常了，避免主备库之间网络故障引发脑裂。

• 发起故障自动接管命令

        用于故障自动切换的数据守护系统中，主库发生故障时，挑选符合接管条件的备库，并通知备库执行接管操作。

监视器类型：

• 监控模式

        一个数据守护系统中，最多允许同时启动10个监视器，所有监视器都可以接收守护进程消息，获取守护系统状态，也可以执行各种监控命令。所有监视器都可以发起Switchover等命令，但守护进程一次只能接收一个监视器的命令，在一个监视器命令执行完成之前，守护进程收到其他监视器发起的请求，会直接报错返回。

•  确认模式

        确认模式和监控模式的区别在于，除了具备监控模式监视器所有功能之外，确认监视器还具有状态确认和自动接管两个功能。故障自动切换模式的数据守护系统，必须部署一个确认监视器，否则在出现数据库故障时，会导致数据库服务中断。在使用主备多实例监视器的情况下，确认监视器可以配置多个，但是同时进行工作的确认监视器的mid必须配置为相同值，代表这些确认监视器属于同一个数据守护系统，同一个数据守护系统中的确认监视器在保证大多数工作正常的情况下发挥的功能与一个确认监视器相同。除使用主备多实例监视器的情况外，一个数据守护系统只能配置一个确认监视器。

2、守护进程dbwatcher的作用：

       守护进程负责监控数据库运行状态，必要时重启数据库服务。守护进程和实例链路建立成功后，数据库实例定时发送信息到守护进程，发送到守护进程的内容包括：实例进程ID、实例名、数据库模式、数据库状态、FILE_SEQ、FILE_LSN、CUR_SEQ、CUR_LSN、MAL链路状态、归档状态、公钥、MPP控制文件等信息。

守护进程更新本地记录的实例信息后，同时记录该时间戳。当检测到实例进程ID已经不存在或者超过一段时间没有收到实例消息（INST_ERROR_TIME），则会认定实例故障。如果配置了自动重启，则会将实例重新拉起。

3、MAL通讯

        MAL系统是DM内部高速通信系统，基于TCP/IP协议实现。服务器的很多重要功能都是通过MAL系统实现通信的，例如数据守护、数据复制、MPP、远程日志归档等。MAL系统内部包含一系列线程，有MAL监听线程、MAL发送工作线程、MAL接收工作线程等。

通过MAL发送的远程归档与本地归档的另外一个区别就是归档失败的处理策略不同：本地归档写入失败（比如磁盘空间不足），系统将会挂起；而远程归档失败则会直接将远程归档失效，不再发送REDO日志到指定数据库实例。当节点间网络恢复、或者远程节点重启成功后，系统会自动检测并恢复远程归档，继续发送新写入的REDO日志，但不会主动补齐故障期间的REDO日志。因此，在出现节点故障等情况下，通过MAL发送的远程归档的内容有可能是不完整的，而本地归档的内容肯定是完整的；如果备份还原恰好需要用到这段丢失的远程归档日志，那么可以从源端的本地归档拷贝、补齐这部分内容。而共享本地归档的远程归档，其本质就是本地归档，因而不存在远程归档日志丢失的问题，加上共享本地归档精省去了MAL发送的过程，因此更加可靠高效。综上所述，DM推荐用户使用共享本地归档的远程归档。

4、实例数据库状态

 DM 数据库的状态： 启动从 SHUTDOWN->Mount->open

• mount状态，数据库读取初始化参数和控制文件,启动到 mount 状态。 该状态下可以配置归档、主备机模式等设置。可以读取控制文件和内存中的数据，不能读写数据文件，此时数据库不能提供正常服务。
• open 状态：打开状态，此时数据库提供正常服务，可以读写数据文件（可以访问表、视图、 数据等）。
• suspend：只读状态，此时数据库只能读、不能写，如果执行 commit 写数据，数据库会挂 起。 

         MOUNT 和 OPEN 可以相互转换，SUSPEND 和 OPEN 可以相互转换，但 MOUNT 和 SUSPEND 不能相互转换。

2、归档类型

        由于主备模式是基于归档日志进行数据一致性校验和恢复的，为此达梦主备集群归档模式分为：实时归档，即时归档，本地归档，异步归档四种。

• 本地归档：

Redo日志本地归档（Local），就是将Redo日志写入到本地归档日志文件的过程。

• 实时归档：

        与本地归档写入保存在磁盘中的日志文件不同，实时归档（Realtime）将主库产生的Redo日志通过MAL系统传递到备库。
 
原理：
1. 主库在Redo日志（RLOG_PKG）写入联机日志文件前，将Redo日志发送到备库；
2. 备库收到Redo日志（RLOG_PKG）后标记为KEEP_PKG，将原KEEP_PKG加入日志重演任务系统，并马上响应主库，不需要等待Redo日志重演结束后再响应主库；
3. 主库收到备库的响应消息，确认备库已经收到Redo日志后，再将Redo日志写入联机日志文件中。

• 即时归档：

        在主库将Redo日志写入联机日志文件后，通过MAL系统将Redo日志发送到备库。即时归档与实时归档的主要区别是Redo日志的发送时机不同。

• 异步归档：

        异步归档（Async)）由主、备库上配置的定时器触发，根据异步备库的 KEEP LSN信息，扫描本地归档目录获取 Redo日志，并通过MAL系统将Redo日志发送到异步备库。异步备库的redo日志重演过程与实时归档等其他类型的完全一致。 

3、实时主备。

实时主备，分为两种模式，默认是高性能模式。

• 事务一致性模式：

1. 当主库产生数据变更，此时并未写入主库的redo日志，然后将redo buffer中的数据变更发送给备库；
2. 备库接收到redo信息后，并立即重演redo日志。然后响应主库。
3. 主库收到备库的响应后，才会把redo buffer中的数据变更写入redo日志中。

• 高性能模式：

1.  当主库产生数据变更，此时并未写入主库的redo日志，然后将redo buffer中的数据变更发送给备库；
2. 备库接受到主库发送的redo信息，立即给主库一个确认收到的反馈信息，响应主库；
3. 备库接收到redo信息后，并没有立即重演redo日志。主库收到备库的响应后，才会把redo buffer中的数据变更写入redo日志中。

  ​​​​​4、异步主备

异步归档：

1. 异步归档（Async）由主、备库上配置的定时器触发；

2. 根据异步备库的KEEP LSN信息，扫描本地归档目录获取Redo日志，并通过MAL系统将Redo日志发送到异步备库。

3.  异步备库的Redo日志重演过程与实时归档等其他类型的完全一致。

三、此次升级主库启动失败原因解析。

       1、官方注意事项

        关闭整个数据守护系统时，先关闭主库再关闭备库，顺序一定不能错。对于本地守护类型的库，在关闭数据守护系统时，不受此顺序限制。 因为主库 Shutdown 过程中，需要 Purge 所有已提交事务，会修改数据，并产生 Redo 日志。如果先 Shutdown 备库，会导致主库发送归档日志失败， 并且由于主库已经处于 Shutdown 状态，会导致主库异常关闭。

官方给出的提醒如下：

2、日志分析

        升级版本后重新启动数据守护系统时，由于升级过程中可能涉及系统表、动态视图等的修改，需要在主库版本升级后将升级过程中的 Redo 日志发送到备库，备库通过重做这段 Redo 日志进行版本升级。在此过程中，不允许对备库进行访问，否则会报“备库版本升级 时不允许访问”的错误。Redo 日志重做完成后，备库允许正常访问。

        手动方式启动数据守护系统时，对于守护进程，数据库实例和监视器的启动顺序没有严格要求，也可以通过监视器命令启动守护系统（前提是所有守护进程已经启动）。 启动流程中，守护进程在通知主库 Open 之前，会先收集出和主库数据一致的备库（备库的 ALSN 信息和主库的 FLSN 信息相等），守护进程会将这些备库的归档设置为 Valid 有效状态，其他数据不一致的备库则设置为 Invalid 无效状态。Primary 模式数据库实例切换为 Open 状态时，需要回滚活动事务、Purge 已提交事务，并重构回滚段，会引发数据变化、LSN 增长。对归档无效的备库，在数据守护启动完成后，主备库数据肯定是处于不一致状态。 主库守护进程 Open 主库后，会修改 INST_RECOVER_TIME 内存值为 3 秒（默认 60 秒），确保归档状态无效的备库 Open 后，尽快启动故障恢复流程，同步主库数据完成后，重新将归档设置为 Valid 状态。 如果在故障恢复流程完成之前，主库故障，并且不存在归档状态有效的备库，则无法执行备库接管；备库强制接管会引发守护进程组分裂。

3、总结

根据时间轴的日志得出：

①停止备库的时候主库备份恢复完成后，回滚活动事务、Purge 已提交事务，并重构回滚段，会引发数据变化、LSN 增长等，通过MAL将RLOG_PKG发送给备库并标记为KEEP_PKG，由于是先停了备库，此时备库响应主库失败，主备库数据处于不一致状态。

②起主库的时候，主库守护进程无法收集出和主库数据一致的备库（备库的 ALSN 信息和主库的 FLSN 信息相等）的信息，导致主库无法open，数据库启动到suspend状态，报错。

到此文章结束，请耐心阅读~
更多达梦技术资讯，请访问达梦技术社区：
达梦数据库 - 新一代大型通用关系型数据库 | 达梦云适配中心
https://eco.dameng.com/