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.
# Alta disponibilidad y replicación de Amazon DocumentDB
Puede conseguir un alto nivel de disponibilidad y escalado de lectura en Amazon DocumentDB (con compatibilidad con MongoDB) mediante instancias de réplica. Un único clúster de Amazon DocumentDB admite una sola instancia principal y hasta 15 instancias de réplica. Dichas instancias pueden distribuirse entre las zonas de disponibilidad dentro de la región del clúster. La instancia principal acepta el tráfico de lectura y escritura, y las instancias de réplica solo aceptan solicitudes de lectura.
El volumen del clúster consta de varias copias de los datos del clúster. Sin embargo, los datos del volumen del clúster se representan como un único volumen lógico para la instancia principal y para las réplicas de Amazon DocumentDB del clúster. Las instancias de réplica presentan consistencia final. Devuelven los resultados de las consultas con un retardo de réplica mínimo, normalmente muy inferior a 100 milisegundos una vez que la instancia principal ha escrito una actualización. El retardo de la réplica varía en función de la velocidad de cambio de la base de datos. Es decir, durante los periodos en los que se produce una gran cantidad de operaciones de escritura en la base de datos, puede registrarse un aumento del retardo de réplica.
## Escalado de lectura
Las réplicas de Amazon DocumentDB funcionan bien para el escalado de lectura porque están totalmente dedicadas a las operaciones de lectura en el volumen del clúster. Las operaciones de escritura se administran en la instancia principal. El volumen del clúster lo comparten todas las instancias del clúster. Por lo tanto, no tiene que replicar y mantener una copia de los datos de cada réplica de Amazon DocumentDB.
## Alta disponibilidad
Cuando se crea un clúster de Amazon DocumentDB, dependiendo del número de zonas de disponibilidad del grupo de subredes (debe haber al menos dos), Amazon DocumentDB aprovisiona instancias en las distintas zonas de disponibilidad. Cuando se crea las instancias del clúster, Amazon DocumentDB distribuye automáticamente las instancias entre las zonas de disponibilidad de un grupo de subredes para equilibrar el clúster. Esta acción también impide que todas las instancias se encuentren en la misma zona de disponibilidad.
**Ejemplo**
Para ilustrarlo, imagine un ejemplo en el que se crea un clúster que tiene un grupo de subredes con tres zonas de disponibilidad: *AZ1*, *AZ* y *AZ3*.
Cuando se crea la primera instancia del clúster, es la instancia principal y se sitúa en una de las zonas de disponibilidad. En este ejemplo, está en *AZ1*. La segunda instancia que se crea es una instancia de réplica y se sitúa en una de las otras dos zonas de disponibilidad, por ejemplo *AZ2*. La tercera instancia que se crea también es una instancia de réplica y se sitúa en la zona de disponibilidad restante, *AZ3*. Si se crean más instancias, estas se distribuyen entre las distintas zonas de disponibilidad para lograr el equilibrio en el clúster.
Si se produce un error en la instancia principal (AZ1), se activará una conmutación por error y una de las réplicas existentes pasará a ser la instancia principal. Cuando se recupere la antigua instancia principal, se convertirá en una réplica en la misma zona de disponibilidad en la que se aprovisionó (AZ1). Al suministrar un clúster de tres instancias, Amazon DocumentDB sigue conservando ese clúster de tres instancias. Amazon DocumentDB gestiona automáticamente la detección, la conmutación por error y la recuperación de los errores de las instancias sin ninguna intervención manual.
Cuando Amazon DocumentDB realiza una conmutación por error y recupera una instancia, la instancia recuperada permanece en la zona de disponibilidad en la que se aprovisionó originalmente. Sin embargo, el rol de la instancia podría cambiar de principal a réplica. Esto tiene por objeto evitar que una serie de conmutaciones por error pueda provocar que todas las instancias se encuentren en la misma zona de disponibilidad.
Puede especificar réplicas de Amazon DocumentDB para que actúen como destino para las conmutaciones por error. Es decir, si la instancia principal falla, la réplica de un tercero o la réplica de Amazon DocumentDB que ha especificado pasa a ser la instancia principal. En este proceso se produce una breve interrupción durante la cual las solicitudes de escritura y lectura realizadas a la instancia principal generan errores con una excepción. Si el clúster de Amazon DocumentDB no incluye ninguna réplica de Amazon DocumentDB; la instancia principal se vuelve cuando produce un error. Promover una réplica de Amazon DocumentDB es mucho más rápido que volver a crear la instancia principal.
Para escenarios de alta disponibilidad, le recomendamos que cree una o varias réplicas de Amazon DocumentDB. Dichas réplicas deberían ser de la misma clase de instancia que la instancia principal y estar en zonas de disponibilidad distintas para el clúster de Amazon DocumentDB.
Para obtener más información, consulte los siguientes temas:
+ [Información general de la tolerancia a errores de clúster de Amazon DocumentDB](db-cluster-fault-tolerance.md)
+ [Conmutación por error a Amazon DocumentDB](failover.md)
+ [Control del destino de la conmutación por error](failover.md#failover-target_control)
### Alta disponibilidad con clústeres globales
Para una alta disponibilidad en varias Regiones de AWS, puede configurar [clústeres globales de Amazon DocumentDB](https://docs.aws.amazon.com/documentdb/latest/developerguide/global-clusters.html). Cada clúster global abarca varias regiones, lo que permite lecturas globales de baja latencia y la recuperación de desastres de interrupciones en una Región de AWS. Amazon DocumentDB maneja automáticamente la reproducción de todos los datos y actualizaciones desde la región primaria a cada una de las regiones secundarias.
## Adición de réplicas de
La primera instancia que se añade al clúster es la instancia principal. Cada instancia de base de datos que se añade después de la primera instancia es una instancia de réplica. Un clúster puede tener hasta 15 instancias de réplica, además de la instancia principal.
Cuando crea un clúster mediante la Consola de administración de AWS, se crea automáticamente una instancia principal al mismo tiempo. Para crear una réplica al mismo tiempo que crea el clúster y la instancia principal, seleccione **Create replica in different zone (Crear réplica en zona diferente)**. Para obtener más información, consulte el paso 4.d de [Creación de un clúster de Amazon DocumentDB](db-cluster-create.md). Para añadir más réplicas a un clúster de Amazon DocumentDB, consulte [Agregación de una instancia de Amazon DocumentDB a un clúster](db-instance-add.md).
Cuando usa la AWS CLI para crear el clúster, debe crear explícitamente la instancia principal y las instancias de réplica. Para obtener más información, consulte la sección "Mediante la AWS CLI" de los temas siguientes:
+ [Creación de un clúster de Amazon DocumentDB](db-cluster-create.md)
+ [Agregación de una instancia de Amazon DocumentDB a un clúster](db-instance-add.md)
# Conmutación por error a Amazon DocumentDB
En algunos casos, como en determinados tipos de mantenimiento planificado, o en el improbable caso de que se produzca un error en el nodo principal o en la zona de disponibilidad, Amazon DocumentDB (con compatibilidad con MongoDB) detectará el error y reemplazará el nodo principal. Durante una conmutación por error, el tiempo de inactividad de escritura se minimiza. Esto se debe a que el papel del nodo principal se conmuta por error a una de las réplicas de lectura en lugar de tener que crear y aprovisionar un nuevo nodo principal. Esta detección de error y promoción de réplica garantizan la posibilidad de reanudar la escritura en el nuevo principal tan pronto como se complete la promoción.
Para que la conmutación por error funcione, el clúster debe tener como mínimo dos instancias: una instancia principal y al menos una de réplica.
**nota**
Este tema solo se aplica a los clústeres basados en instancias de Amazon DocumentDB. No se aplica a los clústeres elásticos o globales.
## Control del destino de la conmutación por error
Amazon DocumentDB proporciona niveles de conmutación por error como una forma de controlar qué instancia de réplica pasa a ser la instancia principal cuando se produce una conmutación por error.
**Niveles de conmutación por error**
Cada instancia de réplica está asociada a un nivel de conmutación por error (0-15). Cuando se produce una conmutación por error debido a tareas de mantenimiento o al caso improbable de que se produzca un error de hardware, la instancia principal se conmuta a una réplica con el nivel de prioridad mayor (el nivel más bajo). Si varias réplicas tienen el mismo nivel de prioridad, la instancia principal se conmutará a la réplica de ese nivel cuyo tamaño sea lo más similar a la principal anterior.
Estableciendo el nivel de conmutación por error para un grupo de réplicas seleccionadas en `0` (la prioridad más alta), puede asegurarse de que una conmutación por error promoverá una de las réplicas de ese grupo. En la práctica, puede evitar determinadas réplicas pasen a ser la instancia principal en caso de que se produzca una conmutación por error asignando un nivel de prioridad bajo (un número alto) a esas réplicas. Esto resulta útil en aquellos casos en los que determinadas réplicas se usan ampliamente en una aplicación y la conmutación por error a una de ellas afectaría negativamente a una aplicación crítica.
Puede configurar el nivel de conmutación por error de una instancia cuando la cree o modificándola más adelante. La configuración del nivel conmutación por error de una instancia modificando la instancia no genera una conmutación por error. Para obtener más información, consulte los siguientes temas:
+ [Agregación de una instancia de Amazon DocumentDB a un clúster](db-instance-add.md)
+ [Modificación de una instancia de base de datos de Amazon DocumentDB](db-instance-modify.md)
Al iniciar manualmente una conmutación por error, dispone de dos métodos para controlar qué instancia de réplica pasa a ser la principal: los niveles de conmutación por error indicados anteriormente y el parámetro `--target-db-instance-identifier`.
**--`target-db-instance-identifier`**
Para las pruebas, puede forzar una conmutación por error mediante la operación `failover-db-cluster`. Puede utilizar el parámetro `--target-db-instance-identifier` para especificar qué réplica pasará a ser la instancia principal. El uso del parámetro `--target-db-instance-identifier` invalida el nivel de prioridad de conmutación por error. Si no especifica el parámetro `--target-db-instance-identifier`, la conmutación por error de la instancia principal se rige por el nivel de prioridad de conmutación por error.
## ¿Qué ocurre durante una conmutación por error?
Amazon DocumentDB administra automáticamente la conmutación por error para que sus aplicaciones puedan reanudar las operaciones de la base de datos lo antes posible y sin intervención administrativa.
+ Si dispone de una réplica de Amazon DocumentDB en la misma zona de disponibilidad o en otra distinta cuando se realiza la conmutación por error, Amazon DocumentDB cambia el registro de nombre canónico (CNAME) para que su instancia apunte a la réplica en buen estado que, a su vez, se convierte en la nueva instancia principal. La conmutación por error suele completarse en 30 segundos de principio a fin.
+ Si no tiene una instancia de réplica de Amazon DocumentDB (por ejemplo, un clúster de instancia única), Amazon DocumentDB intentará crear una nueva instancia en la misma zona de disponibilidad que la instancia original. Este reemplazo de la instancia original se lleva a cabo con el mayor esfuerzo, pero puede fallar si, por ejemplo, existe un problema que esté afectando a la zona de disponibilidad de manera generalizada.
La aplicación debe reintentar establecer las conexiones de la base de datos en caso de que se pierda la conexión.
## Prueba de conmutación por error
Una conmutación por error de un clúster promueve una de las réplicas de Amazon DocumentDB (instancias de solo lectura) del clúster a instancia principal (la instancia de escritura del clúster).
Cuando se produce un error en la instancia principal, Amazon DocumentDB conmuta automáticamente a una réplica de Amazon DocumentDB, si existe. Puede forzar una conmutación por error cuando desee simular un error en una instancia principal para realizar pruebas. Cada instancia de un clúster tiene su propia dirección de punto de conexión. Por lo tanto, es necesario eliminar y restablecer las conexiones existentes que utilizan dichas direcciones de punto de conexión cuando finalice la conmutación por error.
Para forzar una conmutación por error, utilice la operación `failover-db-cluster` con los parámetros que se indican a continuación.
+ `--db-cluster-identifier`: obligatorio. El nombre del clúster de base de datos que se va a conmutar por error.
+ `--target-db-instance-identifier`: opcional. El nombre de la instancia que pasará a ser la instancia principal.
**Example**
La siguiente operación fuerza una conmutación por error del clúster `sample-cluster`. No especifica qué instancia se convertirá en la nueva instancia principal, por lo que Amazon DocumentDB elige la instancia de acuerdo con el nivel de prioridad de conmutación por error.
Para Linux, macOS o Unix:
```
aws docdb failover-db-cluster \
--db-cluster-identifier sample-cluster
```
Para Windows:
```
aws docdb failover-db-cluster ^
--db-cluster-identifier sample-cluster
```
La siguiente operación fuerza una conmutación por error del clúster `sample-cluster`, especificando que `sample-cluster-instance` pasará a ser la instancia principal. (Observe `"IsClusterWriter": true` en el resultado).
Para Linux, macOS o Unix:
```
aws docdb failover-db-cluster \
--db-cluster-identifier sample-cluster \
--target-db-instance-identifier sample-cluster-instance
```
Para Windows:
```
aws docdb failover-db-cluster ^
--db-cluster-identifier sample-cluster ^
--target-db-instance-identifier sample-cluster-instance
```
La salida de esta operación será similar a lo que se indica a continuación (formato JSON).
```
{
"DBCluster": {
"HostedZoneId": "Z2SUY0A1719RZT",
"Port": 27017,
"EngineVersion": "3.6.0",
"PreferredMaintenanceWindow": "thu:04:05-thu:04:35",
"BackupRetentionPeriod": 1,
"ClusterCreateTime": "2018-06-28T18:53:29.455Z",
"AssociatedRoles": [],
"DBSubnetGroup": "default",
"MasterUsername": "master-user",
"Engine": "docdb",
"ReadReplicaIdentifiers": [],
"EarliestRestorableTime": "2018-08-21T00:04:10.546Z",
"DBClusterIdentifier": "sample-cluster",
"ReaderEndpoint": "sample-cluster.node.us-east-1.docdb.amazonaws.com",
"DBClusterMembers": [
{
"DBInstanceIdentifier": "sample-cluster-instance",
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1,
"IsClusterWriter": true
},
{
"DBInstanceIdentifier": "sample-cluster-instance-00",
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1,
"IsClusterWriter": false
},
{
"DBInstanceIdentifier": "sample-cluster-instance-01",
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1,
"IsClusterWriter": false
}
],
"AvailabilityZones": [
"us-east-1b",
"us-east-1c",
"us-east-1a"
],
"DBClusterParameterGroup": "default.docdb3.6",
"Endpoint": "sample-cluster.node.us-east-1.docdb.amazonaws.com",
"IAMDatabaseAuthenticationEnabled": false,
"AllocatedStorage": 1,
"LatestRestorableTime": "2018-08-22T21:57:33.904Z",
"PreferredBackupWindow": "00:00-00:30",
"StorageEncrypted": false,
"MultiAZ": true,
"Status": "available",
"DBClusterArn": "arn:aws:rds:us-east-1:123456789012:cluster:sample-cluster",
"VpcSecurityGroups": [
{
"Status": "active",
"VpcSecurityGroupId": "sg-12345678"
}
],
"DbClusterResourceId": "cluster-ABCDEFGHIJKLMNOPQRSTUVWXYZ"
}
}
```
## Retraso de replicación
El retraso de replicación suele ser de 50 ms o menos. Los motivos más comunes del aumento del retraso en la réplica son:
+ Una velocidad de escritura alta en la principal que hace que las réplicas de lectura queden por detrás de la principal.
+ Discrepancia en las réplicas de lectura entre consultas de larga duración (p. ej., escaneos secuenciales de gran tamaño o consultas de agregación) y la replicación de escritura entrante.
+ Gran cantidad de consultas simultáneas en las réplicas de lectura.
Para minimizar el retraso en la replicación, pruebe estas técnicas de solución de problemas:
+ Si tiene una alta velocidad de escritura o un uso elevado de la CPU, le recomendamos que escale verticalmente las instancias del clúster.
+ Si hay consultas de larga duración en las réplicas de lectura y se actualizan con mucha frecuencia los documentos consultados, plantéese la posibilidad de modificar las consultas de larga duración o ejecutarlas en la réplica principal o de escritura para evitar problemas en las réplicas de lectura.
+ Si hay un gran número de consultas simultáneas o un uso elevado de la CPU solo en las réplicas de lectura, otra opción es escalar horizontalmente el número de réplicas de lectura para distribuir la carga de trabajo.
+ Dado que el retraso en la replicación se debe a un alto rendimiento de escritura y a que las consultas se ejecutan durante mucho tiempo, recomendamos solucionar el retraso de la replicación utilizando la métrica DBClusterReplicaLagMaximum CW en combinación con el registrador de consultas lentas y las métricas `WriteThroughput`/`WriteIOPS`.
En general, se recomienda que todas las réplicas sean del mismo tipo de instancia, de modo que una conmutación por error de un clúster no provoque una degradación del rendimiento.
Si va a elegir entre escalar verticalmente y horizontalmente (por ejemplo, seis instancias más pequeñas frente a tres instancias más grandes), normalmente recomendamos que primero intente escalar verticalmente (instancias más grandes) antes de hacerlo horizontalmente, ya que obtendrá una caché de búfer más grande por instancia de base de datos.
De forma proactiva, debe configurar una alarma de retraso de replicación y establecer su umbral en un valor que considere que es el límite superior del retraso (u “obsoleto”) que pueden estar los datos de las instancias de réplica antes de que comiencen a afectar a la funcionalidad de la aplicación. En general, le recomendamos que se supere el umbral de retraso de replicación en varios puntos de datos antes de emitir una alarma debido a las cargas de trabajo transitorias.
**nota**
Además, recomendamos que configure otra alarma para los retrasos de replicación que superen los 10 segundos. Si supera este umbral para varios puntos de datos, recomendamos que escale verticalmente las instancias o reduzca el rendimiento de la escritura en la instancia principal.