Uso del reenvío de escritura local en un clúster de base de datos de Amazon Aurora MySQL

El reenvío de escritura local (en el clúster) permite a sus aplicaciones emitir transacciones de lectura/escritura directamente en una réplica de Aurora. A continuación, estas transacciones se reenvían a la instancia de base de datos del escritor para su confirmación. Puede utilizar el reenvío de escritura local cuando sus aplicaciones requieran coherencia de lectura después de escritura, que es la capacidad de leer la última escritura de una transacción.

Las réplicas de lectura reciben actualizaciones del escritor de forma asincrónica. Sin el reenvío de escritura, tiene que realizar transacciones de cualquier lectura que requiera coherencia de lectura después de escritura en la instancia de base de datos del escritor. O bien, tiene que desarrollar una lógica de aplicación personalizada y compleja para aprovechar numerosas réplicas de lectura para la escalabilidad. Sus aplicaciones deben dividir completamente todo el tráfico de lectura y escritura, manteniendo dos conjuntos de conexiones a bases de datos para enviar el tráfico al punto de conexión correcto. Esta sobrecarga de desarrollo complica el diseño de la aplicación cuando las consultas forman parte de una única sesión lógica, o transacción, dentro de la aplicación. Además, dado que el retraso de replicación puede variar entre las réplicas de lectura, es difícil lograr una coherencia de lectura global en todas las instancias de la base de datos.

El reenvío de escritura evita la necesidad de dividir esas transacciones o enviarlas exclusivamente al escritor, lo que simplifica el desarrollo de la aplicación. Esta nueva capacidad facilita la escalabilidad de lectura para las cargas de trabajo que necesitan leer la última escritura de una transacción y no son sensibles a la latencia de escritura.

El reenvío de escritura local es diferente del reenvío de escritura global, que reenvía las escrituras de un clúster de base de datos secundario al clúster de base de datos principal en una base de datos global de Aurora. Puede utilizar el reenvío de escritura local en un clúster de base de datos que forme parte de una base de datos global de Aurora. Para obtener más información, consulte Uso del reenvío de escritura en una base de datos Amazon Aurora global.

El reenvío de escritura local requiere las versiones 3.04 y posteriores de Aurora MySQL.

Habilitación del reenvío de escritura local

De forma predeterminada, el reenvío de escritura local no está habilitado para los clústeres de bases de datos de Aurora MySQL. El reenvío de escritura local se habilita a nivel de clúster, no a nivel de instancia.

aws rds create-db-cluster \
  --db-cluster-identifier write-forwarding-test-cluster \
  --enable-local-write-forwarding \
  --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.04.0 \
  --master-username myuser \
  --master-user-password mypassword \
  --backup-retention 1

Habilitación del reenvío de escritura para las sesiones de bases de datos

El parámetro aurora_replica_read_consistency es un parámetro de base de datos y un parámetro de clúster de base de datos que permite el reenvío de escritura. Puede especificar EVENTUAL, SESSION o GLOBAL para el nivel de coherencia de lectura. Para obtener más información sobre los niveles de consistencia, consulte Coherencia de lectura para el reenvío de escritura.

Las siguientes reglas se aplican a este parámetro:

Comprobación de si un clúster de base de datos tiene habilitado el reenvío de escritura

Para determinar si puede utilizar el reenvío de escritura en un clúster de base de datos, confirme que el clúster tenga el atributo LocalWriteForwardingStatus establecido en enabled.

En la AWS Management Console, en la pestaña Configuración de la página de detalles del clúster, verá el estado Habilitado para Reenvío de escritura de réplica de lectura local.

Para ver el estado de la configuración de reenvío de escritura de todos los clústeres, ejecute el siguiente comando de la AWS CLI.

aws rds describe-db-clusters \
--query '*[].{DBClusterIdentifier:DBClusterIdentifier,LocalWriteForwardingStatus:LocalWriteForwardingStatus}'

[
    {
        "LocalWriteForwardingStatus": "enabled",
        "DBClusterIdentifier": "write-forwarding-test-cluster-1"
    },
    {
        "LocalWriteForwardingStatus": "disabled",
        "DBClusterIdentifier": "write-forwarding-test-cluster-2"
    },
    {
        "LocalWriteForwardingStatus": "requested",
        "DBClusterIdentifier": "test-global-cluster-2"
    },
    {
        "LocalWriteForwardingStatus": "null",
        "DBClusterIdentifier": "aurora-mysql-v2-cluster"
    }
]

Un clúster de base de datos puede tener los siguientes valores para LocalWriteForwardingStatus:

Compatibilidad de las aplicaciones con el reenvío de escritura

Puede utilizar los siguientes tipos de instrucciones SQL con reenvío de escritura:

Algunas instrucciones no están permitidas o pueden producir resultados obsoletos cuando se utilizan en un clúster de base de datos con reenvío de escritura. Por lo tanto, la configuración EnableLocalWriteForwarding está deshabilitada de forma predeterminada para los clústeres de bases de datos. Antes de la habilitación, asegúrese de que el código de la aplicación no se verá afectado por ninguna de estas restricciones.

Las siguientes restricciones se aplican a las instrucciones SQL que utiliza con el reenvío de escritura. En algunos casos, puede utilizar las instrucciones en clústeres de bases de datos con reenvío de escritura habilitado. Este enfoque funciona si el reenvío de escritura no está habilitado dentro de la sesión por el parámetro de configuración aurora_replica_read_consistency. Si intenta usar una instrucción cuando no está permitida debido al reenvío de escritura, verá un mensaje de error similar al siguiente:

ERROR 1235 (42000): This version of MySQL doesn't yet support 'operation with write forwarding'.

Niveles de aislamiento para el reenvío de escritura

En las sesiones que utilizan reenvío de escritura, solo puede utilizar el nivel de aislamiento REPEATABLE READ. Aunque también puede utilizar el nivel de aislamiento READ COMMITTED con réplicas de Aurora, ese nivel de aislamiento no funciona con el reenvío de escritura. Para obtener información acerca de los niveles de aislamiento de REPEATABLE READ y READ COMMITTED, consulte Niveles de aislamiento de Aurora MySQL.

Coherencia de lectura para el reenvío de escritura

Puede controlar cuál es el grado de coherencia de lectura en un clúster de base de datos. El nivel de coherencia de lectura determina cuánto espera el clúster base de datos antes de cada operación de lectura para garantizar que algunos de los cambios o todos los cambios se repliquen desde el escritor. Puede ajustar el nivel de coherencia de lectura para asegurarse de que todas las operaciones de escritura reenviadas desde la sesión estén visibles en el clúster de base de datos antes de cualquier consulta posterior. También puede utilizar esta configuración para asegurarse de que las consultas del clúster de base de datos siempre vean las actualizaciones más recientes del escritor. Esta configuración también se aplica a las consultas enviadas por otras sesiones u otros clústeres. Para especificar este tipo de comportamiento para la aplicación, elija un valor para el parámetro del clúster de base de datos o el parámetro de base de datos aurora_replica_read_consistency.

A medida que aumenta el nivel de coherencia, la aplicación pasa más tiempo esperando que los cambios se propaguen entre instancias de base de datos. Puede buscar el equilibrio entre un tiempo de respuesta rápido y la garantía de que los cambios realizados en otras instancias de base de datos estén completamente disponibles antes de que se ejecuten las consultas.

Puede especificar los siguientes valores para el parámetro aurora_replica_read_consistency:

Para obtener información sobre los parámetros de configuración relacionados con el reenvío de escritura, consulte Parámetros de configuración para el reenvío de escritura.

mysql> set aurora_replica_read_consistency = 'session';

Ejemplos de uso del reenvío de escritura

El siguiente ejemplo muestra los efectos del parámetro aurora_replica_read_consistency en la ejecución de instrucciones INSERT seguidas de instrucciones SELECT. Los resultados pueden diferir según el valor de aurora_replica_read_consistency y el momento en que se produzcan las instrucciones.

Para lograr una mayor coherencia, puede esperar brevemente antes de emitir la instrucción SELECT. O Aurora puede esperar automáticamente hasta que los resultados terminen de replicarse antes de continuar con SELECT.

Para obtener información sobre la configuración de parámetros de base de datos, consulte Grupos de parámetros para Amazon Aurora.

mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        5 |
+----------+
1 row in set (0.00 sec)

mysql> insert into t1 values (6); select count(*) from t1;
+----------+
| count(*) |
+----------+
|        5 |
+----------+
1 row in set (0.00 sec)

mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)

mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.01 sec)

mysql> insert into t1 values (6); select count(*) from t1; select count(*) from t1;
Query OK, 1 row affected (0.08 sec)
+----------+
| count(*) |
+----------+
|        7 |
+----------+
1 row in set (0.37 sec)
+----------+
| count(*) |
+----------+
|        7 |
+----------+
1 row in set (0.00 sec)

mysql> insert into t1 values (6); select sleep(2); select count(*) from t1;
Query OK, 1 row affected (0.07 sec)
+----------+
| sleep(2) |
+----------+
|        0 |
+----------+
1 row in set (2.01 sec)
+----------+
| count(*) |
+----------+
|        8 |
+----------+
1 row in set (0.00 sec)

mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        8 |
+----------+
1 row in set (0.75 sec)

mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        8 |
+----------+
1 row in set (0.37 sec)

mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        8 |
+----------+
1 row in set (0.66 sec)

Ejecutar instrucciones multiparte con reenvío de escritura

Una instrucción DML puede constar de varias partes, como una instrucción INSERT ... SELECT o una instrucción DELETE ... WHERE. En este caso, la instrucción completa se reenvía a la instancia de base de datos del escritor y se ejecuta allí.

Transacciones con reenvío de escritura

Si el modo de acceso de la transacción está configurado en solo lectura, no se utiliza el reenvío de escritura. Puede especificar el modo de acceso de la transacción mediante la instrucción SET TRANSACTION o la instrucción START TRANSACTION. También puede cambiar el valor de la variable de sesión transaction_read_only para especificar el modo de acceso de la transacción. Solo puede cambiar este valor de sesión cuando esté conectado a un clúster de base de datos que tenga habilitado el reenvío de escritura.

Si una transacción de larga duración no emite ninguna instrucción durante un período de tiempo significativo, podría exceder el período de tiempo de espera de inactividad. Este período tiene un valor predeterminado de un minuto. Puede configurar el parámetro aurora_fwd_writer_idle_timeout para aumentarlo hasta un día. La instancia del escritor cancela las transacciones que superen el tiempo de espera de inactividad. La siguiente instrucción que envíe recibirá un error de tiempo de espera. A continuación, Aurora revertirá la transacción.

Este tipo de error puede producirse en otros casos cuando el reenvío de escritura deja de estar disponible. Por ejemplo, Aurora cancela las transacciones que utilicen el reenvío de escritura si reinicia el clúster de base de datos o si deshabilita la configuración de reenvío de escritura.

Cuando se reinicia una instancia del escritor de un clúster que utiliza el reenvío de escritura local, todas las transacciones y consultas activas reenviadas en las instancias del lector que utilizan el reenvío de escritura local se cierran automáticamente. Cuando la instancia del escritor vuelva a estar disponible, podrá volver a intentar estas transacciones.

Parámetros de configuración para el reenvío de escritura

Los grupos de parámetros de base de datos de Aurora contienen ajustes para la característica de reenvío de escritura. Los detalles sobre estos parámetros se resumen en la tabla siguiente, con notas de uso después de la tabla.

Para controlar las solicitudes de escritura entrantes, utilice esta configuración:

Para obtener más información acerca de aurora_replica_read_consistency, consulte Coherencia de lectura para el reenvío de escritura.

Para obtener más información acerca de los grupos de parámetros de base de datos, consulte Grupos de parámetros para Amazon Aurora.

Métricas de Amazon CloudWatch y variables de estado de Aurora MySQL para el reenvío de escritura

Las siguientes métricas de Amazon CloudWatch y variables de estado de Aurora MySQL se aplican cuando se utiliza el reenvío de escritura en uno o más clústeres de base de datos. Todas estas métricas y variables de estado se miden en la instancia de base de datos del escritor.

Las siguientes métricas de CloudWatch y las variables de estado de Aurora MySQL se miden en cada instancia de base de datos del lector de un clúster de base de datos con reenvío de escritura habilitado.

Identificación de transacciones y consultas reenviadas

Puede utilizar la tabla information_schema.aurora_forwarding_processlist para identificar las transacciones y consultas reenviadas. Para obtener más información sobre esta tabla, consulte information_schema.aurora_forwarding_processlist.

El siguiente ejemplo muestra todas las conexiones reenviadas en una instancia de base de datos del escritor.

mysql> select * from information_schema.AURORA_FORWARDING_PROCESSLIST where IS_FORWARDED=1 order by REPLICA_SESSION_ID;

+-----+----------+--------------------+----------+---------+------+--------------+--------------------------------------------+--------------+--------------------+---------------------------------+----------------------+----------------+
| ID  | USER     | HOST               | DB       | COMMAND | TIME | STATE        | INFO                                       | IS_FORWARDED | REPLICA_SESSION_ID | REPLICA_INSTANCE_IDENTIFIER     | REPLICA_CLUSTER_NAME | REPLICA_REGION |
+-----+----------+--------------------+----------+---------+------+--------------+--------------------------------------------+--------------+--------------------+---------------------------------+---------------------------------------+
| 648 | myuser   | IP_address:port1   | sysbench | Query   |    0 | async commit | UPDATE sbtest58 SET k=k+1 WHERE id=4802579 |            1 |                637 | my-db-cluster-instance-2        | my-db-cluster        | us-west-2      |
| 650 | myuser   | IP_address:port2   | sysbench | Query   |    0 | async commit | UPDATE sbtest54 SET k=k+1 WHERE id=2503953 |            1 |                639 | my-db-cluster-instance-2        | my-db-cluster        | us-west-2      |
+-----+----------+--------------------+----------+---------+------+--------------+--------------------------------------------+--------------+--------------------+---------------------------------+----------------------+----------------+

En la instancia de base de datos del lector de reenvío, puede ver los subprocesos asociados a estas conexiones de base de datos del escritor si ejecuta SHOW PROCESSLIST. Los valores REPLICA_SESSION_ID del escritor, 637 y 639, son los mismos que los valores Id del lector.

mysql> select @@aurora_server_id;

+---------------------------------+
| @@aurora_server_id              |
+---------------------------------+
| my-db-cluster-instance-2        |
+---------------------------------+
1 row in set (0.00 sec)

mysql> show processlist;

+-----+----------+--------------------+----------+---------+------+--------------+---------------------------------------------+
| Id  | User     | Host               | db       | Command | Time | State        | Info                                        |
+-----+----------+--------------------+----------+---------+------+--------------+---------------------------------------------+
| 637 | myuser   | IP_address:port1   | sysbench | Query   |    0 | async commit | UPDATE sbtest12 SET k=k+1 WHERE id=4802579  |
| 639 | myuser   | IP_address:port2   | sysbench | Query   |    0 | async commit | UPDATE sbtest61 SET k=k+1 WHERE id=2503953  |
+-----+----------+--------------------+----------+---------+------+--------------+---------------------------------------------+
12 rows in set (0.00 sec)