Rolling upgrades in Elasticsearch - Mini Project: Build & Apply

Rolling Upgrades in Elasticsearch

📖 Scenario: You manage an Elasticsearch cluster that needs to be upgraded without downtime. Rolling upgrades let you update nodes one by one, keeping the cluster available.

🎯 Goal: Learn how to perform a rolling upgrade by updating node settings and verifying cluster health step-by-step.

📋 What You'll Learn

Create a dictionary with node names and their current versions

Add a variable for the target upgrade version

Write a loop to simulate upgrading nodes one by one

Print the final cluster version after all upgrades

💡 Why This Matters

🌍 Real World

Rolling upgrades help keep Elasticsearch clusters available while updating nodes one at a time.

💼 Career

Understanding rolling upgrades is important for DevOps and system administrators managing Elasticsearch in production.

1

Create the initial cluster nodes data

Create a dictionary called nodes with these exact entries: 'node1': '7.10.0', 'node2': '7.10.0', 'node3': '7.10.0'

Elasticsearch

# Create the dictionary called nodes with the given node versions
# Your code here

Hint

Use curly braces to create a dictionary with keys as node names and values as version strings.

2

Set the target upgrade version

Create a variable called target_version and set it to the string '7.11.0'

Elasticsearch

nodes = {'node1': '7.10.0', 'node2': '7.10.0', 'node3': '7.10.0'}
# Create the variable target_version with value '7.11.0'
# Your code here

Hint

Assign the string '7.11.0' to the variable target_version.

3

Simulate rolling upgrade of nodes

Use a for loop with variable node to iterate over nodes keys and update each node's version to target_version inside the loop

Elasticsearch

nodes = {'node1': '7.10.0', 'node2': '7.10.0', 'node3': '7.10.0'}
target_version = '7.11.0'
# Use a for loop to update each node's version to target_version
# Your code here

Hint

Loop over the dictionary keys and assign the target_version to each key's value.

4

Print the final cluster versions

Write a print statement to display the nodes dictionary

Elasticsearch

nodes = {'node1': '7.10.0', 'node2': '7.10.0', 'node3': '7.10.0'}
target_version = '7.11.0'
for node in nodes:
    nodes[node] = target_version
# Print the nodes dictionary
# Your code here

Hint

Use print(nodes) to show the updated versions after upgrade.

Practice

1. What is the main purpose of performing a rolling upgrade in Elasticsearch?

easy

A. To disable the cluster permanently during upgrade

B. To upgrade all nodes simultaneously for faster updates

C. To upgrade nodes one by one without stopping the entire cluster

D. To delete old data before upgrading

Solution

1. Step 1: Understand rolling upgrade concept

   A rolling upgrade updates nodes one at a time to keep the cluster running.

2. Step 2: Compare options

   Only To upgrade nodes one by one without stopping the entire cluster describes upgrading nodes one by one without stopping the cluster.

3. Final Answer:

   To upgrade nodes one by one without stopping the entire cluster -> Option C

4. Quick Check:

   Rolling upgrade = upgrade nodes individually [OK]

Hint: Rolling upgrade means upgrading nodes one by one [OK]

Common Mistakes:

• Thinking all nodes upgrade at once
• Confusing rolling upgrade with cluster shutdown
• Assuming data is deleted during upgrade

2. Which command is recommended to disable shard allocation before starting a rolling upgrade?

easy

A. PUT /_cluster/settings {"persistent": {"cluster.routing.allocation.enable": "none"}}

B. POST /_cluster/disable_shards

C. GET /_cluster/settings {"allocation": "disable"}

D. DELETE /_cluster/shards

Solution

1. Step 1: Identify correct syntax to disable shard allocation

   The correct way is to update cluster settings with PUT and set allocation to "none".

2. Step 2: Check options

   Only PUT /_cluster/settings {"persistent": {"cluster.routing.allocation.enable": "none"}} uses the correct HTTP method, endpoint, and JSON body.

3. Final Answer:

   PUT /_cluster/settings {"persistent": {"cluster.routing.allocation.enable": "none"}} -> Option A

4. Quick Check:

   Disable shard allocation = PUT cluster settings with allocation none [OK]

Hint: Use PUT with cluster settings and allocation none to disable shards [OK]

Common Mistakes:

• Using wrong HTTP method like POST or GET
• Wrong endpoint or missing persistent key
• Trying to delete shards instead of disabling allocation

3. Given the following sequence during a rolling upgrade:

1. Disable shard allocation
2. Upgrade node 1
3. Upgrade node 2
4. Enable shard allocation

What is the expected cluster behavior after step 4?

medium

A. The cluster will stop accepting new data

B. The cluster will rebalance shards across all nodes

C. The cluster will delete old shards permanently

D. The cluster will remain unbalanced with shards stuck

Solution

1. Step 1: Understand shard allocation states

   Disabling shard allocation prevents shard movement during upgrade; enabling it allows rebalancing.

2. Step 2: Analyze cluster behavior after enabling allocation

   After enabling, the cluster redistributes shards to balance load.

3. Final Answer:

   The cluster will rebalance shards across all nodes -> Option B

4. Quick Check:

   Enable allocation = rebalance shards [OK]

Hint: Enabling shard allocation triggers shard rebalancing [OK]

Common Mistakes:

• Thinking cluster stops accepting data
• Assuming shards get deleted
• Believing shards remain stuck after enabling allocation

4. You ran a rolling upgrade but forgot to disable shard allocation first. What problem might occur?

medium

A. Shards may move during upgrade causing data loss or instability

B. The upgrade will fail immediately with syntax error

C. The cluster will automatically disable allocation for you

D. Nothing happens; upgrade proceeds safely

Solution

1. Step 1: Understand shard allocation role during upgrade

   Disabling allocation prevents shards from moving and keeps data safe during node restarts.

2. Step 2: Consequence of not disabling allocation

   If not disabled, shards may relocate while nodes restart, risking data loss or cluster instability.

3. Final Answer:

   Shards may move during upgrade causing data loss or instability -> Option A

4. Quick Check:

   Not disabling allocation risks shard movement and instability [OK]

Hint: Always disable shard allocation before upgrade to avoid shard moves [OK]

Common Mistakes:

• Expecting upgrade to fail with syntax error
• Assuming cluster disables allocation automatically
• Thinking upgrade is safe without disabling allocation

5. During a rolling upgrade, you want to ensure minimal downtime and data safety. Which sequence of actions is best practice?

hard

A. Upgrade all nodes simultaneously -> Disable shard allocation -> Enable shard allocation -> Restart cluster

B. Restart cluster -> Disable shard allocation -> Upgrade nodes one by one -> Enable shard allocation

C. Enable shard allocation -> Upgrade nodes one by one -> Disable shard allocation -> Verify cluster health

D. Disable shard allocation -> Upgrade nodes one by one -> Enable shard allocation -> Verify cluster health

Solution

1. Step 1: Identify correct upgrade steps

   Best practice is to disable shard allocation first to prevent shard moves, then upgrade nodes one by one.

2. Step 2: Finalize upgrade process

   After upgrading all nodes, enable shard allocation to rebalance shards and verify cluster health to confirm stability.

3. Final Answer:

   Disable shard allocation -> Upgrade nodes one by one -> Enable shard allocation -> Verify cluster health -> Option D

4. Quick Check:

   Disable allocation, upgrade nodes, enable allocation, check health [OK]

Hint: Disable allocation first, upgrade nodes, then enable allocation [OK]

Common Mistakes:

• Upgrading all nodes at once causing downtime
• Enabling allocation before upgrade completion
• Restarting cluster unnecessarily