En esta página se describe cómo usar y promocionar réplicas de lectura entre regiones (réplicas creadas en una región distinta a la de la principal) para la migración regional o la recuperación tras fallos.
Información general
Hay dos situaciones habituales para promocionar réplicas entre regiones:
- Migración regional: realiza una migración planificada de una base de datos a otra región.
- Recuperación tras desastres: conmutar por error una base de datos a otra región en caso de que la región principal deje de estar disponible.
En ambos casos, se configura la replicación interregional y, a continuación, se promueve la réplica. La principal diferencia entre ellas es si la promoción de la réplica está planificada (en el caso de la migración regional) o no (se necesita una conmutación por error a la región de la réplica para continuar con las operaciones porque la principal no está disponible).
Migración regional
Puedes usar una réplica entre regiones para migrar tu base de datos a otra región con un tiempo de inactividad mínimo. La idea general es crear una réplica en otra región, esperar a que se ponga al día, promoverla y, a continuación, dirigir a los clientes a la instancia recién promovida.
Los pasos que hay que seguir para promocionar una réplica son los mismos que para promocionar una réplica de la misma región. Sigue esas instrucciones para asegurarte de que la instancia recién promocionada tenga todas las transacciones que se hayan confirmado en la instancia principal original. Una vez que hayas promovido la réplica y verificado que la instancia recién promovida funciona, actualiza todos los clientes de la base de datos para que se conecten a la nueva instancia.
Recuperación tras fallos
Las réplicas entre regiones se pueden usar como parte de un procedimiento de recuperación tras fallos. Puedes promover una réplica interregional para conmutar por error a otra región si la región de la instancia principal no está disponible durante un periodo prolongado.
Para obtener más información sobre la recuperación tras fallos, consulta Información sobre la recuperación tras fallos en Cloud SQL.
Recuperación tras fallos avanzada
Si usas la edición Cloud SQL Enterprise Plus, puedes designar una réplica de lectura interregional como réplica de recuperación tras fallos para la recuperación tras fallos avanzada. Con la recuperación ante desastres avanzada, se realiza una conmutación por error de la réplica para sustituir la instancia principal por la réplica de recuperación ante desastres designada. La antigua instancia principal se convierte en una réplica de la réplica de recuperación ante desastres ascendida. Solo puedes realizar una conmutación por error de réplica a la réplica de recuperación ante desastres designada. Puedes seguir promocionando otras réplicas de lectura sin conmutación por error.
Para volver a la implementación original después de la conmutación por error de la réplica sin perder datos, puedes realizar una conmutación. Como la antigua instancia principal es una réplica de la nueva, puedes volver a cambiar los roles para restaurar la antigua instancia principal.
Para obtener más información, consulta Recuperación tras desastres avanzada.
Verificar los criterios de conmutación por error
Como la replicación es asíncrona, cuando se produce una interrupción en una región y se intenta una conmutación por error, es posible que se pierdan algunas transacciones recientes que se hayan confirmado en la principal (no se habrán replicado en la réplica). Cuando una instancia principal deja de estar disponible, los siguientes pasos muestran (1) cómo determinar la cantidad de datos, si los hay, que se pueden haber perdido en la conmutación por error entre regiones y (2) cómo asegurarse de que la réplica promocionada refleje tantas escrituras recientes como sea posible.
En primer lugar, comprueba el valor de Replication Lag de la instancia de réplica en el panel de control de monitorización, que indica el tiempo en segundos que lleva de retraso la réplica con respecto a su principal. El valor de esta métrica en el momento justo antes de que la réplica principal dejara de estar disponible indica el periodo durante el cual se pueden haber perdido las transacciones confirmadas en la réplica principal. Por ejemplo, si Replication Lag se ha mostrado durante 5 segundos, es posible que la réplica no tenga las escrituras en el principal de los 5 segundos anteriores a que el principal dejara de estar disponible.
(La cantidad real de datos perdidos puede ser inferior a esta, ya que Replication
Lag también incluye transacciones que la réplica ha recibido correctamente, pero que aún no se han aplicado).
A continuación, conéctate a la instancia réplica con un cliente MySQL siguiendo las instrucciones de la página Estado de la replicación (consulta la pestaña Cliente mysql). Consulta las instrucciones relativas a las métricas Master_Log_File, Read_Master_Log_Pos, Relay_Master_Log_File y Exec_Master_Log_Pos. Comprueba que la réplica haya procesado todas las transacciones que haya recibido de la principal. De esta forma, cuando se promueva, la réplica reflejará todas las transacciones que se hayan recibido antes de que la principal dejara de estar disponible.
Promocionar una réplica de lectura
Una vez que hayas determinado que se cumplen los criterios de conmutación por error, puedes convertir una de las réplicas en una instancia independiente de escritura. Veamos la siguiente situación:
- La región A (us-central1) tiene una instancia principal de alta disponibilidad (db-a-0).
- La región B (us-west1) tiene una réplica entre regiones de alta disponibilidad (db-b-1) de db-a-0.
- La región C (us-east1) tiene una réplica interregional (db-c-1) de db-a-0
Puedes elegir promover db-b-1 en la región B para que se convierta en una instancia independiente de escritura.
Consulta las instrucciones detalladas para promocionar una réplica.
Asegúrate de que el tipo de máquina sea adecuado
Comprueba que el tipo de máquina de la instancia recién ascendida sea adecuado para su carga de trabajo monitorizando métricas de la instancia, como el uso de CPU y memoria. Si la instancia recién ascendida es más pequeña que la instancia principal anterior, te recomendamos que cambies el tamaño de la instancia ascendida para que coincida con la instancia principal anterior y pueda gestionar la misma carga.
Habilitar la alta disponibilidad en la instancia promocionada
Para una configuración de recuperación ante desastres, te recomendamos que configures la réplica que quieras promover como réplica de alta disponibilidad. También puedes configurar la instancia recién ascendida como de alta disponibilidad. Si decides no configurar la réplica de lectura con alta disponibilidad, también puedes configurar la instancia con alta disponibilidad cuando la promuevas.
Cuando se promocionan, las réplicas de lectura se configuran automáticamente con copias de seguridad. La configuración de una réplica de lectura para alta disponibilidad se realiza de la misma forma que en una instancia principal. Para obtener más información, consulta Configurar la instancia para alta disponibilidad.
Recrear réplicas adicionales
Si asciendes una réplica a instancia principal, tendrás que volver a crear las réplicas de la instancia principal anterior. Por ejemplo, considera la configuración a la que se ha hecho referencia anteriormente y que se repite a continuación:
- La región A (us-central1) tiene una instancia principal de alta disponibilidad (db-a-0).
- La región B (us-west1) tiene una réplica interregional (db-b-1) de db-a-0
- La región C (us-east1) tiene una réplica interregional (db-c-1) de db-a-0
Si la instancia principal (db-a-0) deja de estar disponible, puedes convertir la réplica de la región B en la principal. Para volver a tener réplicas adicionales en las regiones A y C, elimina las instancias antiguas (la antigua instancia principal en A y la réplica en C) y crea réplicas de lectura a partir de la nueva instancia principal en B.
La configuración resultante sería la siguiente:
- La región A (us-central1) ahora tiene una réplica interregional (db-a-1)
- La región B (us-west1) ahora tiene la instancia principal (db-b-1)
- La región C (us-east1) ahora tiene una nueva réplica interregional (db-c-2)