某客户项目现场，因其业务系统要用到数据库新版本中的功能特性，因此考虑升级现有数据库版本。在升级之前，万里数据库项目团队帮助客户在本地测试环境构造了相同的基础版本，导入部分生产数据，尽量复刻生产环境进行升级，显示测试升级正常。
之后，将万里安全数据库分布式 GreatDB-Cluster由5.1.9 升级为GreatDB-Cluster 6.0.3 版本，以下为具体的升级方案与过程。
01数据库升级操作一览
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.[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 -- 实例退出
从日志中发现，实例启动期间进行了redo恢复。实际上，关闭数据库实例时，设置了 innodb_fast_shutdown=0，不应出现redo恢复的过程。
另外一台服务器上也进行了gcc/gcc-c++升级，启动第二个计算节点。它与第一个节点实例是副本关系，数据完全一致，该实例可以正常启动，启动日志如下所示：
[Node] [MY-012529] [InnoDB] Redo log format is v4. The redo log was created before MySQL 8.0.30. [Node] [MY-012557] [InnoDB] Redo log is from an earlier version, v4.[Node] [MY-012532] [InnoDB] Applying a batch of 0 redo log records ... [Node] [MY-012535] [InnoDB] Applying batch completed![Node] [MY-013888] [InnoDB] Upgrading redo log: 0M, LSN=284965900. [System] [MY-013577] [InnoDB] InnoDB initialization has ended.[System] [MY-011090] [Server] Data dictionary upgrading from version '80025' to '80025'. [Node] [MY-013327] [Server] MySQL server upgrading from version '80025' to '80032'.[Node] [MY-012357] [InnoDB] Reading DD tablespace files[Node] [MY-012356] [InnoDB] Scanned 38 tablespaes. Validated 38.[System] [MY-013413] [Server] Data dictionary upgrading from version '80025' to '80025' completed. [Node] [MY-013327] [Server] MySQL server upgrading from version '80025' to '80032'.[Node] [MY-010006] [Server] Using data dictionary with version '8025'.[System] [MY-013381] [Server] Server upgradd from '80025' to '80032' started. [System] [MY-013381] [Server] Server upgradd from '80025' to '80032' completed.
第三台服务器上未进行gcc/gcc-c++升级，启动报错情况和第一台相同，升级后依然会进行redo恢复异常的操作。
从测试可以看出，新版本需对gcc/gcc-c++进行升级才能启动实例。未升级的前提下启动实例，会导致redo识别异常，后续升级也无法识别到正常的redo内容。
所有服务器都升级了gcc/gcc-c++后，所有实例启动正常，两个异常的计算节点通过备份数据实现了恢复。
02新的问题出现了
1. 新问题的暴露：
某天深夜22点，客户突然打来电话，说白天升级的数据库集群存在问题：C#程序无法连接到集群， 而升级前是正常连接的。由于场地限制，晚上无法连接到客户的集群环境，于是技术团队通过电话沟通现场情况并进行技术指导。
半小时后，经过细致的排查指导，客户在测试后发现：去掉连接串中的OldGuids=true就能正常连接到数据库，但是写入的汉字全部是乱码。
2. 问题分析：
-
升级前后配置文件未发生变化。通过查询performance_schema.variables_by_thread，确认所有session的字符集都是utf8mb4，和表中字符集一致，因此乱码现象排除字符集原因；
-
查看connector-net的release note，发现MySQL 8.0.33中有修复MySQL.Data.MySqlClient.MySqlConnection相关bug。
3. 问题解决方法：
有两种方法均可解决上述问题：
-
方法1：确认客户的C#驱动版本为MySQL 6.9.8，需升级驱动到MySQL 8.0.32，数据库中连接串可以添加 OldGuids=true，然后数据库连接正常，汉字写入正常；
-
方法2：不升级C#驱动，将vscode工具升级到2013以上版本，数据库中连接串可以添加 OldGuids=true，之后数据库连接正常，汉字写入正常。
03后续操作指南
经过数据库集群层面的复盘梳理，发现版本升级操作虽然在常规流程上没发现问题，但由于实际环境的差异性，仍可能会出现预料之外的情况。未来数据库升级过程中，有2点值得大家重点关注：
1、关注驱动同步升级
尽管在测试环境中，做了详尽测试并顺利完成所有步骤。但实际生产环境升级仍可能需要执行驱动同步升级这一操作。数据库部署环境中，如果只对Java程序进行验证，而忽略Java驱动程序升级，会遗漏实际生产环境中使用的C#程序。这个问题在测试阶段不会被识别异常，但实际生产环境中会出问题；
规避措施：升级流程必须包含对驱动程序兼容性的全面评估，并且在发现版本不匹配时，立即进行同步升级。
2、升级前备份的必要性
生产环境中，可能会遭遇因libgcc_s.so版本过低导致的undo文件损坏问题。如果事先没有进行备份，将可能导致数据无法完全恢复，造成严重的生产事故。因此，系统升级前进行数据备份，至关重要。
规避措施：必须始终确保在数据库升级前执行全面的数据备份，不仅能保护业务系统的数据安全，还能在出现问题时迅速恢复系统，减少潜在损失。
