Fiabilidad de Amazon Aurora

Aurora se ha diseñado para ofrecer fiabilidad, durabilidad y tolerancia a errores. Puede diseñar la arquitectura de su clúster de bases de datos Aurora para mejorar la disponibilidad por medio de acciones como añadir réplicas de Aurora y situarlas en distintas zonas de disponibilidad, y Aurora incluye también varias características automáticas que la convierten en una solución de base de datos confianza.

Reparación automática del almacenamiento

Como Aurora mantiene varias copias de sus datos en tres zonas de disponibilidad, el riesgo de perder datos como resultado de un error de disco se reduce sustancialmente. Aurora también detecta automáticamente los errores de los volúmenes de disco que integran el volumen de clúster. Cuando se produce un error en un segmento de un volumen de disco, Aurora repara inmediatamente el segmento. Cuando Aurora repara el segmento de disco, utiliza los datos de los otros volúmenes que componen el volumen de clúster para garantizar que los datos del segmento reparado están actualizados. Como resultado, Aurora evita las pérdidas de datos y reduce la necesidad de realizar una restauración a un momento dado para recuperarse cuando se produce un error del disco.

Caché de páginas que puede sobrevivir

En Aurora, la memoria caché de páginas de cada instancia de base de datos se administra en un proceso independiente de la base de datos, lo que permite a la memoria caché de páginas sobrevivir con independencia de la base de datos. (La memoria caché de páginas también se denomina grupo de búferes InnoDB en Aurora MySQL y memoria caché de búferes en Aurora PostgreSQL).

En el improbable caso de que se produzca un fallo en la base de datos, la memoria caché de páginas permanece en la memoria, lo que mantiene las páginas de datos actuales "calientes" en la memoria caché de páginas cuando se reinicia la base de datos. Esto proporciona una ventaja de rendimiento al evitar la necesidad de que las consultas iniciales ejecuten operaciones de E/S de lectura para "calentar" la memoria caché de páginas.

En el caso de Aurora MySQL, el comportamiento de la memoria caché de páginas al reiniciar y conmutar por error es el siguiente:

• Puede reiniciar la instancia de escritor sin reiniciar las instancias de lector.

  • Si las instancias del lector no se reinician cuando se reinicia la instancia del escritor, no pierden su memoria caché de páginas.

  • Si las instancias del lector se reinician cuando se reinicia la instancia del escritor, pierden su memoria caché de páginas.

• Cuando se reinicia una instancia del lector, la memoria caché de páginas de las instancias del escritor y del lector sobreviven.

• Cuando el clúster de base de datos falla, el efecto es similar a cuando se reinicia una instancia del escritor. En la nueva instancia del escritor (anteriormente era la instancia del lector) la memoria caché de páginas sobrevive, pero en la instancia del lector (anteriormente era la instancia del escritor), la memoria caché de páginas no sobrevive.

En el caso de Aurora PostgreSQL, puede utilizar la administración de la memoria caché de páginas del clúster para preservar la memoria caché de páginas de una instancia del lector designada que se convierte en la instancia del escritor después de la conmutación por error. Para obtener más información, consulte Recuperación rápida después de una conmutación por error con la administración de caché del clúster para Aurora PostgreSQL.

Recuperación de reinicios no planificados

Aurora se ha diseñado para recuperarse de reinicio no planificado casi instantáneamente y continuar sirviendo sus datos de aplicación sin el registro binario. Aurora se recupera de forma asíncrona en subprocesos paralelos, de forma que su base de datos permanece abierta y disponible inmediatamente después de un reinicio no planificado.

Para obtener más información, consulte Tolerancia a errores para un clúster de base de datos de Aurora y Optimizaciones para reducir el tiempo de reinicio de la base de datos.

A continuación se indican consideraciones para registro binario y recuperación de reinicio no planificado en Aurora MySQL:

• Habilitar el registro binario en Aurora afecta directamente al tiempo de recuperación tras un reinicio no planificado, ya que fuerza a la instancia de base de datos a realizar la recuperación de log binario.

• El tipo de registro binario utilizado afecta al tamaño y a la eficiencia del registro. Para la misma cantidad de actividad de base de datos, algunos formatos registran más información que otros en los logs binarios. La siguiente configuración del parámetro binlog_format da lugar a distintas cantidades de datos de log:

  • ROW: la mayor cantidad de datos de registro

  • STATEMENT: la menor cantidad de datos de registro

  • MIXED: una cantidad moderada de datos de registro que habitualmente ofrece la mejor combinación de integridad de datos y rendimiento

  La cantidad de datos de log binario afecta al tiempo de recuperación. Si hay más datos registrados en los logs binarios, la instancia de base de datos debe procesar más datos durante la recuperación, lo que aumenta el tiempo de recuperación.

• Para reducir la sobrecarga computacional y mejorar los tiempos de recuperación con el registro binario, puede utilizar el binlog mejorado. El binlog mejorado acelera el tiempo de recuperación de la base de datos hasta en un 99 %. Para obtener más información, consulte Configuración del binlog mejorado para Aurora MySQL.

• Aurora no necesita que los logs binarios repliquen datos dentro de un clúster de bases de datos o que realicen una restauración a un momento dado (PITR).

• Si no necesita el log binario para replicación externa (o un flujo de log binario externo), le recomendamos que establezca el parámetro binlog_format en OFF para deshabilitar el registro binario. Al hacerlo se reduce el tiempo de recuperación.

Para obtener más información sobre el registro binario de Aurora y la replicación, consulte Replicación con Amazon Aurora. Para obtener más información acerca de las implicaciones de distintos tipos de replicación de MySQL, consulte Advantages and Disadvantages of Statement-Based and Row-Based Replication en la documentación de MySQL.