Downgrading a Leader-Secondary-Egress Cluster

This procedure describes how to downgrade from version 2.3 of the software to 2.2 or 2.1.

Plan to downgrade during a maintenance window or have a redundant cluster available to accept traffic during the downgrade 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 downgrade the nodes. If you're not using a health checker, ensure that your load balancer doesn't reference nodes that are currently being downgraded and aren't in the correct state to output content.

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

Warning

To ensure a seamless downgrade, 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 downgrade.

These are the node references in this procedure:

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

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

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

Note

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

You can't perform a regular downgrade to version 2.0.x and earlier. To downgrade to an earlier version, see Kickstarting AWS Elemental Delta. Note that there may be also special consideration if you're downgrading to versions 2.1.0 through 2.1.2. For more information, see Downgrade Special Consideration.