ApsaraDB RDS for MySQL admite la migración de nodos de proxy entre zonas dentro de la misma región. Si migra los nodos de proxy a la zona de la instancia principal de RDS, se reduce la latencia de escritura entre zonas y se evita la degradación del rendimiento de escritura que genera el tráfico entre zonas del proxy y la instancia principal.
Requisitos previos
Antes de empezar, compruebe lo siguiente:
-
La instancia de RDS cumple todas las condiciones siguientes:
Motor: MySQL
Edición: RDS High-availability Edition o RDS Cluster Edition
Almacenamiento: discos en la nube
Proxy de base de datos: habilitado
Estado de la instancia: Running, incluida la instancia principal, todas las instancias de solo lectura y el nodo de proxy
La instancia utiliza endpoints de virtual private cloud (VPC). La migración entre zonas no es compatible con los proxies de base de datos en redes clásicas. Para más información, consulte Consulte y gestione los endpoints y puertos de la instancia.
Si el nodo de proxy y la instancia principal de RDS están en zonas distintas y se conecta mediante un endpoint de proxy, el rendimiento de escritura disminuye. Para evitarlo, configure el mismo VPC y vSwitch para ambos.
Facturación
La migración entre zonas no tiene costo.
Posibles impactos
Revise a continuación impactos antes de iniciar la migración.
Interrupción transitoria de la conexión
La migración entre zonas provoca una interrupción transitoria de la conexión de aproximadamente 30 segundos. Para minimizar las afectaciones:
-
Conecte su aplicación con un endpoint que no se vea afectado por la migración:
RDS High-availability Edition: el endpoint de la instancia principal de RDS o el endpoint de una instancia de RDS de solo lectura
RDS Cluster Edition: el endpoint de lectura/escritura, el endpoint de solo lectura o el endpoint de conexión directa al nodo
Programe la migración fuera del horario de mayor demanda.
Compruebe que su aplicación cuente con un mecanismo de reconexión automática. De lo contrario, vuelva a conectarse manualmente cuando termine la migración.
Cambios en la dirección IP virtual
La migración entre zonas modifica las direcciones IP virtuales (VIP) vinculadas a los endpoints de su instancia. Conecte su aplicación mediante endpoints en lugar de direcciones IP para que resuelva automáticamente la nueva VIP después de la migración.
Una vez concluida la migración, borre de inmediato los registros DNS almacenados en caché en el cliente de base de datos. Cuando cambian las VIP, la propagación de DNS toma tiempo; si el cliente sigue resolviendo la VIP anterior, las conexiones fallarán hasta que expire la caché. En los clientes que se ejecutan en una máquina virtual Java (JVM), establezca el tiempo de vida (TTL) en la configuración de la JVM en 60 segundos o menos. Así, el cliente volverá a consultar el DNS rápidamente tras un cambio de VIP. Para más información, consulte Class InetAddress.
Acceso más cercano
La migración entre zonas puede invalidar la configuración de acceso más cercano. Después de la migración, la nueva zona queda accesible de forma predeterminada y la zona original deja de estarlo. Si la zona del endpoint de proxy difiere de la nueva zona predeterminada, el acceso más cercano a esa zona fallará.
A continuación se muestran algunos escenarios de ejemplo.
| Escenario | Zona original del nodo de proxy | Endpoint de proxy | Acceso más cercano original | Nueva zona del nodo de proxy | Nueva zona predeterminada | Nueva zona del endpoint de proxy | Nuevo acceso más cercano |
|---|---|---|---|---|---|---|---|
Escenario 1: Zone A+Zone B → Zone A+Zone C |
Zone A | Proxy endpoint a | Zone A | Zone A | Zone A | Zone A | Zone A |
| Zone C | Invalid | ||||||
| Zone B | Proxy endpoint b | Zone B | Zone C | Zone C | Zone C | Zone C | |
| Zone D | Invalid | ||||||
Escenario 2: Zone A+Zone B → Zone C+Zone D |
Zone A | Proxy endpoint a | Zone A | Zone C | Zone C | Zone C | Zone C |
| Zone E | Invalid | ||||||
| Zone B | Proxy endpoint b | Zone B | Zone D | Zone D | Zone D | Zone D | |
| Zone E | Invalid |
Recursos insuficientes
Si la zona de destino no cuenta con recursos suficientes, la migración podría fallar.
Migrar nodos de proxy
Inicie sesión en la consola de ApsaraDB RDS. En la página Instances, seleccione la región donde reside su instancia, localice la instancia y haga clic en su ID.
En el panel de navegación izquierdo, haga clic en Database Proxy para consultar la información básica de su proxy de base de datos.
-
Haga clic en Cross-zone Migration.
NotaSi Cross-zone Migration no aparece, compruebe que su instancia cumpla todos los requisitos previos.
-
En el cuadro de diálogo Cross-zone Migration of Database Proxy, revise la información de zona y red de la instancia principal de RDS y del proxy de base de datos. Establezca Destination Zone, Destination vSwitch y Change Time, y luego haga clic en OK.
ImportanteNo es posible cambiar el tipo ni las especificaciones del proxy de base de datos durante la migración.
Revise los impactos listados y haga clic en OK para confirmar.
Referencia de API
|
Operación |
Descripción |
|
Migra los nodos de proxy a una zona de destino al especificar vSwitchIds |
Preguntas frecuentes
¿La migración entre zonas afecta mi aplicación si no utilizo un endpoint de proxy?
No. La migración solo afecta a las aplicaciones conectadas mediante un endpoint de proxy. Si se conecta a través del endpoint de la instancia principal de RDS o del endpoint de una instancia de RDS de solo lectura (RDS High-availability Edition), o bien mediante el endpoint de lectura/escritura, el endpoint de solo lectura o el endpoint de conexión directa al nodo (RDS Cluster Edition), sus cargas de trabajo no se verán afectadas.
¿Cuánto dura la interrupción de la conexión?
La interrupción transitoria dura aproximadamente 30 segundos, aunque el tiempo real varía según su carga de trabajo. Programe la migración fuera del horario de mayor demanda y utilice un tipo de endpoint que no se vea afectado para minimizar el impacto.