Para obtener capacidades similares a las de Amazon Timestream, considere Amazon Timestream LiveAnalytics para InfluxDB. Ofrece una ingesta de datos simplificada y tiempos de respuesta a las consultas en milisegundos de un solo dígito para realizar análisis en tiempo real. Obtenga más información [aquí](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html).
Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Periodos de mantenimiento
Amazon Timestream para InfluxDB realiza tareas de mantenimiento de forma periódica en sus recursos. El mantenimiento suele implicar actualizaciones de los siguientes recursos de su instancia de base de datos:
+ Hardware subyacente
+ Sistema operativo (SO) subyacente
+ Versión del motor de base de datos
Las actualizaciones del sistema operativo suelen deberse a motivos de seguridad.
Para realizar algunas tareas de mantenimiento, es necesario que Amazon Timestream para InfluxDB desconecte la instancia de base de datos durante un breve periodo de tiempo. Entre los elementos de mantenimiento que requieren que un recurso esté desconectado están el sistema operativo necesario o la aplicación de parches a la base de datos. Los parches obligatorios que tienen que ver con la seguridad y la fiabilidad de la instancia son los únicos que se programan automáticamente. Estos parches se producen con poca frecuencia, normalmente una vez cada pocos meses. Rara vez se requiere más de una fracción de su período de mantenimiento.
**Periodo de mantenimiento**
Cada instancia de base de datos de Amazon Timestream for InfluxDB tiene un período de mantenimiento semanal durante el cual se realiza el mantenimiento. Puede configurar su ventana de mantenimiento de dos maneras:
+ **Servicio gestionado (predeterminado)**: Amazon Timestream para InfluxDB determina el intervalo de mantenimiento óptimo para el recurso.
+ **Administrado por el cliente**: usted especifica el período de mantenimiento preferido mediante el formato `ddd:HH:MM-ddd:HH:MM` (por ejemplo,). `Sun:02:00-Sun:04:00` El período debe ser de al menos 2 horas y no más de 24 horas. Se admiten ventanas que crucen la medianoche.
Puede establecer el período de mantenimiento que prefiera al crear una instancia de base de datos o cambiarlo más adelante mediante la `update-db-instance` API.
**Zona horaria**
Puede especificar una zona horaria para el período de mantenimiento mediante el `timezone` campo. Cuando se establece, los horarios de las ventanas se interpretan en la zona horaria especificada. El campo `timezone` es obligatorio. Utilice los identificadores de zona horaria de la IANA, como o. `America/New_York` `Asia/Tokyo` El sistema gestiona automáticamente las transiciones del horario de verano.
**Ejemplos de CLI**
Cree una instancia de base de datos con una ventana de mantenimiento personalizada:
```
aws timestream-influxdb create-db-instance \
--name "my-influxdb" \
--db-instance-type db.influx.medium \
--allocated-storage 50 \
--vpc-subnet-ids subnet-12345abc subnet-67890def \
--vpc-security-group-ids sg-12345abc \
--maintenance-schedule '{
"timezone": "America/New_York",
"preferredMaintenanceWindow": "Sun:02:00-Sun:04:00"
}' \
--region us-west-2
```
Actualice el período de mantenimiento de una instancia de base de datos existente:
```
aws timestream-influxdb update-db-instance \
--identifier \
--maintenance-schedule '{
"timezone": "Asia/Tokyo",
"preferredMaintenanceWindow": "Wed:03:00-Wed:06:00"
}' \
--region us-west-2
```
Volver al servicio gestionado:
```
aws timestream-influxdb update-db-instance \
--identifier \
--maintenance-schedule '{
"timezone": "UTC",
"preferredMaintenanceWindow": ""
}' \
--region us-west-2
```
**importante**
Si una acción de mantenimiento requerida se ha aplazado durante más de 25 días, el servicio puede realizar el mantenimiento fuera del plazo que prefiera para garantizar la seguridad y la fiabilidad de su recurso.
Durante el mantenimiento, el estado de la instancia de base de datos cambia a`MAINTENANCE`. Una vez finalizado, el estado vuelve a`AVAILABLE`.
**Zonas horarias compatibles**
Utilice los identificadores de zona horaria de la IANA. No se admiten abreviaturas de zona horaria como, y`EST`. `PST` `GMT+5`
| **Zona horaria** | **Descripción** |
| --- | --- |
| UTC | Hora universal coordinada (predeterminada) |
| America/New\_York | Este de los Estados Unidos |
| America/Chicago | Centro de los Estados Unidos |
| America/Denver | Montaña estadounidense |
| America/Los\_Angeles | Pacífico estadounidense |
| America/Sao\_Paulo | Brasil |
| Europe/London | UK |
| Europe/Paris | Europa Central |
| Europe/Berlin | Alemania |
| Asia/Tokyo | Japón |
| Asia/Shanghai | China |
| Asia/Singapore | Singapur |
| Asia/Mumbai | India |
| Asia/Dubai | EMIRATOS ÁRABES UNIDOS |
| Australia/Sydney | Australia Oriental |
| Pacific/Auckland | Nueva Zelanda |
**Consideraciones**
+ Los períodos de mantenimiento definen cuándo se *puede* realizar el mantenimiento, no cuándo se *realizará*. El mantenimiento se realiza según sea necesario, normalmente no más de una vez por semana.
+ El mantenimiento se requiere al menos una vez al mes para aplicar los parches de seguridad y confiabilidad.
+ En el caso de las implementaciones Multi-AZ, el mantenimiento se realiza primero en la zona de espera y, a continuación, se produce una conmutación por error, lo que minimiza el tiempo de inactividad.
+ Si utiliza una zona horaria con transiciones de horario de verano, evite programar el mantenimiento entre la 1:00 a. m. y las 3:00 a. m. para evitar saltarse las ventanas durante la próxima primavera.