En esta página, se describe cómo usar y promover réplicas de lectura entre regiones (réplicas creadas en una región diferente a la de la principal) para la migración regional o la recuperación ante desastres.
Descripción general
Hay dos situaciones comunes en las que se ascienden réplicas entre regiones:
- Migración regional: Realiza una migración planificada de una base de datos a una región diferente.
- Recuperación ante desastres: Conmuta por error una base de datos a otra región en caso de que la región principal deje de estar disponible.
Ambos casos de uso incluyen la configuración de la replicación entre regiones y, luego, el ascenso de la réplica. La principal diferencia entre ellos es si el ascenso de la réplica está planificado (en el caso de la migración regional) o no planificado (se requiere una conmutación por error a la región de la réplica para continuar con las operaciones porque la principal dejó de estar 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 la replicación se actualice, ascenderla y, luego, dirigir a los clientes a la instancia recién ascendida.
Los pasos involucrados en el ascenso son los mismos que se usan a fin de ascender una réplica dentro de la región. Sigue estas instrucciones para asegurarte de que la instancia recién ascendida tenga todas las transacciones confirmadas en la instancia principal original. Una vez que hayas ascendido la réplica y verificado que la instancia recién ascendida funciona, actualiza todos los clientes de la base de datos para que se conecten con la instancia nueva.
Recuperación ante desastres (DR)
Las réplicas entre regiones se pueden usar como parte de un procedimiento de recuperación ante desastres. Puedes ascender una réplica entre regiones para conmutar por error a otra región si la región de la instancia principal deja de estar disponible por un período prolongado.
Para obtener más información sobre la recuperación ante desastres, consulta Información sobre la recuperación ante desastres en Cloud SQL.
Recuperación ante desastres (DR) avanzada
Si usas la edición Cloud SQL Enterprise Plus, puedes designar una réplica de lectura entre regiones como una réplica de recuperación ante desastres (réplica de DR) para la recuperación ante desastres (DR) avanzada. Con la DR avanzada, realizas una conmutación por error de réplica para reemplazar la instancia principal por la réplica de DR designada. Con el tiempo, la instancia principal anterior se convierte en una réplica de la réplica de DR que se asciende. Solo puedes realizar una conmutación por error de réplica a la réplica de DR designada. Aún puedes ascender otras réplicas de lectura sin conmutación por error.
Para volver tu implementación al estado original después de la conmutación por error de la réplica sin pérdida de datos, puedes realizar un cambio. Dado que la instancia principal anterior es una réplica de la instancia principal nueva, puedes volver a cambiar los roles para restablecer la instancia principal anterior.
Para obtener más información, consulta Recuperación avanzada ante desastres (DR). La DR avanzada se encuentra en Vista previa.
Verifica los criterios de conmutación por error
Debido a que la replicación es asíncrona, cuando se produce una interrupción regional y se intenta realizar una conmutación por error, es posible que se pierdan algunas transacciones recientes que se confirmaron en la instancia principal (no se replican en la réplica). Cuando una instancia principal deja de estar disponible, en los pasos siguientes se muestran (1) cómo determinar la cantidad de datos, si los hubiere, que podrían haberse perdido en la conmutación por error entre regiones y (2) cómo garantizar que la réplica promocionada refleje la mayor cantidad posible de escrituras recientes.
Primero, comprueba el valor Replication Lag para la instancia de réplica en el panel de supervisión, que indica qué tan lejos, en segundos, la réplica se encuentra detrás de la instancia principal. El valor de esta métrica al momento justo antes de que la instancia principal deje de estar disponible indica el período durante el que podrían perderse las transacciones confirmadas en la instancia principal. Por ejemplo, si Replication Lag muestra 5 segundos, es posible que la réplica no tenga las escrituras de la instancia principal de los 5 segundos antes de que la instancia principal dejara de estar disponible.
(La cantidad real de datos perdidos puede ser menor porque Replication
Lag también incluye transacciones que la réplica recibió con éxito, pero que aún no se aplican).
Luego, conéctate a la instancia de réplica con un cliente MySQL mediante las instrucciones que se muestran en la página estado de replicación (consulta la pestaña Cliente de MySQL). Consulta las instrucciones relacionadas con las métricas Master_Log_File, Read_Master_Log_Pos, Relay_Master_Log_File y Exec_Master_Log_Pos. Verifica que la réplica haya procesado todas las transacciones que recibió de la instancia principal. Esto garantiza que, cuando se promueva, la réplica refleje todas las transacciones que se recibieron antes de que la instancia principal dejara de estar disponible.
Asciende una réplica de lectura
Una vez que determines que se cumplen los criterios de conmutación por error, puedes promover una de las réplicas a una instancia independiente que admita operaciones de escritura. Considera la siguiente situación:
- La región A (us-central1) tiene una instancia principal con alta disponibilidad (db-a-0).
- La región B (us-west1) tiene una réplica entre regiones con alta disponibilidad (db-b-1) de db-a-0.
- La región C (us-east1) tiene una réplica entre regiones (db-c-1) de db-a-0.
Puedes elegir ascender db-b-1 en la región B para que se convierta en una instancia independiente que admita escritura.
Consulta Asciende una réplica para obtener instrucciones detalladas.
Asegúrate de que el tipo de máquina sea adecuado
Asegúrate de que el tipo de máquina de la instancia recién ascendida sea adecuado para su carga de trabajo mediante la supervisión de 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 su instancia principal anterior, de modo que pueda manejar la misma cantidad de carga.
Habilita la alta disponibilidad en la instancia que se ascendió
Para una configuración de recuperación ante desastres, recomendamos que configures la réplica que planeas ascender como una réplica de alta disponibilidad. De forma alternativa, configura la instancia recién ascendida como de alta disponibilidad. Si eliges no configurar la réplica de lectura con alta disponibilidad, también puedes configurar la instancia con alta disponibilidad cuando la asciendas (si es que lo haces).
Cuando se ascienden, las réplicas de lectura se configuran de forma automática con copias de seguridad. La configuración de una réplica de lectura para alta disponibilidad se realiza de la misma manera que para una instancia principal. Si deseas obtener más información, consulta Configura la instancia para alta disponibilidad.
Vuelve a crear réplicas adicionales
Si asciendes una réplica para que se convierta en una instancia principal, debes volver a crear cualquier otra réplica de la instancia principal anterior. Por ejemplo, considera la configuración que se mencionó antes y que se repite aquí:
- La región A (us-central1) tiene una instancia principal con alta disponibilidad (db-a-0).
- La región B (us-west1) tiene una réplica entre regiones (db-b-1) de db-a-0.
- La región C (us-east1) tiene una réplica entre regiones (db-c-1) de db-a-0.
Si la instancia principal (db-a-0) deja de estar disponible, puedes ascender la réplica en la región B para que se convierta en la instancia principal. Para volver a tener réplicas adicionales en las regiones A y C, borra las instancias anteriores (la instancia que antes era la principal en A y la réplica en C) y crea réplicas de lectura nuevas a partir de la instancia principal nueva en B.
La configuración resultante sería la siguiente:
- La región A (us-central1) ahora tiene una réplica entre regiones (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 réplica nueva entre regiones (db-c-2).