Replicación con Amazon Aurora
Existen varias opciones de replicación con Aurora. Cada clúster de base de datos Aurora tiene replicación integrada entre varias instancias de base de datos en el mismo clúster. También puede configurar la replicación con el clúster Aurora como origen o destino. Al replicar datos dentro o fuera de un clúster Aurora, puede elegir entre características integradas como bases de datos Aurora globales o los mecanismos de replicación tradicionales para los motores de base de datos MySQL o PostgreSQL. Puede elegir las opciones adecuadas en función de cuál proporciona la combinación correcta de alta disponibilidad, conveniencia y rendimiento para sus necesidades. En las siguientes secciones se explica cómo y cuándo elegir cada técnica.
Réplicas de Aurora
Cuando crea una segunda, tercera, etc. instancia de base de datos en un clúster de base de datos Aurora aprovisionada, Aurora configura automáticamente la replicación desde la instancia de base de datos de escritor a todas las demás instancias de base de datos. Estas otras instancias de base de datos son de solo lectura y se conocen como réplicas Aurora. También nos referimos a ellas como instancias de lector al analizar las formas en que puede combinar instancias de base de datos de escritor y lector dentro de un clúster.
Las réplicas Aurora tienen dos propósitos principales. Puede emitirles consultas para escalar las operaciones de lectura de la aplicación. Normalmente lo hace conectándose al punto de enlace del lector del clúster. De esta forma, Aurora puede distribuir la carga de conexiones de solo lectura entre tantas réplicas Aurora como tenga en el clúster. Las réplicas Aurora también ayudan a aumentar la disponibilidad. Si la instancia de escritor de un clúster deja de estar disponible, Aurora promociona automáticamente una de las instancias de lector para que tome su lugar como el nuevo escritor.
Un clúster de base de datos Aurora puede contener hasta réplicas 15 Aurora. Se pueden distribuir réplicas de Aurora entre las distintas zonas de disponibilidad que abarca un clúster de base de datos dentro de una región de AWS.
Los datos del clúster de base de datos tienen sus propias características de alta disponibilidad y confiabilidad, independientemente de las instancias de base de datos del clúster. Si no está familiarizado con las funciones Aurora de almacenamiento, consulte Información general del almacenamiento de Amazon Aurora. El volumen del clúster de base de datos consta físicamente de varias copias de los datos del clúster de base de datos. La instancia principal y las réplicas Aurora del clúster de base de datos ven los datos del volumen del clúster como un único volumen lógico.
Como resultado, todas las réplicas de Aurora devuelven los mismos datos para los resultados de las consultas con un retraso de réplica mínimo. Este retraso suele ser inferior a 100 milisegundos después de que la instancia principal haya 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 la réplica.
nota
Aurora Replica se reinicia cuando pierde la comunicación con la instancia de base de datos del escritor durante más de 60 segundos en las siguientes versiones de Aurora PostgreSQL:
Versión 14.6 y anteriores
Versión 13.9 y anteriores
Versión 12.13 y anteriores
Todas las versiones de Aurora PostgreSQL 11
Las réplicas de Aurora 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. Como el volumen del clúster se comparte entre todas las instancias de base de datos del clúster de base de datos, se requiere un trabajo adicional mínimo para replicar una copia de los datos para cada réplica de Aurora.
Para incrementar la disponibilidad, puede usar las réplicas de Aurora como objetivos de conmutación por error. Es decir, que si la instancia principal da error, una réplica de Aurora se convierte en 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.
Promover una réplica de Aurora por conmutación por error es mucho más rápido que volver a crear la instancia principal. Si el clúster de la base de datos de Aurora no incluye ninguna réplica de Aurora, el clúster de la base de datos no estará disponible mientras la instancia de base de datos se recupera del error.
Cuando se produce la conmutación por error, algunas de las réplicas de Aurora podrían reiniciarse, según la versión del motor de base de datos. Por ejemplo, en Aurora MySQL versión 2.10 y posteriores, 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. Para obtener más información sobre el comportamiento de reinicio de las diferentes versiones del motor de base de datos de Aurora, consulte Reinicio de un clúster de base de datos de Amazon Aurora o de una instancia de base de datos de Amazon Aurora. Para obtener información sobre lo que ocurre con las cachés de páginas al reiniciar o realizar una conmutación por error, consulte Caché de páginas que puede sobrevivir.
Para escenarios de alta disponibilidad, le recomendamos que cree una o más réplicas de Aurora. Dichas réplicas deberían ser de la misma clase de instancia de base de datos que la instancia principal y de zonas de disponibilidad distintas para el clúster de base de datos Aurora. Para obtener más información sobre las réplicas de Aurora como destinos de conmutación por error, consulte Tolerancia a errores para un clúster de base de datos de Aurora.
No puede crear una réplica de Aurora cifrada para un clúster de base de datos de Aurora sin cifrar. No puede crear una réplica de Aurora sin cifrar para un clúster de base de datos de Aurora cifrado.
sugerencia
Puede utilizar Réplicas Aurora dentro de un clúster Aurora como única forma de replicación para mantener los datos altamente disponibles. También puede combinar la Aurora replicación integrada con los otros tipos de replicación. Hacerlo puede ayudar a proporcionar un nivel adicional de alta disponibilidad y distribución geográfica de sus datos.
Para obtener información detallada acerca de la forma de crear una réplica de Aurora, consulte Adición de réplicas de Aurora a un clúster de base de datos.
Replicación con Aurora MySQL
Además de las réplicas de Aurora, dispone de las siguientes opciones para replicar con Aurora MySQL:
-
Los clústeres de base de datos de Aurora MySQL en diferentes regiones de AWS.
-
Puede replicar datos en varias regiones mediante una base de datos Aurora global. Para obtener más información, consulte Alta disponibilidad en todas las regiones de AWS con bases de datos de Aurora globales.
-
Puede crear una réplica de lectura de Aurora de un clúster de base de datos MySQL de Aurora en una región de AWS diferente, mediante el uso de la replicación de registros binarios (binlog) de MySQL. Cada clúster puede tener hasta cinco réplicas de lectura creadas de esta manera, cada una en una región diferente.
-
-
Dos clústeres de base de datos de Aurora MySQL en la misma región de mediante la utilización de la reproducción del registro binario (binlog) de MySQL.
-
Una instancia de base de datos RDS for MySQL como origen de los datos y un clúster d e base de datos de Aurora MySQL, al crear una réplica de lectura de Aurora de una instancia de base de datos RDS for MySQL. Normalmente, este método se usa para la migración de Aurora MySQL y no para una replicación continua.
Para obtener más información sobre cómo replicar con Aurora MySQL, consulte Replicación con Amazon Aurora MySQL.
Replicación con Aurora PostgreSQL
Además de las réplicas de Aurora, dispone de las siguientes opciones para replicar con Aurora PostgreSQL:
Una base de datos primaria de Aurora en una región y hasta cinco clústeres de base de datos secundarios de solo lectura en diferentes regiones mediante una base de datos global de Aurora. Aurora PostgreSQL no admite réplicas de Aurora entre regiones. Sin embargo, se puede usar la base de datos global de Aurora para escalar las capacidades de lectura de su clúster de Aurora PostgreSQL DB a más de una región de AWS y cumplir con los objetivos de disponibilidad. Para obtener más información, consulte Uso de bases de datos globales de Amazon Aurora.
Dos clústeres de base de datos Aurora PostgreSQL en la misma región, mediante el uso de la característica de replicación lógica de PostgreSQL.
Una instancia de base de datos RDS for PostgreSQL como origen de los datos y un clúster de base de datos Aurora PostgreSQL, creando una réplica de lectura Aurora de una instancia de base de datos RDS for PostgreSQL. Por lo general, se usa este enfoque para la migración a Aurora PostgreSQL, más que para la replicación continua.
Para obtener más información sobre cómo replicar con Aurora PostgreSQL, consulte Replicación con Amazon Aurora PostgreSQL.
