Directly upgrading from StarRocks
3.3 to 4.0 is not recommended.
Based on StarRocks' official upgrade guidelines, you should follow a consecutive minor version path for safety and compatibility. Here is the recommended path and the key reasons why:
1. Recommended Upgrade Path
To ensure metadata compatibility and a smooth transition, you should upgrade in this order:
3.3.x $\rightarrow$
3.4.x $\rightarrow$
3.5.x $\rightarrow$
4.0.x
2. Why a direct upgrade is risky
*
Minor Version Consistency: The documentation strongly recommends upgrading
consecutively from one minor version to another (e.g., 2.2 -> 2.3 -> 2.4). Skipping multiple minor versions increases the risk of metadata migration failures.
*
JDK Requirement Change: Starting from
v3.5, StarRocks requires
JDK 17 or later. If you are on v3.3 (which likely uses JDK 8 or 11), a direct jump to 4.0 might fail because the environment needs to be prepared for the JDK 17 transition first introduced in 3.5.
*
Major Version Prerequisite: Historically, major version upgrades (like the jump from 2.x to 3.0) required the cluster to be on the final minor version of the previous major release (e.g., you had to be on v2.5 to upgrade to v3.0). It is expected that 4.0 follows a similar requirement relative to 3.5.
3. Key Precautions
*
Create Images: Between consecutive minor upgrades, it is highly recommended to run
ALTER SYSTEM CREATE IMAGE
and ensure the image is synchronized to all Follower FEs before moving to the next version.
*
JDK 17: Ensure your environment is updated to JDK 17 before upgrading to v3.5 or v4.0.
*
Rolling Upgrade: Always upgrade BEs and CNs first, followed by Follower FEs, and finally the Leader FE.
For a detailed step-by-step guide, refer to the
Upgrade StarRocks and the
v4.0 Release Notes.
References
•
release_notes/release-4.0.md
•
deployment/upgrade.md