Splunk® Enterprise

Managing Indexers and Clusters of Indexers

Splunk Enterprise version 8.0 is no longer supported as of October 22, 2021. See the Splunk Software Support Policy for details. For information about upgrading to a supported version, see How to upgrade Splunk Enterprise.
This documentation does not apply to the most recent version of Splunk® Enterprise. For documentation on the most recent version, go to the latest release.

Anomalous bucket issues

Anomalous buckets are buckets that remain in the fixup state indefinitely, without making any progress. Such buckets can indicate or cause a larger problem with your system. An anomalous bucket, for example, can prevent the cluster from meeting its replication and search factors.

The Bucket Status dashboard lets you identify anomalous buckets. It also allows you to take actions on those buckets that can often fix them. Specifically, you can:

  • Get details on a bucket.
  • Roll the bucket from hot to warm.
  • Resync the state of a bucket copy between a peer and the master.
  • Delete a copy of the bucket on a single peer, or delete all copies of the bucket across all peers.

Consult with Splunk Support before performing these actions on a bucket. Some of the actions, performed without full understanding, can lead to further problems with your system or even to irreversible data loss.

Identify anomalous buckets

To identify anomalous buckets and to take action on them, use the Bucket Status dashboard.

  1. From the Master dashboard, go to the Bucket Status dashboard. See View the bucket status dashboard.
  2. Click the Fixup Tasks - Pending tab.

You can filter the list of pending buckets by fixup type and by the amount of time that they have been waiting for fixup. If a bucket has been waiting an unusual amount of time for fixup, it might be the cause of problems.

Take action on an anomalous bucket

For buckets that have been stuck in fixup for long periods of time, you can take remedial action.

  1. Click Action for the bucket that you want to manage.
  2. Select one of the available actions:
    • View bucket details
    • Roll
    • Resync
    • Delete Copy
    A pop-up window appears to guide you through the selected action.

Use the following sequence when performing actions on anomalous bucket.

  1. View bucket details
  2. Roll
  3. Resync
  4. Delete Copy

Only perform the next action if the previous one does not resolve the issue.

View bucket details

This pop-up window provides details on the bucket such as:

  • The bucket size
  • Whether it is frozen
  • Whether it has been force-rolled
  • Whether it is a standalone bucket
  • The peers on which it resides

These details can help to narrow down the cause of the bucket problem and what action to take to remediate it.

Roll

This action rolls the bucket from the hot state to the warm state. It has an effect only on hot buckets.

Resync

The master holds information about each copy of a bucket. However, in some cases, the master can have incorrect information about the copy on a particular peer. This condition can occur when communication problems arise between the master and a peer.

Here are some examples of bucket copy state information that can be out of sync between peer and master:

  • Whether the copy is searchable
  • Whether the copy is hot or warm
  • Whether the copy is primary
  • Whether the copy exists on that peer

The peer knows the state of its bucket copies, so if the peer and the master have different state information for a bucket copy, the information on the master is incorrect.

To resolve this problem, resync the bucket copy's state on the master. When you resync a bucket, you specify the peer with the copy that you need to resync. The resync process causes the peer to send the master its current information about the bucket copy.

Delete Copy

You can delete either a single copy of a bucket on a specific peer, or all copies of a bucket across the entire cluster.

If deleting a single copy causes the cluster to lose its complete state, the cluster will engage in fixup activities so that the bucket again meets both the search factor and the replication factor. This situation might result in another copy of the bucket appearing on the same peer. If, however, the specified bucket is frozen, the cluster does not attempt any fixup activities.

Performing the delete action on all copies of a bucket across the cluster results in irreversible data loss.

Last modified on 13 October, 2020
Bucket replication issues   Configuration bundle issues

This documentation applies to the following versions of Splunk® Enterprise: 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 7.3.9, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.0.8, 8.0.9, 8.0.10


Was this topic useful?







You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters