# Configuración de Retention Policies (RP) en InfluxDB

### ¿Qué es una Retention Policy en InfluxDB? <a href="#qu-es-una-retention-policy-en-influxdb" id="qu-es-una-retention-policy-en-influxdb"></a>

Una Retention Policy en InfluxDB define:

* **Duración**: El tiempo que los datos serán almacenados antes de ser eliminados automáticamente.
* **Factor de replicación**: Cuántas copias de los datos se mantienen (aplicable en entornos de clúster).

En InfluxDB 1.x , cada base de datos puede tener varias políticas de retención, pero solo una puede ser la predeterminada.

### **Buckets y su relación con Retention Policies** <a href="#undefined" id="undefined"></a>

En InfluxDB 2.x, los *buckets* reemplazan a las bases de datos y políticas de retención de 1.x.

| Concepto InfluxDB 1.x      | Equivalente en InfluxDB 2.x |
| -------------------------- | --------------------------- |
| Database + RetentionPolicy | Bucket                      |

**Ejemplo:**

* Un bucket llamado `sensores_1h` puede configurarse para retener datos durante 1 hora.
* Otro bucket, `histórico_90d`, puede retener datos durante 90 días.

### ¿Por qué son importantes las Retention Policies? <a href="#por-qu-son-importantes-las-retention-policies" id="por-qu-son-importantes-las-retention-policies"></a>

* **Control de almacenamiento**: Evitan que la base de datos crezca indefinidamente, lo que puede afectar el rendimiento y aumentar los costes de almacenamiento.
* **Gestión del ciclo de vida de los datos**: Permiten conservar datos recientes con mayor granularidad y eliminar automáticamente los datos antiguos que ya no son relevantes.
* **Optimización para SCADA**: En sistemas industriales, se pueden definir diferentes buckets para alarmas, históricos y datos en tiempo real, cada uno con su propia política de retención.

### ¿Qué son los Shard y Shard Group?

<figure><img src="/files/kLgIa0idI55JLN4A6wEN" alt="" width="375"><figcaption><p>Diagrama de estructura de shard y shard group</p></figcaption></figure>

* **Shard:**\
  Un shard es una unidad física de almacenamiento que contiene datos de series temporales comprimidos y codificados para un rango de tiempo específico, definido por la duración del shard group. Cada shard almacena múltiples series y se representa como uno o varios archivos TSM en disco.
* **Shard group:**\
  Un shard group es un contenedor lógico que agrupa uno o más shards que cubren el mismo intervalo de tiempo dentro de un bucket. La duración del shard group determina el rango de tiempo que abarca (por ejemplo, 1 día, 1 semana) y está relacionada con la política de retención del bucket. En InfluxDB OSS, normalmente cada shard group contiene un solo shard.

**Ejemplo sencillo:**

* Un **shard** es como una carpeta donde guardas todos los recibos o documentos de un solo mes. Cada vez que llega un nuevo documento con la fecha de ese mes, lo metes en esa carpeta.
* Un **shard group** es como una caja donde pones todas las carpetas de varios meses seguidos, por ejemplo, todas las carpetas de un año.

### **Creación y configuración de Buckets con Retention Policy** <a href="#undefined" id="undefined"></a>

### **Desde la interfaz web (UI):**

1. Accede a la interfaz de InfluxDB 2.x.
2. Ve a la sección *Buckets*.
3. Haz clic en *Create Bucket*.
4. Asigna un nombre y selecciona la duración de la retención (por ejemplo, 7 días, 30 días o personalizada).
5. Guarda el bucket.

### **Desde la CLI:**

{% code title="bash" overflow="wrap" %}

```bash
influx bucket create \
  --name sensores_30d \
  --retention 720h
```

{% endcode %}

Esto crea un bucket llamado `sensores_30d` con una retención de 30 días (720 horas).

### **Desde la API:**

{% code title="text" overflow="wrap" %}

```javascript
POST /api/v2/buckets
{
  "name": "sensores_30d",
  "retentionRules": [
    {
      "type": "expire",
      "everySeconds": 2592000 // 30 días
    }
  ],
  "orgID": "<tu_org_id>"
}
```

{% endcode %}

### **Reglas y mejores prácticas** <a href="#undefined" id="undefined"></a>

* **Define la retención según el uso:** Datos críticos para análisis inmediato pueden retenerse menos tiempo; datos históricos agregados, más tiempo.
* **Evita buckets con retención infinita a menos que sea imprescindible**: El bucket `autogen` (retención infinita) puede crecer sin control.
* **Automatiza el downsampling:** Usa tareas para reducir la resolución de los datos que necesitan almacenarse más tiempo.
* **Revisa la configuración periódicamente:** Ajusta la retención según el crecimiento y necesidades del negocio.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://darioaplicano.gitbook.io/influxdb2.x/sesion-1/guion-de-la-sesion/documentacion/conceptos-clave-de-influxdb/configuracion-de-retention-policies-rp-en-influxdb.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
