Migrating to Java 17 for Starburst Enterprise 390-e or higher#

The Starburst Enterprise platform (SEP) 390-e STS release, and importantly the 393-e LTS release, are the first releases that require Java 17 as the runtime environment for the coordinator and worker nodes in the cluster. This guide details necessary considerations when upgrading to these releases or newer releases from older releases that use Java 11.

General advice#

Upgrading software is always an important step to gain access to new features, bug fixes, performance improvements, and other enhancements of the software.

When choosing your upgrade path and strategy, you must take into account how business critical your deployment of SEP is to your company. It is generally advisable to perform a test upgrade in a non-critical environment, and especially advised when making the complex update from SEP <= 390-e to SEP >= 390-e.

The following is a rough guide to use as a blueprint for your specific upgrade plan:

Step 1: Understand your current usage

  • To understand the scope of the changes, it is important to review the release notes for all versions, including multiple Trino and SEP release notes, especially if you are upgrading from an older release. Pay special attention to any breaking changes, and changes on connectors and other features you are actually using.

  • Plan to upgrade to 393-e at a minimum and review the release notes for breaking changes and other updates.

  • Create an inventory of all custom plugins, including authentication, UDFs, and connector plugins, and plan to update them all to adapt to the new SPI.

Step 2: Prepare

  • Download all required binaries.

  • Implement all necessary custom plugin updates.

Step 3: Upgrade

  • Upgrade your clusters one at a time, ideally beginning with a test upgrade on a development or staging cluster first.

In the next sections you can learn more details about the changes affecting different users of SEP, and the required steps to adjust:

Platform administrator#

As a platform administrator, you are responsible for installing, maintaining, and updating the SEP clusters for your organization.

The upgrade to 390-e or higher is a slightly larger effort than typically required for a SEP upgrade. The specific changes necessary includes some changes that affect all SEP installation, and others depend on your deployment method and related tooling in use. The following sections include details for all the required changes related to the required Java 17.

Work with your data engineers to adapt to any changes required for catalog files and others data management related components.

Finally your users, the data consumers are not affected, but we recommend an upgrade of any client tools to newest available version as general best practice.

Java runtime#

There is a strict requirement for the Java runtime version of SEP in place, so be sure to include an update of your Java runtime. For SEP 390-e Java 17, patch version 17.0.3 or higher, is required. If you update to newer SEP versions, check the specific requirements of that version.

tar.gz archive installation#

The Java runtime is managed independently of the archive. Verify and update the Java installation on all nodes manually, or with your provisioning tool as desired.

RPM archive#

The declared dependency to a Java runtime in the RPM has been updated. The default suggested installation procedure ignores that declaration with --no-deps. Separately ensure that the correct Java installation is installed and configured on all nodes.

starburst-admin#

The collection of Ansible playbooks Deploy with Starburst Admin has been updated to support SEP 390-e and higher, and Java 17. Use version 1.5.1 or newer.

Docker container#

The Docker container image automatically contains the correct Java runtime and relevant configuration. No adjustments are necessary.

If you use a custom etc/jvm.config file, you need to ensure to update it to the suggested configuration.

Kubernetes with Helm#

The Docker image and the Helm chart default configuration contain the correct Java runtime and relevant configuration. No adjustments are necessary.

If you use a custom configuration for the coordinators and workers you need to update the relevant details based on the the suggested configuration.

Amazon AMI and CFT#

The Amazon AMI and CFT automatically contain the correct Java runtime and relevant configuration. No adjustments are necessary.

Java keystores#

The default PKCS12 algorithms included in Java 17 have been strengthened. As a results existing PKCS12 keystores that have been protected using the previous algorithm defaults can have interoperability issues on JDK 17.

To mitigate those limitations, you must create new keystores using JDK 17 tooling.

Kerberos#

The encryption algorithms 3DES and RC4 in Kerberos are deprecated and disabled (JDK-8139348). By default the des3-hmac-sha1 and rc4-hmac encryption types are now disabled. Users of Kerberos authentication must update to newer, supported algorithms.

Encapsulated JVM internals#

JDK internals are now strongly encapsulated by default. This requires some additional JVM flags for libraries that are not yet compatible with JDK 17. Only users of the Snowflake connector must update their JVM configuration.

Data engineer#

As a data engineer, you are responsible for the data sources connected to SEP, and any related configuration in catalog files and elsewhere in SEP, security tools, and general aspects such as network performance between SEP and data sources.

The upgrade to 390-e or higher is similar to other SEP upgrades, since most relevant configuration remained unchanged.

The specific changes necessary depend on your data sources, and specific usage and is detailed in the following sections.

Connectors and catalogs#

Connectors change regularly with each release, and you must make sure you understand the changes for all connectors you are actively using in your catalogs and clusters.

The following connectors specifically required configuration changes related to Java 17:

Snowflake connector#

The Snowflake connector requires a JVM configuration to open up access to JVM internals. Users of catalogs using the connector must update their jvm.config as necessary, depending on their deployment platform.

Starburst Ranger plugin#

No changes are required for the Starburst Ranger Plugin.

Users of the Starburst Ranger CLI must upgrade to Java 17.

Atlas CLI#

Users of the Starburst Ranger CLI must upgrade to Java 17.

Cache service#

Users of the Cache service must upgrade to Java 17 when using in embedded as well as the standalone mode. Embedded mode usage is automatically correct when the coordinator configuration is updated. Standalone users must update their etc/jvm.config file for manual deployments or use the cache service Helm chart and Docker container, which are already configured for Java 17.

Users of the Cache service CLI must upgrade to Java 17.

Data consumer#

As a data consumer, you are working with SQL and use client tools, such as the CLI, to connect to SEP to execute these queries.

The upgrade to 390-e or higher has a no impact on you with regards to usage of Java 17.

Users of the Trino CLI can update to Java 17, but Java 11 remains to be supported.

Note

We recommend an upgrade of any client tools to newest available version as general best practice.