项目纪实 | 版本升级操作get！GreatDB分布式升级过程详解

数据运维 2024-05-31 共饮一杯 手机阅读

某客户项目现场，因其业务系统要用到数据库新版本中的功能特性，因此考虑升级现有数据库版本。在升级之前，万里数据库项目团队帮助客户在本地测试环境构造了相同的基础版本，导入部分生产数据，尽量复刻生产环境进行升级，显示测试升级正常。


之后，将万里安全数据库分布式 GreatDB-Cluster由5.1.9 升级为GreatDB-Cluster 6.0.3 版本，以下为具体的升级方案与过程。


1. 系统参数配置

  • GreatDB-Cluster 5.1.9 对应MySQL功能版本为8.0.25， GreatDB-Cluster 6.0.3 对应 MySQL功能版本为8.0.32（旨在与MySQL驱动程序形成对照）；

  • 生产环境操作系统使用CentOS Linux release 7.6.1810 (Core)。


2. 执行升级

  • 由于版本跨度较大，执行了离线升级操作。

  • 先停止应用，所有从副本追平主副本，GTID一致，再安全地关闭数据库实例，所有脏页都刷盘。

  • 替换了执行程序后，启动第一个计算节点实例，此时出现异常  libgcc_s.so must be insta lled for pthread_cancel to work ，实例进程退出。


3. 异常处理

  • 通过ldd查看程序的依赖包，发现并没有缺失，问题指向了系统的lib包。

  • 相同的数据文件在低版本数据库中可以正常运行，高版本就有异常信息。技术人员评估可能与gcc版本有关，挂载系统版本镜像进行gcc升级 yum -y install gcc gcc-c++；

  • 重新启动实例后，不再报libgcc_s.so错误，然而启动实例依然失败，在错误日志中显示如下信息：


    -- 检查完dbwr文件后的
    [Note] [MY-013086] [InnoDB] Starting to parse redo log at lsn=225550883, whereas checkpoint_lsn=225551
    [Node] [MY-012547] [InnoDB] Log scan progressed past the checkpoint LSN 225550883
    [Node] [MY-012551] [InnoDB] Database was not shutdown normally!
    [Node] [MY-012552] [InnoDB] Starting crash recovery.
    <br>
    [ERROR] [MY-012519] [InnoDB] ########## CORRUPT LOG RECORD FOUND ##########
    [Node] [MY-012520] [InnoDB] Logrecord type 0, page 0:0. Log parsing proceeded successfully up to 22555
    [Node] [MY-012521] [InnoDB] Hex dump starting 100 bytes before and ending 100 bytes after the corrupte
    [Node] [MY-012522] [InnoDB] Set innodb_force_recovery to ignore this error
    -- 实例退出