ApsaraDB RDS:Troubleshoot failures in connecting to an ApsaraDB RDS for MySQL instance

La instancia de ECS está en una VPC y la de RDS en la red clásica

• Método 1 (recomendado): Migre la instancia de RDS a la nube privada virtual (VPC) donde reside la instancia de ECS. Consulte Change the network type of an ApsaraDB RDS instance.

  Nota

  Si ambas instancias están en VPC, deben residir en la misma VPC para comunicarse por una red interna.

• Método 2: Adquiera una nueva instancia de ECS en la red clásica. Las instancias de ECS no se pueden migrar de una VPC de vuelta a la red clásica. Una VPC es más segura que la red clásica.

• Método 3: Conéctese mediante el public endpoint de la instancia de RDS. Este método no garantiza un rendimiento, seguridad ni estabilidad óptimos.

La instancia de ECS está en la red clásica y la de RDS en una VPC

• Método 1 (recomendado): Migre la instancia de ECS a la VPC donde reside la instancia de RDS.

  Nota

  Si ambas instancias están en VPC, deben residir en la misma VPC para comunicarse por una red interna.

• Método 1: Migre la instancia de ECS a la VPC a la que pertenece la instancia de RDS. Este es el método recomendado.

  Nota

  Si la instancia de ECS y la de RDS residen en VPC, deben estar en la misma VPC para comunicarse entre sí por una red interna.

• Método 2: Migre la instancia de RDS a la red clásica. Una VPC es más segura que la red clásica.

• Método 3: Utilice ClassicLinkOverview of ClassicLink para establecer una conexión de red interna entre la instancia de ECS y la de RDS.

• Método 4: Conéctese mediante el public endpoint de la instancia de RDS. Este método no garantiza un rendimiento, seguridad ni estabilidad óptimos.

Prueba de conectividad

Ejecute los siguientes comandos desde la instancia de ECS. Reemplace <Domain name> con el endpoint interno o público de RDS y <Port number> con el puerto de la base de datos:

ping <Domain name>
telnet <Domain name> <Port number>

Si la prueba de conectividad falla, es probable que el problema esté en la resolución de DNS o en la configuración de red. Continúe con la corrección de la configuración de DNS de la NIC que se muestra a continuación.

Corrección de la configuración de DNS de la NIC

1. Abra el archivo de configuración de la NIC en modo de edición:

   Nota

   Ejecute ifconfig para averiguar el nombre del archivo de configuración de la NIC. El valor predeterminado es ifcfg-eth0.

   vi /etc/sysconfig/network-scripts/<NIC configuration file name>

2. Agregue la siguiente configuración de DNS al final del archivo. Si DNS1 y DNS2 ya existen, actualice sus valores:

   DNS1=100.100.XX.XX
   DNS2=100.100.XX.XX

3. Reinicie el servicio de red:

   sudo systemctl restart network

4. Compruebe que el cambio surtió efecto:

   cat /etc/resolv.conf

No se puede resolver el endpoint después de reiniciar o restaurar la instancia, o tras un cambio de DNS

Después de reiniciar o restaurar una instancia de RDS, o cuando cambia su configuración de DNS, el cliente podría reportar que no se resuelve el endpoint público o mostrar otros comportamientos anormales de resolución de DNS. Es posible que las pruebas de ping o telnet hacia la dirección IP sigan funcionando correctamente.

La propagación de DNS puede tardar desde varios minutos hasta decenas de minutos. Durante este periodo, una caché de DNS local obsoleta o un retraso en la propagación global de DNS impide que el cliente resuelva la dirección más reciente.

1. Espere a que termine la propagación de DNS y vuelva a intentar la conexión mediante el endpoint público.

2. Para aislar el problema de DNS, utilice temporalmente la dirección IP en un cliente como Navicat. Si la dirección IP funciona pero el endpoint público no, continúe con la solución de problemas de resolución y caché de DNS.

3. Actualice la configuración o la caché de DNS en el cliente o en el servidor. Siga los pasos de la sección "Corrección de la configuración de DNS de la NIC", vuelva a resolver el endpoint público y pruebe la conexión nuevamente.

¿Por qué las pruebas de ping y telnet funcionan correctamente, pero la aplicación no se conecta?

Una prueba de ping exitosa indica que el host responde a las solicitudes ICMP, mientras que una prueba de telnet exitosa confirma que el puerto de la base de datos es accesible. Si la aplicación aún no logra conectarse, realice las siguientes comprobaciones:

1. Descarte comportamientos anormales o problemas de configuración en herramientas gráficas como Navicat. Utilice la interfaz de línea de comandos de MySQL para una prueba de conexión de bajo nivel: mysql -h <endpoint> -P <port> -u <username> -p.

2. Si el comando se ejecuta correctamente, significa que la conexión de red y los permisos de la cuenta probada funcionan bien. Compruebe la versión del controlador de la base de datos, el formato de la cadena de conexión, el endpoint, el puerto, el nombre de la base de datos, el nombre de usuario y la contraseña en el código de la aplicación Java u otra aplicación.

3. No utilice cuentas del sistema cuyos nombres comiencen con dms para probar conexiones de negocio. Cree una cuenta con privilegios o una cuenta estándar de negocio en la consola, pruebe la conexión con ella y compruebe que tenga acceso a la base de datos de destino.

Si el comando también falla, continúe con la solución de problemas de red, lista blanca, puerto y cuenta descrita en este documento.