Elasticsearch cluster.blocks.read_only Setting

Pulse - Elasticsearch Operations Done Right

On this page

Example Common Issues and Misuses Do's and Don'ts Frequently Asked Questions

The cluster.blocks.read_only setting in Elasticsearch is a cluster-wide setting that controls whether the entire cluster is in read-only mode. When enabled, it prevents any write operations on the cluster, including indexing new documents, updating existing ones, or making changes to cluster settings.

  • Default Value: false
  • Possible Values: true or false
  • Recommendations: This setting should be used with caution and typically only in specific scenarios such as during maintenance or to prevent data modifications in critical situations.

When set to true, the cluster enters a read-only state where:

  • Read operations (searches, gets) are still allowed
  • Write operations (index, update, delete) are blocked
  • Cluster state changes are prevented

Example

To enable read-only mode for the entire cluster:

PUT _cluster/settings
{
  "persistent": {
    "cluster.blocks.read_only": true
  }
}

This might be used when you need to perform maintenance on the cluster or when you want to prevent any accidental writes during a critical operation.

To disable read-only mode:

PUT _cluster/settings
{
  "persistent": {
    "cluster.blocks.read_only": null
  }
}

Common Issues and Misuses

  • Forgetting to disable read-only mode after maintenance, leading to unexpected write failures
  • Enabling read-only mode without proper communication to users or applications, causing confusion and potential data loss
  • Using this setting instead of more granular index-level read-only blocks when only specific indices need protection

Do's and Don'ts

Do's:

  • Use this setting for cluster-wide maintenance or emergency situations
  • Communicate clearly with all stakeholders before enabling read-only mode
  • Have a plan and timeline for disabling read-only mode
  • Monitor the cluster state to ensure it's not left in read-only mode unintentionally

Don'ts:

  • Don't use this setting for long-term read-only scenarios; consider other options like index-level blocks
  • Don't enable read-only mode without a clear purpose and plan
  • Don't forget to disable it after the maintenance or emergency situation is resolved

Frequently Asked Questions

Q: How does cluster.blocks.read_only differ from index blocks?
A: While cluster.blocks.read_only affects the entire cluster, index blocks can be applied to specific indices. Index blocks offer more granular control, allowing you to set read-only status on individual indices rather than the whole cluster.

Q: Can I still perform cluster state changes when cluster.blocks.read_only is true?
A: No, when cluster.blocks.read_only is set to true, it prevents most cluster state changes along with write operations. This includes changes to settings, mappings, and other cluster-level configurations.

Q: Will setting cluster.blocks.read_only to true affect ongoing ingestion or indexing jobs?
A: Yes, enabling this setting will cause all ongoing write operations, including ingestion and indexing jobs, to fail. It's important to coordinate the timing of enabling this setting to minimize disruption.

Q: How can I check if my cluster is currently in read-only mode?
A: You can check the current cluster settings using the Cluster Get Settings API:

GET _cluster/settings?include_defaults=true

Look for the "cluster.blocks.read_only" setting in the response.

Q: Is there a way to temporarily enable read-only mode without making it persistent?
A: Yes, you can use transient settings instead of persistent ones. Replace "persistent" with "transient" in the API call. Transient settings are lost upon a full cluster restart, while persistent settings are not.


Subscribe to the Pulse Newsletter

Get early access to new Pulse features, insightful blogs & exclusive events , webinars, and workshops.