Cuando se habilita la división de lectura/escritura, las solicitudes de lectura se distribuyen a instancias de solo lectura que replican datos de forma asíncrona from la instancia principal. Esto significa que una lectura inmediata tras una escritura puede devolver datos obsoletos. Los niveles de consistencia controlan cómo el proxy de base de datos equilibra la actualización de las lecturas frente al rendimiento.
ApsaraDB RDS for MySQL admite tres niveles de consistencia para los endpoints del proxy de base de datos en modo de división de lectura/escritura: consistencia eventual, consistencia de sesión y consistencia global.
El nivel de consistencia predeterminado es la consistencia eventual. Si su aplicación requiere garantías de lectura posterior a escritura, establezca explícitamente un nivel de consistencia superior.
Funcionamiento
El proxy de base de datos utiliza la replicación del registro binario (binlog) para mantener sincronizadas las instancias de solo lectura con la instancia principal. Cada transacción confirmada genera un evento de binlog que aplican las instancias de solo lectura. La posición de los datos en cada instancia de solo lectura se rastrea mediante un identificador global de transacciones (GTID), específicamente la variable Executed_Gtid_Set, que registra el conjunto de transacciones aplicadas en dicha instancia.
Para la consistencia de sesión y la consistencia global, el proxy utiliza el seguimiento de GTID para enrutar las lecturas únicamente a las instancias de solo lectura que ya han aplicado las transacciones requeridas. Si ninguna instancia de solo lectura cumple con el requisito de GTID dentro del período de tiempo de espera de consistencia de lectura (predeterminado: 10 ms), la solicitud se redirige a la instancia principal.
Niveles de consistencia
Consistencia eventual (predeterminada)
Las solicitudes de lectura se envían directamente a las instancias de solo lectura si la replicación del registro binario no presenta interrupciones. Dado que la replicación de binlog es asíncrona, es posible que una instancia de solo lectura aún no refleje las escrituras más recientes de la instancia principal.
Ejemplo: Dadas a continuación instrucciones en una sesión:
SET AUTOCOMMIT = 1;
INSERT INTO t1(id, price) VALUES (111, 96);
UPDATE t1 SET price = 100 WHERE id = 111;
SELECT price FROM t1;La instrucción SELECT puede devolver 96 en lugar de 100 si el retraso de replicación impide que la actualización sea visible en la instancia de solo lectura. La consulta no espera.
Cuándo utilizarla: Su carga de trabajo no depende de la consistencia de lectura posterior a escritura y la prioridad es maximizar la eficacia de la división de lectura/escritura.
Consistencia de sesión
El proxy de base de datos registra el GTID de la transacción confirmada más reciente en la sesión actual. Antes de enrutar una lectura, comprueba que la instancia de solo lectura destino haya aplicado las transacciones hasta ese GTID. Esto garantiza que, dentro de una sesión, las lecturas siempre reflejen las propias escrituras de dicha sesión.
Ejemplo: Con las mismas instrucciones anteriores, la instrucción SELECT espera hasta que la instancia de solo lectura aplique la instrucción UPDATE y luego devuelve 100.
Cuándo utilizarla: Existen dependencias de consistencia dentro de una sesión. Este nivel tiene un impacto moderado en el rendimiento y es adecuado para la mayoría de las cargas de trabajo de producción.
Consistencia global
El proxy de base de datos registra el GTID de la transacción confirmada más reciente en todo el clúster antes de cada lectura. Las lecturas se enrutan únicamente a instancias de solo lectura que han aplicado todas las transacciones hasta ese punto, lo que garantiza que cada sesión tenga una vista consistente de la base de datos.
Ejemplo: Cada instrucción SELECT espera a que los cambios de datos requeridos sean visibles en la instancia de solo lectura antes de ejecutarse. El tiempo de espera varía según el retraso de replicación.
Si la replicación se retrasa, se redirigen más lecturas a la instancia principal, lo que aumenta la carga y la latencia en dicha instancia.
Cuándo utilizarla: Existen dependencias de consistencia entre sesiones y su carga de trabajo tiene significativamente más lecturas que escrituras.
Elija un nivel de consistencia
Para la mayoría de las cargas de trabajo, utilice la consistencia de sesión. Proporciona consistencia de lectura posterior a escritura dentro de la sesión con una sobrecarga mínima.
|
Nivel de consistencia |
Impacto en el rendimiento de la división de lectura/escritura |
Fortaleza de la consistencia |
Alcance de la consistencia |
|
Consistencia eventual |
Ninguna |
Baja |
Consistencia del resultado final |
|
Consistencia de sesión |
Medio |
Media |
Dentro de una sesión |
|
Consistencia global |
Alto |
Alta |
En todas las sesiones |
Utilice la consistencia global solo si su aplicación requiere garantías de lectura posterior a escritura entre sesiones y tiene significativamente más lecturas que escrituras. La consistencia global añade latencia a cada operación de lectura.
Requisitos previos
Antes de empezar, asegúrese de que:
El proxy de base de datos está habilitado y ejecuta la versión 2.25.1 o posterior. Consulte Enable the database proxy feature y Release notes for the database proxy version.
El atributo del endpoint del proxy de base de datos está establecido en Read/Write (Read/Write Splitting). Consulte Configure los atributos de lectura y escritura y el peso de lectura.
La instancia RDS ejecuta MySQL 5.7 (versión menor del motor 20210630 o posterior) o MySQL 8.0 (versión menor del motor 20210930 o posterior).
Notas de uso
Para la consistencia de sesión y la consistencia global, el proxy espera a que las instancias de solo lectura alcancen la posición de GTID requerida antes de enrutar una lectura. Esto aumenta la latencia de lectura. El tiempo máximo de espera equivale al período de tiempo de espera de consistencia de lectura (predeterminado: 10 ms).
Cuando se utiliza la consistencia global y ocurre un retraso de replicación, el proxy redirige más lecturas a la instancia principal, lo que incrementa aún más su carga y latencia.
Configure el nivel de consistencia
Vaya a la página Instances. En la barra de navegación superior, seleccione la región donde reside su instancia RDS y haga clic en el ID de la instancia.
En el panel de navegación izquierdo, haga clic en Database Proxy.
En la sección Connection Information, busque el endpoint del proxy de base de datos y haga clic en Modify Configuration en la columna Actions.
Seleccione un nivel de consistencia.
Para la consistencia eventual y la consistencia de sesión, puede establecer un umbral de latencia. El valor predeterminado es 30 segundos. Si una instancia de solo lectura supera este umbral, el proxy deja de enrutar lecturas hacia ella.
Para la consistencia de sesión y la consistencia global, puede establecer un read consistency timeout period . El valor predeterminado es 10 ms.
Apéndice: Implementación de la consistencia de sesión y la consistencia global
Para implementar la consistencia de sesión y la consistencia global, el proxy de base de datos supervisa el valor Executed_Gtid_Set en cada instancia de solo lectura, que corresponde al conjunto de transacciones que ha aplicado dicha instancia.
Antes de enrutar cada lectura, el proxy determina el GTID requerido y selecciona una instancia de solo lectura que ya haya alcanzado esa posición. Si ninguna instancia se ha puesto al día dentro del período de tiempo de espera de consistencia de lectura, la solicitud se redirige a la instancia principal.
El GTID requerido difiere según el nivel de consistencia:
Consistencia de sesión: El GTID de la transacción confirmada más reciente en la sesión actual.
Consistencia global: El GTID de la transacción confirmada más reciente en todo el clúster.
Referencia de API
|
Operación |
Descripción |
|
Consulta la configuración detallada del proxy de base de datos para una instancia RDS. |
|
|
Consulta información sobre un endpoint del proxy de base de datos. |
|
|
Modifique la configuración de conexión para un endpoint del proxy de base de datos. |