Performing database maintenance
After you create a writeable dataview, you create a scaling group general purpose cluster to
run a long-running database maintenance script. For this, you use the cluster
initializationScript
attribute. The database maintenance script could run for
multiple hours without being terminated. When database maintenance script is running, monitor
the cluster logs for progress and any errors from the database maintenance script. After the
database maintenance script completes, connect to the cluster to verify the updated kdb
database and commit changes to the underlying kdb database by using the
commit_kx_database
q API. You can also automate these steps in your database
maintenance script itself.
Create a general purpose cluster in the scaling group with the previously created data view and provide database maintenance script using
initializationScript
in the CreateKxCluster API operation. After you create the cluster, wait till the status changes toRunning
. During this time, you can monitor the logs from the cluster for progress and any errors from the database maintenance script.Call the GetKxConnectionString API to get a
signedConnectionString
for the cluster.-
Connect to the cluster and verify the kdb database state by running q commands.
-
Call the
commit_kx_database
q API with the database name to apply the changes to the source kdb database. -
Call the GetKxChangset API operation to check the status of the commit database changeset. After the kdb database is successfully updated, you can load the updated kdb database on an existing HDB cluster by calling the UpdateKxClusterDatabases API operation or on a new HDB cluster by calling the CreateKxCluster API operation.
This is section shows how you can perform database maintenance on a partitioned
database by using a dbmaint.q
script. The following example explains how you
can load the dbmaint.q
script on a general purpose cluster that runs on a
scaling group, add a new column to a table, and finally commit the database to create a
changeset.
Load the
dbmaint.q
script by running the following command. This script contains utility functions for maintenance of partitioned database tables in kdb+. q) \l /opt/kx/app/code/dbmaint/dbmaint.q
Load a database.
q) \l /opt/kx/app/db/
welcomedb
-
Inspect the table schema in your database.
q) meta example c | t f a ------| ----- date | d sym | s p time | p number| j
-
Change to the database parent directory.
q) \cd /opt/kx/app/db
-
Add a new column using the
addcol
function from thedbmaint.q
script.addcol[`:
welcomedb
;`example;`price;0h]; Inspect the updated table schema with the newly added column.
q)con "meta example" c | t f a ------| ----- date | d sym | s p time | p number| j price | h
Commit the database changes by calling the
.aws.commit_kx_changeset
q API. The API creates a changeset and returns the id, which you can use to monitor the changeset status through the FinSpace API or console.q) .aws.commit_kx_database["
welcomedb
"] id | "UscXQcZ2htijCQlr1xNaIA
" status| "PENDING"
Note
The recommended way to perform a long-running database maintenance is to implement a database maintenance script and execute it as cluster initialization script. An initialization script can run for multiple hours without being interrupted which is required for long-running database maintenance tasks. When database maintenance script is running, monitor the cluster logs for progress and any errors. After the database maintenance script completes, connect to the cluster to verify the updated kdb database and commit changes to the underlying kdb database by using the commit_kx_database q API. You can also automate verification and commit steps in your database maintenance script itself.