La migración entre zonas traslada una instancia de ApsaraDB RDS for MySQL a otra zona dentro de la misma región, sin pérdida de datos. Este proceso tarda hasta una hora en instancias con discos en la nube y varias horas en instancias con SSD local premium, según el volumen de datos.
Limitaciones
Antes de comenzar, compruebe que su instancia cumple todas las condiciones siguientes:
La instancia ejecuta High-availability Edition o Basic Edition. Las instancias serverless no son compatibles.
La instancia no utiliza un tipo de instancia descontinuado. Consulte Instance types for standard primary ApsaraDB RDS for MySQL instances (original x86 architecture). Para cambiar el tipo de instancia, consulte Change instance specifications.
La instancia se encuentra en estado Running. Si existen instancias de solo lectura asociadas, estas también deben estar en estado Running; de lo contrario, aparecerá el error
OperationDenied.MasterDBlnstancestateal iniciar la migración.Si la instancia usa discos en la nube, la versión menor del motor debe ser 20201031 o posterior. Para actualizarla, consulte Update the minor engine version.
La región contiene varias zonas. Consulte Regions and zones.
-
El proxy de base de datos compartido está deshabilitado. Para verificarlo: en la página Database Proxy, busque la pestaña Read/Write Splitting (Shared). Si dicha pestaña aparece, el proxy compartido está habilitado.
Los proxies de base de datos compartidos dejaron de recibir mantenimiento a partir del 1 de abril de 2021. Si aún utiliza uno, actualícelo a un proxy de base de datos dedicado. Consulte Actualizar el proxy de base de datos de un proxy compartido a un proxy dedicado . Los proxies de base de datos dedicados y de propósito general no se ven afectados por la migración entre zonas.
Si la instancia utiliza SSD empresariales premium (ESSD) con Buffer Pool Extension (BPE) habilitado, la zona de destino debe admitir BPE. Consulte Applicable scope. Para migrar a una zona sin compatibilidad con BPE, primero deshabilite esta función.
Facturación
La migración entre zonas es gratuita, incluidas las migraciones de una sola zona a múltiples zonas.
Impactos de la migración
Conmutación de instancia
Durante la migración puede producirse una conmutación, lo que deja temporalmente no disponibles el endpoint de la instancia principal y el endpoint del proxy de base de datos. Configure su aplicación para que se reconecte automáticamente. Si no cuenta con reconexión automática, vuelva a conectarse manualmente.
Se produce una conmutación cuando se cumple alguna de las siguientes condiciones:
|
Condition |
Effect |
|
La zona de destino de la instancia principal difiere de su zona actual |
La instancia principal se reemplaza durante la migración |
|
La zona de destino de la instancia principal difiere de su zona de red actual |
La instancia principal se reemplaza durante la migración |
Para obtener detalles sobre el comportamiento de la conmutación, consulte Impactos de una conmutación de instancia.
Cambio de VIP
Si ocurre una conmutación, la dirección IP virtual (VIP) de la instancia cambia, aunque el endpoint permanece igual. Conecte su aplicación mediante el endpoint, no mediante la dirección IP.
Vinculación con PolarDB-X 1.0: Un cambio de VIP puede interrumpir la conectividad entre la instancia de RDS y la instancia de PolarDB-X 1.0 vinculada. Resuelva cualquier problema de conectividad de inmediato. Consulte Fix database shard connections.
Caché de DNS: Elimine los registros del Sistema de Nombres de Dominio (DNS) almacenados en caché del cliente de base de datos inmediatamente después de la migración. En clientes JVM, establezca el tiempo de vida (TTL) en 60 segundos o menos para que el cliente resuelva nuevamente el endpoint tras un cambio de VIP. Para más información sobre cómo configurar el TTL en la configuración de JVM, consulte Class InetAddress.
Otros impactos
|
Impact |
Details |
|
Tareas de DTS |
Reinicie las tareas de Data Transmission Service (DTS) en curso una vez finalizada la migración. Consulte What is DTS? |
|
Recreación de tablas |
Las tablas se recrean durante la migración. El campo |
|
Disponibilidad de recursos |
Si la zona de destino no cuenta con inventario suficiente de recursos, la migración podría fallar. |
|
Cambio exclusivo de vSwitch |
No es posible cambiar únicamente el vSwitch durante una migración entre zonas. Para modificar el vSwitch, consulte Change the VPC and vSwitch. |
Escenarios de migración
Solo puede migrar dentro de la misma región. Para trasladarse a otra región, create an RDS instance en la región de destino, migre los datos mediante DTS, verifique sus cargas de trabajo y luego release the original instance.
Se admiten los siguientes escenarios de migración. El despliegue en múltiples zonas protege contra fallos del centro de datos; el despliegue en una sola zona solo protege contra fallos de servidor y rack.
|
Scenario |
Result |
When to use |
|
De una zona a una zona |
Las instancias principal y secundaria residen en la misma zona de destino. Ejemplo: ambas pasan de Singapore Zone C a Singapore Zone A. |
Elija esta opción cuando necesite consolidar instancias en una sola zona. Tenga en cuenta que el despliegue en una sola zona no ofrece recuperación ante desastres (DR) entre zonas. |
|
De una zona a múltiples zonas |
Las instancias principal y secundaria residen en distintas zonas de destino. Ejemplo: la principal pasa de Singapore Zone C a Singapore Zone B; la secundaria pasa a Singapore Zone A. |
Elija esta opción si desea DR entre zonas. El despliegue en múltiples zonas protege contra fallos del centro de datos. |
|
De múltiples zonas a una zona |
Las instancias principal y secundaria se trasladan a la misma zona de destino. Ejemplo: la principal en Singapore Zone B y la secundaria en Singapore Zone A pasan ambas a Singapore Zone C. |
Elija esta opción para simplificar su topología. Tenga en cuenta que se pierde la DR entre zonas. |
|
De múltiples zonas a múltiples zonas |
Las instancias principal y secundaria se trasladan a distintas zonas de destino. Ejemplo: la principal pasa de Singapore Zone B a Singapore Zone A; la secundaria pasa de Singapore Zone C a Singapore Zone B. |
Elija esta opción para cambiar la ubicación de las zonas manteniendo la DR entre zonas. |
Migrar una instancia entre zonas
Asegúrese de que existan una nube privada virtual (VPC) y como mínimo un vSwitch en la zona de destino antes de comenzar. De no ser así, create a vSwitch primero en la zona de destino.
Inicie sesión en la consola de ApsaraDB RDS. En la barra de navegación superior, seleccione la región de la instancia. Localice la instancia y haga clic en su ID.
-
En la página Basic Information, haga clic en Migrate Data Across Zones en la esquina superior derecha.
Si Migrate Data Across Zones no se muestra, compruebe si la instancia cumple todas las limitaciones mencionadas anteriormente.
-
En el cuadro de diálogo Migrate Instance Across Zones, establezca el parámetro Destination Zone y seleccione un vSwitch. Luego configure el parámetro Switching Time: Haga clic en Yes.
Switch Immediately — la conmutación se realiza tan pronto como finaliza la migración.
Switch Within Maintenance Window — la conmutación se pospone hasta la siguiente ventana de mantenimiento.
ImportanteTras la conmutación, si el vSwitch cambió, la instancia se reconecta mediante nuevas conexiones. Asegúrese de que su aplicación se reconecte automáticamente. Si los registros DNS en caché no se actualizan de inmediato, podría ocurrir una segunda conmutación aproximadamente 10 minutos después, cuando el tráfico se redirija a la zona principal de destino. Configure su aplicación para que se reconecte automáticamente. Para más información, consulte Impactos de una conmutación de instancia.
En el cuadro de diálogo de confirmación, revise la información de las zonas antes y después de la migración, y luego haga clic en OK.
Preguntas frecuentes
Si se escriben datos en la instancia durante la migración, ¿se ven afectados los datos originales tras la conmutación? ¿Se conservan los datos recién escritos?
Los datos originales no se ven afectados y los datos recién escritos se conservan. Durante la migración se produce una conmutación de instancia; configure su aplicación para que se reconecte automáticamente. Consulte Impactos de una conmutación de instancia.
¿Qué factores influyen en el tiempo de migración?
En instancias con SSD local premium, el tiempo de migración depende del volumen de datos; los conjuntos grandes pueden tardar varias horas. En instancias con discos en la nube, la migración tarda hasta una hora.
Referencia de API
|
Operation |
Description |
|
Migra una instancia entre zonas |
Pasos siguientes
Para la migración entre zonas de otros motores de base de datos en la misma región, consulte: