Upgrading a Leader-Secondary-Egress AWS Elemental Delta Cluster - AWS Elemental Delta

This is version 2.3 of the AWS Elemental Delta documentation. This is the latest version. For prior versions, see the Previous Versions section of AWS Elemental Delta Documentation.

Upgrading a Leader-Secondary-Egress AWS Elemental Delta Cluster

This section describes how to upgrade software versions of an existing cluster of Delta nodes that includes a leader node, a secondary node, and nodes designated for egress only.

Plan to upgrade during a maintenance window or have a redundant cluster available to accept traffic during the upgrade process. All activity on the node stops during this process and content could be lost.

If you have a cluster that includes a leader node, a secondary node, and one or more nodes dedicated for egress, follow this procedure to upgrade the nodes. If you're not using a health checker, ensure that your load balancer doesn't reference nodes that are currently being upgraded and aren't in the correct state to output content.

You must upgrade the nodes in concert with each other, in order to be able to continue ingesting and egressing content during the upgrade.


To ensure a seamless upgrade, do not use a VIP for content ingest. Instead, use one of these options:

  • Use a multicast source feed.

  • Send dual, matching streams to each ingest node.

This way, content can continue to be ingested during upgrade.

These are the node references in this procedure:

  • The current (as of the start of the upgrade process) leader is referred to as “node A”.

  • The current secondary node is referred to as “node B”.

You will upgrade node B and set it as the leader, and then upgrade node A and add it to node B's cluster. In the end, the two nodes will have switched roles.


We strongly recommend that you review this entire procedure before starting, in order to understand what will happen.