Rolling upgrades in Elasticsearch - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to start a rolling upgrade by setting the cluster to read-only mode.

Elasticsearch

PUT /_cluster/settings
{
  "persistent": {
    "cluster.blocks.read_only": [1]
  }
}

Drag options to blanks, or click blank then click option'

Afalse

Btrue

C"true"

D"false"

Attempts:

3 left

💡 Hint

Common Mistakes

Using string values like "true" instead of boolean true.

Setting the value to false which disables read-only mode.

Setting cluster.blocks.read_only to true makes the cluster read-only, which is a common step before starting a rolling upgrade.

2fill in blank

medium

Complete the code to update the index settings to disable replicas during the rolling upgrade.

Elasticsearch

PUT /my-index/_settings
{
  "index": {
    "number_of_replicas": [1]
  }
}

Drag options to blanks, or click blank then click option'

A0

B"1"

C"0"

D1

Attempts:

3 left

💡 Hint

Common Mistakes

Using string values like "0" instead of numeric 0.

Setting replicas to 1 which keeps replicas enabled.

Setting number_of_replicas to 0 disables replicas, which helps reduce overhead during rolling upgrades.

3fill in blank

hard

Fix the error in the code to check the cluster health status during the rolling upgrade.

Elasticsearch

GET /_cluster/health
{
  "wait_for_status": [1]
}

Drag options to blanks, or click blank then click option'

A"yellow"

Bgreen

C"green"

Dyellow

Attempts:

3 left

💡 Hint

Common Mistakes

Using unquoted status values causing syntax errors.

Using the wrong status string.

The wait_for_status parameter requires a string value like "green" or "yellow" enclosed in quotes.

4fill in blank

hard

Fill both blanks to update the cluster settings to disable shard allocation and then re-enable it after the upgrade.

Elasticsearch

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": [1]
  }
}

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": [2]
  }
}

Drag options to blanks, or click blank then click option'

A"none"

B"all"

C"primaries"

D"new_primaries"

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect allocation values like "primaries" or "new_primaries".

Forgetting to use quotes around the values.

Setting cluster.routing.allocation.enable to "none" disables shard allocation during upgrade, and setting it back to "all" re-enables it.

5fill in blank

hard

Fill all three blanks to create a script that disables shard allocation, waits for green status, and then re-enables allocation.

Elasticsearch

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": [1]
  }
}

GET /_cluster/health
{
  "wait_for_status": [2],
  "timeout": "30s"
}

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": [3]
  }
}

Drag options to blanks, or click blank then click option'

A"none"

B"green"

C"all"

D"yellow"

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong status values like "yellow" instead of "green".

Not using quotes around string values.

Mixing up the order of disabling and enabling allocation.

This script disables shard allocation with "none", waits for the cluster to reach "green" status, then re-enables allocation with "all".

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