Upgrading OneDB helm charts

When upgrading your helm chart, it is always recommended to take a database backup before upgrading the product. The helm upgrade command is used to upgrade the current release with new configuration. Or, it can be used to upgrade the current version of the chart to a new helm chart version.

OneDB SQL Data Store and the Connection Manager statefulsets support “RollingUpdate” and “OnDelete” update strategies. RollingUpdate is the default update strategy. The RollingUpdate process will start from the highest pod ordinal index to the lowest pod ordinal index. For example, onedb-server-1 is updated before onedb-server-0.

With “OnDelete” update strategy, after ‘helm update’ operation, pod definition will not be updated till user manually deletes the old pod. “OnDelete” update strategy is recommended when database conversion is required or in a situation where user would like to manually control the upgrade procedure.

Note: While upgrading 0.4.16 or earlier helm chart version to chart 0.4.27 or later version, make sure to set ‘nfsserver.enabled’ chart attribute value to ‘true’ before performing ‘helm upgrade’ operation. ‘nfsserver.enabled’ attribute must be set to ‘true’ to mount ReadWriteMany NFS PVC on all OneDB server pods, and perform necessary steps required to convert OneDB container pod on-disk storage to newer version format.
Important: OneDB Explore Container has upgraded its H2 (embedded database) version due to security vulnerabilities present in the older versions of H2. When upgrading your helm chart to 0.4.27 version for 2.0.1.2, H2 Database needs to be updated manually. For more information, see Upgrading OneDB Explore.

The goal of OneDB’s upgrade process is to have as little interruption as possible. During an upgrade, kubernetes pods are restarted which will cause a slight interruption in write activity.

If the OneDB Database server does not need to perform a database conversion, then read activity can continue throughout the upgrade process. If a database conversion has to occur then there will be a slight interruption in read activity as well.

To maintain read activity during the upgrade process, your application must be designed with retry logic in it. When a pod is taken down so that it can be upgraded your application should retry its connection so it can connect to and use another server in the cluster.