<commit_before>---
title: Anti-entropy service in InfluxDB Enterprise
aliases:
  - /enterprise_influxdb/v1.6/guides/anti-entropy/
menu:
  enterprise_influxdb_1_6:
    menu: Anti-entropy service
    weight: 40
    parent: Administration
---

## Introduction

Shard entropy refers to inconsistency among shards in a shard group.
This can be due to the "eventually consistent" nature of data stored in InfluxDB
Enterprise clusters or due to missing or unreachable shards.
The anti-entropy (AE) service ensures that each data node has all the shards it
owns according to the metastore and that all shards in a shard group are consistent.
Missing shards are automatically repaired without operator intervention while
out-of-sync shards can be manually queued for repair.
This guide covers how AE works and some of the basic situations where it takes effect.

## Concepts

The anti-entropy service is part of the `influxd` process running on each data node
that ensures the node has all the shards the metastore says it owns and
that those shards are in sync with others in the same shard group.
If any shards are missing, the AE service will copy existing shards from other shard owners.
If data inconsistencies are detected among shards in a shard group, you can
[envoke the AE process](#command-line-tools-for-managing-entropy) and queue the
out-of-sync shards for repair.
In the repair process, AE will sync the necessary updates from other shards
in the same shard group.

By default, the service checks every 30 seconds, as configured in the [`anti-entropy.check-interval`](/enterprise_influxdb/v1.6/administration/configuration/#check-interval-30s) setting.

The anti-entropy service can only address missing or inconsistent shards when
there is at least one copy of the shard available.
In other words, as long as new and healthy nodes are introduced, a replication
factor of 2 can recover from one missing or inconsistent node;
a replication factor of 3 can recover from two missing or inconsistent nodes, and so on.
A replication factor of 1 cannot be recovered by the anti-entropy service.

## Symptoms of entropy
The AE process automatically detects and fixes missing shards, but shard inconsistencies
must be [manually detected and queued for repair](#detecting-and-repairing-entropy).
There are symptoms of entropy that, if seen, would indicate an entropy repair is necessary.
<commit_msg>updated default anti-entropy.check-interval in AE doc<commit_after>---
title: Anti-entropy service in InfluxDB Enterprise
aliases:
  - /enterprise_influxdb/v1.6/guides/anti-entropy/
menu:
  enterprise_influxdb_1_6:
    menu: Anti-entropy service
    weight: 40
    parent: Administration
---

## Introduction

Shard entropy refers to inconsistency among shards in a shard group.
This can be due to the "eventually consistent" nature of data stored in InfluxDB
Enterprise clusters or due to missing or unreachable shards.
The anti-entropy (AE) service ensures that each data node has all the shards it
owns according to the metastore and that all shards in a shard group are consistent.
Missing shards are automatically repaired without operator intervention while
out-of-sync shards can be manually queued for repair.
This guide covers how AE works and some of the basic situations where it takes effect.

## Concepts

The anti-entropy service is part of the `influxd` process running on each data node
that ensures the node has all the shards the metastore says it owns and
that those shards are in sync with others in the same shard group.
If any shards are missing, the AE service will copy existing shards from other shard owners.
If data inconsistencies are detected among shards in a shard group, you can
[envoke the AE process](#command-line-tools-for-managing-entropy) and queue the
out-of-sync shards for repair.
In the repair process, AE will sync the necessary updates from other shards
in the same shard group.

By default, the service checks every 5 minutes, as configured in the [`anti-entropy.check-interval`](/enterprise_influxdb/v1.6/administration/configuration/#check-interval-5m) setting.

The anti-entropy service can only address missing or inconsistent shards when
there is at least one copy of the shard available.
In other words, as long as new and healthy nodes are introduced, a replication
factor of 2 can recover from one missing or inconsistent node;
a replication factor of 3 can recover from two missing or inconsistent nodes, and so on.
A replication factor of 1 cannot be recovered by the anti-entropy service.

## Symptoms of entropy
The AE process automatically detects and fixes missing shards, but shard inconsistencies
must be [manually detected and queued for repair](#detecting-and-repairing-entropy).
There are symptoms of entropy that, if seen, would indicate an entropy repair is necessary.

{'fraction_non_alphanumeric': 0.045736754966887415, 'fraction_numerical': 0.005794701986754967, 'mean_word_length': 4.6002317497103125, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3632344', 'n_tokens_mistral': 1300, 'n_tokens_neox': 1228, 'n_words': 689}