ApsaraDB RDS:Database proxy FAQ

Contenido

• What is a database proxy?

• What is the difference between general-purpose and dedicated proxies?

• Does a database proxy use the QPS or TPS of the primary instance?

• Is a database proxy endpoint the same as a regular instance endpoint?

• After I enable the database proxy, are the original endpoints of the primary and read-only instances reclaimed?

• Is the internal network type of a database proxy the same as that of the primary instance?

• What architecture do database proxies use? Is failover supported?

• What is the relationship between the proxy specification and proxy node specification?

• What is the relationship between the number of proxy nodes and the proxy specification?

• What are the limits on proxy node specifications?

• Is there a relationship between the number of proxy nodes and the number of proxy endpoints?

• Does the performance of a database proxy improve if I add more proxy endpoints?

• Does a database proxy limit the number of user connections?

• What do I do if a timeout error occurs when I connect by using a database proxy endpoint?

• Can I modify a database proxy endpoint (read/write splitting endpoint)?

• If the primary instance has a low write frequency, can read requests be sent to it?

• Does read/write splitting support hints?

• Why does the load on each node not match the configured read weights?

• If the database proxy is disabled, can I still configure read weights for read-only instances?

• If a read-only instance becomes unavailable, new connections are routed to healthy read-only instances. Will existing connections to the failed instance automatically fail over?

• After I enable the database proxy, how do I verify read/write splitting?

• After I purchase a read-only instance for read/write splitting, is historical data from the primary instance automatically synchronized to the read-only instance?

• What is the difference between the connection pool in a database proxy and the one in an application? How should they be used together?

• Why do my queries return garbled characters?

• Are DDL operations automatically synchronized from the primary instance to secondary instances?

• If I migrate proxy nodes across availability zones, does the nearest access feature become unavailable?

• Can I change the availability zone when I modify the proxy configuration?

• How do I resolve the "All connection endpoints' vSwitchId must be in the destination availability zone" error when changing from a dual-zone deployment to a single-zone deployment?

¿Qué es un proxy de base de datos?

Un proxy de base de datos es un servicio de proxy de red que se sitúa entre sus servidores de base de datos y de aplicaciones. Reenvía todas las solicitudes de su aplicación a la base de datos y proporciona funciones avanzadas como división automática de lectura/escritura, división de transacciones, pools de conexiones y persistencia de conexiones. Está diseñado para ofrecer alta disponibilidad, alto rendimiento y facilidad de uso y mantenimiento.

¿Cuál es la diferencia entre los proxies de propósito general y los dedicados?

• Propósito general: Shares physical CPU resources, which makes it a cost-effective option. The maximum proxy specification is 16 CPU cores (8 proxy nodes), and this type is free of charge.

• Dedicado: Uses exclusive physical CPU resources, providing greater performance stability. The maximum proxy specification is 64 CPU cores (32 proxy nodes), and this type is billed on a pay-as-you-go basis.

For more information, see General-purpose and dedicated proxies, Relationship between the number of proxy nodes and proxy specification, and Database proxy fees.

¿Un proxy de base de datos utiliza las QPS o TPS de la instancia principal?

No.

¿El endpoint de un proxy de base de datos es igual al endpoint de una instancia normal?

No.

• El endpoint de una instancia normal enruta todas las solicitudes a esa instancia específica.

• El endpoint de un proxy de base de datos identifica automáticamente las solicitudes de lectura y escritura según sus sentencias SQL. Reenvía las solicitudes de escritura a la instancia principal y las de lectura a las instancias de solo lectura. Este proceso permite la división de lectura/escritura y reduce la carga en la instancia principal.

Después de habilitar el proxy de base de datos, ¿se recuperan los endpoints originales de las instancias principales y de solo lectura?

No.

¿El tipo de red interna de un proxy de base de datos es el mismo que el de la instancia principal?

La red interna de un proxy de base de datos siempre es una VPC.

¿Qué arquitectura utilizan los proxies de base de datos? ¿Se admite la conmutación por error?

El proxy de base de datos utiliza una arquitectura de nodo principal dual de alta disponibilidad. El tráfico se distribuye entre los dos nodos en una proporción de 1:1. Si un nodo falla, el otro asume todo el tráfico. Se activa automáticamente una tarea para reconstruir el nodo fallido y mantener la alta disponibilidad.

Para obtener más información sobre la arquitectura de despliegue, consulte Proxy deployment architecture.

Relación entre el proxy y las especificaciones de los nodos

proxy specification = Sum of all proxy node specifications

Por ejemplo, suponga que se despliega un proxy dedicado en una implementación de zona dual (Zona de disponibilidad A y Zona de disponibilidad B). En la Zona de disponibilidad A hay dos nodos de proxy, cada uno con una especificación de 1 núcleo de CPU. En la Zona de disponibilidad B hay dos nodos de proxy, cada uno con una especificación de 2 núcleos de CPU. La especificación total del proxy se calcula de la siguiente manera: (1 núcleo de CPU × 2) + (2 núcleos de CPU × 2) = 2 núcleos de CPU + 4 núcleos de CPU = 6 núcleos de CPU.

Relación entre los nodos de proxy y la especificación

number of proxy nodes = proxy specification / Specification per Unit, where the specification per unit is fixed at 2 CPU cores.

Por ejemplo, si la especificación del proxy es de 6 núcleos de CPU, el número de nodos de proxy es 3 (6 / 2).

Límites de especificación de los nodos de proxy

• La especificación de un solo nodo de proxy varía de 1 a 8 núcleos de CPU para el tipo de propósito general y de 1 a 16 núcleos de CPU para el tipo dedicado.

• Todos los nodos de proxy dentro de la misma zona de disponibilidad deben tener la misma especificación.

• En un despliegue de zona dual con dos nodos, ambos deben tener la misma especificación.

• Los nodos de proxy en diferentes zonas de disponibilidad pueden tener distintas especificaciones. Para los proxies de propósito general, se recomienda que los nodos en diferentes zonas utilicen la misma especificación.

Relación entre los nodos de proxy y los endpoints

No.

Después de habilitar el proxy de base de datos para una instancia de RDS, puede crear de uno a siete endpoints de proxy. Para cada endpoint de proxy, puede crear un endpoint interno y uno público. Para obtener más información, consulte Add a proxy endpoint.

¿Agregar endpoints de proxy mejora el rendimiento?

No.

El rendimiento de un proxy de base de datos depende del número de instancias de solo lectura y del número de nodos de proxy (especificación del proxy) en las instancias RDS High-availability Edition. Para las instancias RDS Cluster Edition, el rendimiento depende del número de instancias secundarias y del número de nodos de proxy (especificación del proxy).

• Aumentar el número de instancias de solo lectura (para High-availability Edition) o de instancias secundarias (para Cluster Edition) mejora la capacidad de procesamiento de lecturas del proxy de base de datos.

• Aumentar el número de nodos de proxy (especificación del proxy) mejora el rendimiento general del proxy de base de datos.

Límites de conexión del proxy de base de datos

El proxy de base de datos no limita el número máximo de conexiones. Las especificaciones de los nodos de cómputo de su base de datos determinan este límite.

Manejo de errores de tiempo de espera de conexión

Aumente el valor del parámetro wait_timeout e intente conectarse de nuevo. Para obtener más información sobre cómo modificar los parámetros de la instancia, consulte Set the parameters of an ApsaraDB RDS for MySQL instance.

Modificación de un endpoint de proxy

Sí.

Puede modificar un endpoint de proxy de base de datos (endpoint de división de lectura/escritura). Para obtener más información, consulte Modify a proxy endpoint.

Envío de solicitudes de lectura a la instancia principal

Sí.

Puede asignar un peso de lectura a la instancia principal cuando configure la distribución de pesos de lectura. Para obtener más información sobre cómo asignar un peso de lectura a la instancia principal, consulte Enable the database proxy feature for an ApsaraDB RDS for MySQL instance.

Compatibilidad con hints para la división de lectura/escritura

Sí. Puede usar un hint para forzar la ejecución de una solicitud en la instancia principal. Para obtener más información sobre los formatos de hint compatibles con la división de lectura/escritura de RDS, consulte la sección "Uso de un hint para especificar si se envía una sentencia SQL a una instancia principal o de solo lectura" de Default read weight allocation rules.

Los pesos de lectura modificados no surten efecto

Después de modificar los pesos de lectura, solo las nuevas conexiones se distribuyen según los nuevos pesos. Las conexiones existentes no se ven afectadas.

Desequilibrio de carga con los pesos de lectura

Si la distribución de carga entre los nodos no coincide con los pesos de lectura configurados, compruebe lo siguiente:

• Compruebe si sus solicitudes forman parte de una transacción. Todas las solicitudes dentro de una transacción se enrutan a la instancia principal. Puede habilitar transaction splitting para reducir la carga en la instancia principal.

• Asegúrese de conectarse exclusivamente a través de un endpoint de proxy de base de datos. Las conexiones realizadas mediante los endpoints de la instancia principal o de solo lectura omiten la distribución de pesos de lectura.

Configuración de pesos de lectura sin un proxy de base de datos

Si el proxy de base de datos está deshabilitado, no puede configurar pesos de lectura para las instancias de solo lectura. Sin embargo, aún puede lograr la división de lectura/escritura y el equilibrio de carga mediante el uso de endpoints separados para las instancias principales y de solo lectura en el código de su aplicación.

Conmutación por error de conexión para instancias de solo lectura no disponibles

No, las conexiones existentes a la instancia fallida no realizan una conmutación por error automática. Solo se establece una nueva conexión a una instancia saludable después de que la conexión fallida agota su tiempo de espera.

¿Cómo se comprueba la división de lectura/escritura después de habilitar el servicio de proxy de base de datos?

Consulte Verify read/write splitting.

Sincronización automática de datos a nuevas instancias de solo lectura

Sí. Cuando habilita el proxy de base de datos para la división de lectura/escritura, los datos históricos se sincronizan automáticamente desde la instancia principal a la de solo lectura. No se requiere intervención manual.

Pool de conexiones del proxy frente al pool de conexiones de la aplicación

El proxy de base de datos proporciona un pool de conexiones a nivel de proxy que es independiente del pool a nivel de cliente de su aplicación. Si su aplicación ya utiliza un pool de conexiones, no es necesario usar el del proxy. Para obtener más información sobre el pool de conexiones del proxy de base de datos, consulte Configure a connection pool.

Manejo de caracteres ilegibles en los resultados de consulta

Ejecute el siguiente comando para comprobar si los conjuntos de caracteres utilizados por la instancia principal y las instancias de solo lectura son consistentes:

select 
@@global.character_set_results, 
@@global.character_set_client, 
@@global.character_set_connection, 
@@global.character_set_server;

Si los conjuntos de caracteres no son consistentes, pueden aparecer caracteres ilegibles. Puede modificar el conjunto de caracteres de la instancia principal o de una instancia de solo lectura para garantizar que coincidan. Para obtener más información sobre cómo modificar los conjuntos de caracteres de las instancias, consulte Character sets of ApsaraDB RDS for MySQL instances.

Sincronización automática de DDL

Sí. Todas las operaciones DDL, como la creación o eliminación de bases de datos y tablas, la alteración de estructuras de tablas y la modificación de permisos, se sincronizan automáticamente desde la instancia principal a sus instancias secundarias.

Consulta del ID de VPC y vSwitch

En la página Database proxy de su instancia, vaya a la sección Connection information. Para consultar la información, pase el puntero sobre el icono a la derecha de Port, como se muestra en la siguiente figura.

Impacto de la migración entre zonas en la instancia principal

La migración de nodos de proxy entre zonas de disponibilidad afecta únicamente a las cargas de trabajo que utilizan un endpoint de proxy de base de datos. Las conexiones realizadas a través del endpoint de la instancia principal, un endpoint de instancia de solo lectura, un endpoint de lectura/escritura de clúster, un endpoint de solo lectura de clúster o un endpoint a nivel de nodo no se ven afectadas. Para minimizar el impacto, cambie sus cargas de trabajo a un endpoint no afectado y realice la migración fuera del horario pico.

Impacto de la migración de proxy entre zonas

Cuando migra un proxy entre zonas de disponibilidad, las conexiones que utilizan el proxy de base de datos pueden experimentar una desconexión transitoria de aproximadamente 30 segundos. La duración real del impacto depende de su carga de trabajo. Para minimizar el impacto, cambie sus cargas de trabajo a un endpoint no afectado y realice la migración fuera del horario pico. Para obtener más información, consulte Migrate database proxies across zones.

Impacto de la migración entre zonas en el acceso más cercano

Podría dejar de estar disponible.

La migración entre zonas puede invalidar la configuración de acceso más cercano. Después de la migración, la nueva zona es accesible de forma predeterminada; la zona original deja de ser accesible. Si la zona del endpoint de proxy difiere de la nueva zona predeterminada, el acceso más cercano a esa zona fallará.

Cambio de la zona de disponibilidad durante la configuración

No.

Si necesita migrar a una zona de disponibilidad diferente, consulte Migrate database proxies across zones.

Resolución del error de vSwitchId en despliegue de zona única

Al cambiar de un despliegue de zona dual (por ejemplo, en Availability Zone 1 y Availability Zone 2) a un despliegue de zona única (por ejemplo, en Availability Zone 1), primero debe eliminar el endpoint de proxy de base de datos en Availability Zone 2. Para obtener más información, consulte Modify a proxy endpoint.

¿Las direcciones IP resueltas del proxy son fijas?

No. Always use the database proxy endpoint (for example, d3pswqe3jk9xwc5d****-rw4rm.rwlb.rds.aliyuncs.com ) to connect, not the resolved IP address.

Verificación de conexiones a través de un endpoint de proxy

Puede identificar el método de conexión mediante el ID de sesión. Un ID de sesión menor que 16777215 indica una conexión a través de un instance endpoint. Un ID mayor indica una conexión a través de un endpoint de proxy de base de datos.

Los ID de sesión son visibles en Session management.

Datos no visibles inmediatamente después de escrituras

Common cause: This occurs when the proxy routes your read request to a read-only instance that is lagging behind the primary instance due to replication delay.

Solutions:

• Use a hint: For queries that require strong read consistency, use the /*FORCE_MASTER*/ hint to route the request to the primary instance.

• Disable transaction splitting and encapsulate queries that require strong read consistency within a transaction.

• Set the consistency level a consistencia global.