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
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.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).