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.

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. Además, no se admiten funciones ni procedimientos definidos por el usuario. 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.

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.

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)