网站制作资质,wordpress主页 摘要,营销网络建设四个阶段,东欣建设集团网站某客户项目现场#xff0c;因其业务系统要用到数据库新版本中的功能特性#xff0c;因此考虑升级现有数据库版本。在升级之前#xff0c;万里数据库项目团队帮助客户在本地测试环境构造了相同的基础版本#xff0c;导入部分生产数据#xff0c;尽量复刻生产环境进行升级因其业务系统要用到数据库新版本中的功能特性因此考虑升级现有数据库版本。在升级之前万里数据库项目团队帮助客户在本地测试环境构造了相同的基础版本导入部分生产数据尽量复刻生产环境进行升级显示测试升级正常。 之后将万里安全数据库分布式 GreatDB-Cluster由5.1.9 升级为GreatDB-Cluster 6.0.3 版本以下为具体的升级方案与过程。 01数据库升级操作一览 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 lsn225550883, whereas checkpoint_lsn225551 [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_shutdown0不应出现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, LSN284965900. [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#程序无法连接到集群 而升级前是正常连接的。由于场地限制晚上无法连接到客户的集群环境于是技术团队通过电话沟通现场情况并进行技术指导。 半小时后经过细致的排查指导客户在测试后发现去掉连接串中的OldGuidstrue就能正常连接到数据库但是写入的汉字全部是乱码。 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数据库中连接串可以添加 OldGuidstrue然后数据库连接正常汉字写入正常 方法2不升级C#驱动将vscode工具升级到2013以上版本数据库中连接串可以添加 OldGuidstrue之后数据库连接正常汉字写入正常。 03 后续操作指南 经过数据库集群层面的复盘梳理发现版本升级操作虽然在常规流程上没发现问题但由于实际环境的差异性仍可能会出现预料之外的情况。未来数据库升级过程中有2点值得大家重点关注 1、关注驱动同步升级
尽管在测试环境中做了详尽测试并顺利完成所有步骤。但实际生产环境升级仍可能需要执行驱动同步升级这一操作。数据库部署环境中如果只对Java程序进行验证而忽略Java驱动程序升级会遗漏实际生产环境中使用的C#程序。这个问题在测试阶段不会被识别异常但实际生产环境中会出问题 规避措施升级流程必须包含对驱动程序兼容性的全面评估并且在发现版本不匹配时立即进行同步升级。 2、升级前备份的必要性
生产环境中可能会遭遇因libgcc_s.so版本过低导致的undo文件损坏问题。如果事先没有进行备份将可能导致数据无法完全恢复造成严重的生产事故。因此系统升级前进行数据备份至关重要。
规避措施必须始终确保在数据库升级前执行全面的数据备份不仅能保护业务系统的数据安全还能在出现问题时迅速恢复系统减少潜在损失。
