{
  "schema_version": 2,
  "id": "integrate/redis-data-integration/installation/upgrade",
  "title": "Upgrading RDI",
  "url": "https://redis.io/docs/latest/integrate/redis-data-integration/1.19.1/installation/upgrade/",
  "summary": "Learn how to upgrade an existing RDI installation",
  "content": "\n## Upgrading a VM installation\n\nFollow the steps below to upgrade an existing\n[VM installation](https://redis.io/docs/latest/integrate/redis-data-integration/1.19.1/installation/install-vm)\nof RDI:\n\n1.  Download the RDI installer from the [Redis download center](https://redis-enterprise-software-downloads.s3.amazonaws.com/redis-di/rdi-installation-.tar.gz)\n    (in the *Modules, Tools \u0026 Integration* category) and extract it to your\n    preferred installation folder.\n\n    ```bash\n    export RDI_VERSION=\n    wget https://redis-enterprise-software-downloads.s3.amazonaws.com/redis-di/rdi-installation-$RDI_VERSION.tar.gz\n    tar -xvf rdi-installation-$RDI_VERSION.tar.gz\n    ```\n\n1.  Go to the installation folder:\n\n    ```bash\n    cd rdi_install/$RDI_VERSION\n    ```\n\n1.  Run the `upgrade.sh` script as a privileged user. Note that you must pass\n    your RDI password to the script unless the password is empty.\n\n    ```bash\n    sudo ./upgrade.sh --rdi-password \u003credis-rdi-password\u003e\n    ```\n\n### Recovering from failure during a VM upgrade\n\nIf the previous version is v1.4.4 or later, go to the `rdi_install/\u003cPREVIOUS_VERSION\u003e`\ndirectory and run `sudo ./upgrade.sh` to revert to that version, as described in the section\n[Upgrading a VM installation](#upgrading-a-vm-installation) above.\n\nIf the version you are replacing is earlier than v1.4.4, follow these steps. These steps restore and\nrun the CLI binary of the previous RDI version, which still provided the `redis-di upgrade` command.\n(On current versions, upgrades are performed with the `upgrade.sh` script as described above, and\n`redis-di upgrade` is no longer a CLI command.)\n\n1.  Run `redis-di --version` to check the current version.\n\n    If the version is the new one, copy the previous version\n    of the RDI CLI to `/usr/local/bin` with the following command:\n    \n    ```bash\n    sudo cp rdi_install/\u003cPREVIOUS_VERSION\u003e/deps/rdi-cli/\u003cOS\u003e/redis-di usr/local/bin\n    ```\n\n1.  Check that the CLI version is correct by running `redis-di --version`.\n\n    Then, go to the `rdi_install/\u003cPREVIOUS_VERSION\u003e` directory and run the\n    following command;\n\n    ```bash\n    sudo redis-di upgrade --rdi-host \u003cRDI_REDIS_HOST\u003e --rdi-port \u003cRDI_REDIS_PORT\u003e\n    ```\n\n\u003e [!NOTE]\n\u003e If the `collector-source` or the `processor` pods are not in the `Running` state after\n\u003e the upgrade, you must run `redis-di deploy` and check again that they are both in the\n\u003e `Running` state.\n\n### Upgrading a VM installation with High Availability\n\nIf there is an active pipeline, upgrade RDI on the active VM first. \nThis will cause a short pipeline downtime of up to two minutes. \nAfterwards, upgrade RDI on the passive VM. This will not cause any downtime.\n\n\u003e [!WARNING]\n\u003e When upgrading from RDI \u003c 1.8.0 to RDI \u003e= 1.8.0 in a VM HA setup, both RDI instances may incorrectly consider themselves active after the upgrade. This occurs because the upgrade process doesn't change the cluster id value from its default `cluster-1`, causing both clusters to assume they are the active cluster.\n\u003e\n\u003e **Symptoms:**\n\u003e\n\u003e - The upgraded passive node will start collector and processor components\n\u003e - Collector may enter a crash loop as it fails to connect to the source\n\u003e - Both clusters will restart in a loop\n\u003e\n\u003e **Workaround:**\n\u003e\n\u003e After upgrading, manually set a unique cluster ID for one of the installations (preferably on the passive instance):\n\u003e\n\u003e 1. Locate the RDI configuration file on the VM host. The file is typically located at `/etc/rdi/rdi-sys-config.yaml`.\n\u003e 2. Open the configuration file in a text editor. For example:\n\u003e\n\u003e    ```bash\n\u003e    sudo nano /etc/rdi/rdi-sys-config.yaml\n\u003e    ```\n\n## Upgrading a Kubernetes installation\n\nFollow the steps below to upgrade an existing\n[Kubernetes](https://redis.io/docs/latest/integrate/redis-data-integration/1.19.1/installation/install-k8s)\ninstallation of RDI:\n\n1.  If you are using a private registry, pull the new versions of all images listed in \n    [Using a private image registry](https://redis.io/docs/latest/integrate/redis-data-integration/1.19.1/installation/install-k8s#using-a-private-image-registry)\n    and add them to your local registry.\n\n1.  Download the RDI Helm chart tar file from the [Redis download center](https://redis-enterprise-software-downloads.s3.amazonaws.com/redis-di/rdi-.tgz)\n    (in the *Modules, Tools \u0026 Integration* category).\n\n    ```bash\n    export RDI_VERSION=\n    wget https://redis-enterprise-software-downloads.s3.amazonaws.com/redis-di/rdi-$RDI_VERSION.tgz\n    ```\n\n1.  Adapt your `rdi-values.yaml` file to any changes in the new RDI version if needed.\n    See also [Upgrading to RDI 1.8.0 or later from an earlier version](#upgrading-to-rdi-180-or-later-from-an-earlier-version). \n    Before making any changes, save your existing `rdi-values.yaml` if you need to revert \n    to the old RDI version for any reason.\n\n1.  Run the `helm upgrade` command:\n    \n    ```bash\n    helm upgrade --install rdi rdi-\u003ctag\u003e.tar.gz -f rdi-values.yaml -n rdi\n    ```\n\nNote that you don't need to\n[deploy](https://redis.io/docs/latest/integrate/redis-data-integration/1.19.1/data-pipelines/deploy)\nthe RDI configuration again after this step.\n\n### Upgrading to RDI 1.8.0 or later from an earlier version\n\nWhen upgrading to RDI 1.8.0 or later from an earlier version\nyou must adapt your `rdi-values.yaml` file to the following changes:\n\n-   All collector and processor values that were previously under `collector`,\n    `collectorSourceMetricsExporter`, and `processor` have been moved to\n    `operator.dataPlane.collector` and `operator.dataPlane.processor`.\n-   `global.collectorApiEnabled` has been moved to `operator.dataPlane.collectorApi.enabled`,\n    and is now a boolean value, not `\"0\"` or `\"1\"`.\n-   `api.authEnabled` is also now a boolean value, not `\"0\"` or `\"1\"`.\n-   The following values have been deprecated: `rdiMetricsExporter.service.protocol`,\n    `rdiMetricsExporter.service.port`, `rdiMetricsExporter.serviceMonitor.path`,\n    `api.service.name`.\n\n### Verifying the upgrade\n\nCheck that all pods have `Running` status:\n\n```bash\nkubectl get all -n rdi\n```\n\nIf you find that the upgrade did not work as expected for any reason, \nthen run the `helm upgrade` command again (as described in the section\n[Upgrading a Kubernetes installation](#upgrading-a-kubernetes-installation) above),\nbut this time with the previous version you were upgrading from, and using\nyour saved `rdi-values.yaml` for that version. This will restore your previous working state.\n\n\u003e [!NOTE]\n\u003e Downgrading from RDI 1.8.0 or later to an earlier version using `helm upgrade`\n\u003e will not work. If you need to perform such an upgrade, uninstall RDI completely first as\n\u003e described in [Uninstall RDI](https://redis.io/docs/latest/integrate/redis-data-integration/1.19.1/installation/install-k8s#uninstall-rdi),\n\u003e and then install the old version.\n\n## Enabling the Flink processor\n\nThe\n[Apache Flink](https://flink.apache.org/)-based stream processor is\nfully supported on both VM and Kubernetes installations after upgrading to\nRDI 1.19.0. Once the upgrade completes, it is always available —\nno opt-in is required, and the defaults are sized for typical workloads.\nUpgrading does not change the processor used by existing pipelines, which keep\nrunning on the classic processor until you explicitly switch them by\nsetting\n[`processors.type`](https://redis.io/docs/latest/integrate/redis-data-integration/1.19.1/data-pipelines/pipeline-config#processors)\nto `flink` in their `config.yaml`.\n\nOn Kubernetes, to override the Flink processor defaults, add an\n`operator.dataPlane.flinkProcessor` block to your `rdi-values.yaml` file as\ndescribed in\n[Configure the Flink processor](https://redis.io/docs/latest/integrate/redis-data-integration/1.19.1/installation/install-k8s#configure-the-flink-processor).\nOn VMs, see\n[Configure the Flink processor](https://redis.io/docs/latest/integrate/redis-data-integration/1.19.1/installation/install-vm#configure-the-flink-processor).\nFor the per-pipeline migration steps, see\n[Migrate from the classic processor to the Flink processor](https://redis.io/docs/latest/integrate/redis-data-integration/1.19.1/installation/migration-classic-to-flink).\n\n## What happens during the upgrade?\n\nThe upgrade process replaces the current RDI components with their new versions:\n\n-   Firstly, the control plane components are replaced. At this point, the pipeline\n    is still active but monitoring will be disconnected.\n-   Secondly, the pipeline data plane components are replaced.\n    If a pipeline is active while upgrading, the `collector-source` and `processor`\n    pods will be restarted. The pipeline will pause for up to two minutes but it \n    will catch up very quickly after restarting. \n    The pipeline data and state are both stored in Redis, so data will not\n    be lost during the upgrade.\n",
  "tags": ["docs","integrate","rs","rdi"],
  "last_updated": "2026-09-19T17:55:58-07:00"
}