Upgrade database engine version for FalkorDB deployments

• FalkorDB version (spec.version, for example 4.22.2): the database engine the pods run. The versions on offer are the ones in your installation’s version catalog, listed by GET /api/system/falkordb-versions.
• Addon component definition (spec.componentDefinition, for example falkordb-4-1.7.13): the FalkorDB addon release that defines how KubeBlocks runs the pods. See Upgrade the addon.

​

Before you start

• Take a backup and confirm it restores. See Backups. FalkorDB upgrades are one-way: a newer version can write data that older versions can’t load. For example, FalkorDB 4.22.0 writes RDB encoding v20, which earlier releases can’t read.
• The deployment must not be in a Failed state. Fix it first.
• An upgrade recreates every pod, one at a time. Settings made with raw redis-cli CONFIG SET are lost; see Parameters & resources.
• Check that every data node has a persistent volume:
  kubectl get pods -n <namespace> -l app.kubernetes.io/instance=<deployment> \
    -o custom-columns='POD:.metadata.name,COMPONENT:.metadata.labels.apps\.kubeblocks\.io/component-name,DATA-CLAIM:.spec.volumes[?(@.name=="data")].persistentVolumeClaim.claimName'
  
  Every pod whose component isn’t falkordb-sent must list a claim, including every shard’s replicas. Sentinel claims don’t count: Sentinels get a volume even when the data nodes don’t. A data pod that shows <none> runs on pod-local storage: an upgrade recreates it empty and its data is lost. That is the case for any deployment created without storage (spec.nodes.storage left out), and for sharded deployments created with the Admin UI wizard before 1.0.0-beta.4, which ignored the storage settings. Move the data to a new deployment with persistent volumes first, as the 1.0.0-beta.4 Fixed notes in the changelog describe.

​

Upgrade a deployment

falkordb-admin deployments upgrade <name> \
  --namespace <namespace> \
  --version 4.22.2 \
  --component-definition falkordb-4-1.7.13

curl -s -b cookies.txt \
  "http://localhost:3000/api/clusters/<name>?namespace=<namespace>&schemaVersion=1" |
  jq '.metadata.generation'

curl -s -b cookies.txt -X PATCH \
  "http://localhost:3000/api/clusters/<name>?namespace=<namespace>" \
  -H 'Content-Type: application/merge-patch+json' \
  -H 'If-Match: "<metadata.generation>"' \
  -d '{ "schemaVersion": 1, "spec": { "version": "4.22.2", "componentDefinition": "falkordb-4-1.7.13" } }'

• the version or component definition isn’t in the installation’s catalog;
• the deployment is in a Failed state;
• the version is older than the one the deployment runs, prereleases included (4.22.0-rc1 is older than 4.22.0);
• it can’t tell which version the deployment runs, because then it can’t rule out a downgrade.

​

Validate

curl -s -b cookies.txt \
  "http://localhost:3000/api/clusters/<name>?namespace=<namespace>&schemaVersion=1" |
  jq '{version: .spec.version, componentDefinition: .spec.componentDefinition, state: .status.state}'

kubectl get components.apps.kubeblocks.io -n <namespace> \
  -l app.kubernetes.io/instance=<name> \
  -o custom-columns=NAME:.metadata.name,VERSION:.spec.serviceVersion,DEFINITION:.spec.compDef,PHASE:.status.phase

kubectl exec -n <namespace> <pod> -c falkordb -- sh -c \
  'redis-cli -a "$REDIS_DEFAULT_PASSWORD" --no-auth-warning MODULE LIST'

​

Rolling back