MariaDB 10.3.29灾难性bug及开源数据库运维防护问题咨询

问题1：若未找到临时解决方案，这类场景下该如何处理？ #

• 优先自行适配修复补丁：官方已上报确认的bug通常会在对应的issue中公开修复commit，你可以拉取对应版本的MariaDB源码，手动合并修复补丁后自行编译使用，不需要等待官方的正式版本发布，这类单一功能点的补丁改动量小，引入额外风险的概率极低。
• 临时切换兼容替代组件：空间索引相关的SQL语法在MySQL 8.0和MariaDB 10.3版本的兼容性较高，可临时搭建同数据量的MySQL集群做流量切换，仅需做少量语法适配即可保障业务正常运行，待MariaDB官方版本更新后再切回。
• 非核心功能降级：若上述方案都无法落地，且业务允许的前提下，可暂时下线依赖bbox搜索的非核心功能，优先保障核心链路的可用性，待问题修复后再恢复对应功能。

问题2：这类故障是否属于使用开源软件过程中的可预期情况？ #

属于可预期的风险范畴。所有软件在版本迭代过程中都存在引入新bug的概率，开源软件的小版本迭代中，非核心功能的测试覆盖度通常会低于核心事务类功能，类似空间索引这类偏小众的使用场景很容易未被纳入版本发布前的回归测试用例，这类问题是使用开源软件前就需要纳入风险评估的常见情况。

问题3：大家是否会部署运行不同版本MariaDB的冗余服务器？ #

绝大多数生产环境不会直接部署跨版本的冗余集群，不同版本之间的主从同步协议、数据存储格式、SQL语法都可能存在兼容性差异，很容易引发数据不一致等更严重的问题。更通用的做法是：

• 正式升级前搭建和生产数据一致的新版本测试集群，先切1%-5%的小流量做灰度验证，持续跑1~2周无异常后再推进全量升级。
• 核心业务会保留上一个稳定版本的全量备份和备用集群资源，一旦新版本出现故障可以直接把流量切回旧版本集群，不需要执行官方不支持的降级操作。

问题4：日常运维过程中通常采用哪些手段保障自身服务及服务器的稳定运行？ #

• 变更前全量回归测试：所有版本升级操作前，必须针对本次版本更新涉及的所有功能点，以及自身业务的核心使用场景做全量回归测试，比如本次升级涉及空间功能更新，就需要优先覆盖bbox搜索的所有业务用例。
• 灰度升级+实时监控：升级操作不一次性全量执行，先升级单台从节点验证数据同步正常，再逐步升级剩余从节点，最后切主升级原主节点，升级过程中持续监控核心业务指标，出现异常立刻停止升级回滚。
• 多维度备份机制：每次版本变更前必须做一次全量冷备份，日常保留最近7天的增量备份，核心业务保留至少2个历史稳定版本的全量备份，可随时快速恢复到指定版本的状态。
• 提前制定回滚预案：所有变更操作前必须提前确认回滚方案，哪怕官方不支持版本降级，也要提前准备好旧版本的运行环境和恢复流程，避免故障发生后无应对方案。

内容的提问来源于stack exchange，提问作者Pantelis Livadiotis