Reinicio de un clúster de Aurora con disponibilidad de lectura
Con la característica de disponibilidad de lectura, puede reiniciar la instancia de escritura de su clúster de Aurora sin reiniciar las instancias del lector en el clúster de base de datos principal o secundario. Al hacerlo, puede ayudar a mantener la alta disponibilidad del clúster para las operaciones del lector mientras reinicia la instancia del escritor. Puede reiniciar las instancias del lector más tarde, según la programación que le resulte conveniente. Por ejemplo, en un clúster de producción, puede reiniciar las instancias del lector de una en una y comenzar solo después de que finalice el reinicio de la instancia principal. Para cada instancia de base de datos que reinicie, siga el procedimiento descrito en Reinicio de una instancia de base de datos dentro de un clúster de Aurora.
La característica de disponibilidad de lectura de los clústeres de base de datos principales está disponible en Aurora MySQL 2.10 y versiones posteriores. La característica de lectura de los clústeres de base de datos secundario está disponible en Aurora MySQL 3.06 y versiones posteriores.
Esta característica está disponible de forma predeterminada para las siguientes versiones de Aurora PostgreSQL:
Versión 15.2 y versiones posteriores a la 15
Versión 14.7 y versiones posteriores a la 14
Versión 13.10 y versiones posteriores a la 13
Versión 12.14 y versiones posteriores a la 12
Para obtener más información sobre la característica de disponibilidad de lectura en Aurora PostgreSQL, consulte Mejora de la disponibilidad de lectura de las réplicas de Aurora.
Antes de esta característica, reiniciar la instancia principal provocaba también el reinicio de cada instancia del lector. Si el clúster de Aurora ejecuta una versión anterior, utilice el procedimiento de reinicio descrito en Reinicio de un clúster de Aurora con disponibilidad de lectura en su lugar.
nota
El cambio en el comportamiento de reinicio en los clústeres de base de datos de Aurora con disponibilidad de lectura es diferente para las bases de datos globales de Aurora en versiones de Aurora MySQL anteriores a la 3.06. Si reinicia la instancia del escritor del clúster principal de una base de datos de Aurora global, las instancias del lector del clúster principal permanecen disponibles. Sin embargo, las instancias de base de datos de cualquier clúster secundario se reinician al mismo tiempo.
Hay una versión limitada de la característica de disponibilidad de lectura mejorada que es compatible con las bases de datos globales de Aurora para las versiones 12.16, 13.12, 14.9, 15.4 y posteriores de Aurora PostgreSQL.
Con frecuencia, reinicia el clúster después de realizar cambios en los grupos de parámetros del clúster. Puede realizar cambios en los parámetros siguiendo los procedimientos descritos en Grupos de parámetros para Amazon Aurora. Supongamos que reinicia la instancia de base de datos del escritor en un clúster de Aurora para aplicar cambios a los parámetros del clúster. Es posible que algunas o todas las instancias de base de datos del lector sigan utilizando la configuración de parámetros anterior. Sin embargo, las distintas configuraciones de parámetros no afectan la integridad de los datos del clúster. Los parámetros de clúster que afectan a la organización de los archivos de datos solo se utilizan por la instancia de base de datos del escritor.
Por ejemplo, en un clúster de Aurora MySQL puede actualizar los parámetros del clúster, como binlog_format y innodb_purge_threads, en la instancia del escritor antes de las instancias del lector. Solo la instancia del escritor escribe registros binarios y purga registros de deshacer. Para los parámetros que cambian la forma en que las consultas interpretan las instrucciones SQL o la salida de las consultas, es posible que deba reiniciar inmediatamente las instancias del lector. Esto se hace para evitar un comportamiento inesperado de la aplicación durante las consultas. Por ejemplo, supongamos que cambia el parámetro lower_case_table_names y reinicia la instancia del escritor. En este caso, es posible que las instancias del lector no puedan acceder a una tabla recién creada hasta que se reinicien todas.
Para obtener una lista de todos los parámetros de clúster de Aurora MySQL, consulte Parámetros de nivel de clúster.
Para obtener una lista de todos los parámetros de clúster de Aurora PostgreSQL, consulte Parámetros de nivel de clúster de Aurora PostgreSQL.
sugerencia
Aurora MySQL podría reiniciar algunas de las instancias del lector junto con la instancia del escritor si el clúster tiene una carga de trabajo en proceso con un alto rendimiento.
La reducción en el número de reinicios se aplica también durante las operaciones de conmutación por error. Aurora reinicia solo la instancia de base de datos del escritor y el destino de conmutación por error durante una conmutación por error. Otras instancias de base de datos del lector en el clúster siguen disponibles para continuar el procesamiento de consultas mediante conexiones con el punto de enlace del lector. Por lo tanto, puede mejorar la disponibilidad durante una conmutación por error si tiene más de una instancia de base de datos del lector en un clúster.
