文档反馈
问问助手版本管理
EMR Serverless OLAP 版本管理的核心目标是在保障业务稳定性的前提下，通过合理规划版本升级与配置更新，充分利用新版本的特性优化、性能提升与稳定性增强。实践需围绕 “版本选型、升级策略、回滚保障、配置规范” 四大维度展开，结合 StarRocks/Doris 引擎特性与业务场景落地。
版本选型
版本选型需平衡 “新特性需求” 与 “业务兼容性”，核心原则是 “小版本优先用最新，大版本需先验证”，具体选型逻辑如下：
版本类型适配场景
不同版本类型的定位差异明确，需根据业务核心诉求选择：
版本类型 | 核心特性 | 适用场景 | 选型建议 |
|---|---|---|---|
小版本（如 StarRocks 3.2.12、Doris 2.1.8） | 基于同一大版本，以 Bugfix 修复为主，兼容基础功能（SQL 语法、接口、数据格式） |
| 强烈推荐：生产环境优先升级至当前大版本的最新小版本，及时修复漏洞与性能问题 |
大版本（如 StarRocks 3.3、Doris 3.0） | 含 核心功能 / 架构演进（如新增存储引擎、优化查询计划），可能存在兼容性变更 |
| 谨慎选择：仅在业务明确需要新特性时考虑，且必须先在测试集群完成全量兼容性验证 |
注意事项
- 禁止生产环境直接使用 “社区刚发布的大版本”：新大版本可能存在未暴露的稳定性问题，需等待 1-2 个小版本迭代后再评估。
- 避免跨多代大版本跳跃升级（如 StarRocks 3.1 → 3.3）：建议按 “3.1 → 3.2 小版本最新 → 3.3” 逐步升级，减少跨版本兼容性风险。
版本升级说明
版本兼容性
小版本升级（推荐升级至当前大版本的最新小版本）
范围：同一大版本下的所有小版本之间保持兼容，因为社区小版本一般以 Bugfix 修复向前演进。
兼容内容：包括SQL 语法、客户端接口（JDBC/ODBC）、表结构与数据格式等。
不保证兼容项：程序业务逻辑行为（如特定查询性能变化等）。
避免在业务高峰期执行版本升级，会存在部分任务失败需要重试。
大版本升级（需要在测试集群上进行充分验证，确认业务兼容性后再执行升级）
说明：大版本之间的不保证完全兼容，可能存在以下变更：
- SQL语法调整或弃用。
- 接口变更或参数调整。
- 配置项默认值变化。
- 查询执行计划优化导致性能波动等。
升级建议：
- 升级前请务必仔细阅读对应开源引擎版本的发布内容，了解可能的影响。
- 在测试集群上进行充分的业务兼容性验证。
- 避免在业务高峰期执行版本升级，会存在部分任务失败需要重试。
是否可回滚
EMR Serverless OLAP 在引擎升级功能上，支持一键回滚升级，但仅在以下场景下可用：
引擎类型 | 版本类型 | 回滚支持情况 | 回滚操作要点 |
|---|---|---|---|
StarRocks | 小版本 | 支持一键回滚 | 回滚前停止所有写入任务（如 Stream Load、Broker Load），避免数据冲突 |
大版本 | 支持一键回滚，但需遵循社区版本路线 |
| |
Doris | 小版本 |
|
|
大版本 | 均不支持一键回滚 | — |
配置更新
更新方式
所有引擎参数更新推荐只采用 EMR 控制台提供的实例参数 - 参数配置入口，做到参数配置可追溯，可持久化。禁止通过 SQL 命令的方式直接修改引擎参数，会造成配置没有持久化生效，实例重启后参数不生效导致业务受影响，EMR 对此类参数变更导致的问题不承担责任。
更新建议
实例参数变更需要保持谨慎，建议参照以下流程进行实例参数的修改：
- 参照官网文档确认参数的生效范围、单位、有效值等，如果参数修改不当，可能导致重启后进程无法正常启动，业务受损。
- 对于1中没有明确的参数修改，建议修改完成后，按照单 FE/BE 节点维度进行重启验证，观察到相应服务正常启动后，再操作剩余节点。
- 采用 EMR 控制台提供的实例参数 - 参数配置入口，保障参数配置更新可追溯，可回滚，可持久化。