Chapter 5. Updates and Upgrades

Documentation

VoltDB Home » Documentation » VoltDB Kubernetes Administrator's Guide

Chapter 5. Updates and Upgrades

Once the database is up and running, Kubernetes works to keep it running in the configuration you specified. However, you may need to change that configuration as your database requirements evolve. Changes may be as simple as adding, deleting, or modifying database tables or procedures. Or you may want to modify the configuration of the database, adding new users, or even expanding the cluster by adding nodes.

The following sections describe some common update scenarios and how to perform them in a Kubernetes environment, including:

  • Modifying the database schema

  • Modifying the database or cluster configuration

  • Upgrading the VoltDB software and Helm charts

5.1. Updating the Database Schema

Once the VoltDB database starts, you are ready to manage the database contents. Using Kubernetes does not change how you manage the database content. However, it does require a few extra steps to ensure you have access to the database, as described in Section 3.2.1, “Accessing the Database Interactively”.

First you need to identify the pods using the kubectl get pods command. You can then access the pods, individually, using the kubectl exec command, specifying the pod you want to access and the command you want to run. For example, to run sqlcmd on the first pod, use the following command:

$ kubectl exec -it mydb-voltdb-cluster-0 -- sqlcmd
SQL Command :: localhost:21212
1>

You can execute a local batch file of sqlcmd commands remotely by piping the file into the utility. For example:

$ cat schema.sql
 CREATE TABLE HELLOWORLD ( 
    HELLO VARCHAR(15), WORLD VARCHAR(15),
    DIALECT VARCHAR(15) NOT NULL
 );
 PARTITION TABLE HELLOWORLD ON COLUMN DIALECT;
$ kubectl exec -it mydb-voltdb-cluster-0 -- sqlcmd < schema.sql
Command succeeded.
Command succeeded.
$

Changing the database schema does not require synchronization with Helm or Kubernetes necessarily. However, if you specified the schema and/or procedure classes when you initially create the Helm release, it may be a good idea to keep those properties updated in case you need to re-initialize the database. (for example, when re-establishing a XDCR connection that was broken due to conflicts.) This can be done by updating the cluster.config.schemas and/or cluster.config.classes properties and their unique subproperties. For example:

$ helm upgrade mydb voltdb/voltdb       \
   --reuse-values                       \
   --set-file cluster.config.schemas.mysql=schema.sql \
   --set-file cluster.config.classes.myjar=procs.jar

Note that for the schema and classes you must specify a unique subproperty of your choosing for each file (In the previous example mysql and myjar). This way you can include multiple schema or class files by specifying each with a separate --set-file flag and a separate unique subproperty name (such as sql1, sql2, nd so on).