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.
Temas
- Habilitación del reenvío de escritura local
- Comprobación de si un clúster de base de datos tiene habilitado el reenvío de escritura
- Compatibilidad de las aplicaciones con el reenvío de escritura
- Niveles de aislamiento para el reenvío de escritura
- Coherencia de lectura para el reenvío de escritura
- Ejecutar instrucciones multiparte con reenvío de escritura
- Transacciones con reenvío de escritura
- Parámetros de configuración para el reenvío de escritura
- Métricas de Amazon CloudWatch y variables de estado de Aurora MySQL para el reenvío de escritura
- Identificación de transacciones y consultas reenviadas
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.
importante
También puede habilitar el reenvío de escritura local para las réplicas de lectura entre regiones que utilizan el registro binario, pero las operaciones de escritura no se reenvían a la Región de AWS de origen. Se reenvían a la instancia de base de datos del escritor del clúster de réplicas de lectura de binlog.
Utilice este método solo si tiene un caso de uso que requiera escribir en la réplica de lectura de binlog en la Región de AWS secundaria. De no ser así, podría acabar con un escenario de “cerebro dividido” en el que los conjuntos de datos replicados no son coherentes entre sí.
«Recomendamos utilizar el reenvío de escritura global en las bases de datos globales, en lugar del reenvío de escritura local en las réplicas de lectura entre regiones, a menos que sea absolutamente necesario. Para obtener más información, consulte Uso del reenvío de escritura en una base de datos Amazon Aurora global.
Si usa la AWS Management Console, seleccione la casilla de verificación Activar el reenvío de escritura loca debajo de Reenvío de escritura de réplicas de lectura al crear o modificar un clúster de base de datos.
Para habilitar el reenvío de escritura con la AWS CLI, utilice la opción --enable-local-write-forwarding
. Esta opción funciona cuando crea un nuevo clúster de basede datos mediante el comando create-db-cluster
. También funciona cuando modifica un clúster de base de datos existente mediante el comando modify-db-cluster
. Puede deshabilitar el reenvío de escritura mediante la opción --no-enable-local-write-forwarding
con estos mismos comandos de la CLI.
En el siguiente ejemplo se crea un clúster de base de datos de Aurora MySQL con el reenvío de escritura habilitado.
aws rds create-db-cluster \ --db-cluster-identifier write-forwarding-test-cluster \
--enable-local-write-forwarding
\ --engine aurora-mysql \ --engine-version8.0.mysql_aurora.3.04.0
\ --master-username myuser \ --master-user-password mypassword \ --backup-retention 1
A continuación, crea instancias de base de datos del escritor y lector para poder utilizar el reenvío de escritura. Para obtener más información, consulte Creación de un clúster de base de datos de Amazon Aurora.
Para habilitar el reenvío de escritura mediante la API de Amazon RDS, establezca el parámetro EnableLocalWriteForwarding
en true
. Este parámetro funciona cuando crea un nuevo clúster de base de datos mediante la operación CreateDBCluster
. También funciona cuando modifica un clúster de base de datos existente mediante la operación ModifyDBCluster
. Puede deshabilitar el reenvío de escritura estableciendo el parámetro EnableLocalWriteForwarding
en false
.
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:
-
El valor predeterminado es '' (null).
-
El reenvío de escritura solo está disponible si establece
aurora_replica_read_consistency
enEVENTUAL
,SESSION
oGLOBAL
. Este parámetro solo es pertinente en instancias del lector de clústeres de bases de datos que tengan habilitado el reenvío de escritura. -
No puede establecer este parámetro (cuando está vacío) o desestablecerlo (cuando ya está configurado) dentro de una transacción de múltiples instrucciones. Puede cambiarlo de un valor válido a otro valor válido durante una transacción de este tipo, pero no recomendamos esta acción.
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
:
-
disabled
: el reenvío de escritura está deshabilitado. -
disabling
: el reenvío de escritura está en proceso de deshabilitación. -
enabled
: el reenvío de escritura está habilitado. -
enabling
: el reenvío de escritura está en proceso de habilitación. -
null
: el reenvío de escritura no está disponible para este clúster de base de datos. -
requested
: se ha solicitado el reenvío de escritura, pero aún no está activo.
Compatibilidad de las aplicaciones con el reenvío de escritura
Puede utilizar los siguientes tipos de instrucciones SQL con reenvío de escritura:
-
Instrucciones de lenguaje de manipulación de datos (DML) como
INSERT
,DELETE
yUPDATE
. Existen algunas restricciones sobre las propiedades de estas instrucciones que puede utilizar con el reenvío de escritura, como se describe a continuación. -
Instrucciones
SELECT ... LOCK IN SHARE MODE
ySELECT FOR UPDATE
. -
Instrucciones
PREPARE
yEXECUTE
.
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'.
- Lenguaje de definición de datos (DDL)
-
Conéctese a la instancia de base de datos del escritor para ejecutar instrucciones DDL. No puede ejecutarlas desde instancias de base de datos del lector.
- Actualizar una tabla permanente con datos de una tabla temporal
-
Puede utilizar tablas temporales en clústeres de base de datos con el reenvío de escritura habilitado. Sin embargo, no puede utilizar una instrucción DML para modificar una tabla permanente si la instrucción hace referencia a una tabla temporal. Por ejemplo, no puede utilizar una instrucción
INSERT ... SELECT
que saque los datos de una tabla temporal. - Transacciones XA
-
No puede utilizar las siguientes instrucciones en un clúster de base de datos cuando el reenvío de escritura esté activado dentro de la sesión. Puede utilizar estas instrucciones en clústeres de bases de datos que no tengan habilitado el reenvío de escritura o en sesiones en las que la configuración
aurora_replica_read_consistency
esté vacía. Antes de habilitar el reenvío de escritura dentro de una sesión, compruebe si su código utiliza estas instrucciones.XA {START|BEGIN} xid [JOIN|RESUME] XA END xid [SUSPEND [FOR MIGRATE]] XA PREPARE xid XA COMMIT xid [ONE PHASE] XA ROLLBACK xid XA RECOVER [CONVERT XID]
- Instrucciones LOAD para tablas permanentes
-
No puede utilizar las siguientes instrucciones en un clúster de base de datos con reenvío de escritura habilitado.
LOAD DATA INFILE 'data.txt' INTO TABLE t1; LOAD XML LOCAL INFILE 'test.xml' INTO TABLE t1;
- Instrucciones de complemento
-
No puede utilizar las siguientes instrucciones en un clúster de base de datos con reenvío de escritura habilitado.
INSTALL PLUGIN example SONAME 'ha_example.so'; UNINSTALL PLUGIN example;
- Declaraciones SAVEPOINT
-
No puede utilizar las siguientes instrucciones en un clúster de base de datos cuando el reenvío de escritura esté activado dentro de la sesión. Puede utilizar estas instrucciones en clústeres de bases de datos que no tengan habilitado el reenvío de escritura o en sesiones en las que la configuración
aurora_replica_read_consistency
esté en blanco. Antes de habilitar el reenvío de escritura dentro de una sesión, compruebe si su código utiliza estas instrucciones.SAVEPOINT t1_save; ROLLBACK TO SAVEPOINT t1_save; RELEASE SAVEPOINT t1_save;
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
.
importante
Configure siempre el parámetro del clúster de base de datos o el parámetro de base de datos aurora_replica_read_consistency
cuando desee utilizar el reenvío de escritura. Si no lo hace, Aurora no reenvía las escrituras. Este parámetro tiene un valor vacío por defecto, por lo que debe elegir un valor específico cuando utilice este parámetro. El parámetro aurora_replica_read_consistency
solo afecta a los clústeres o instancias de base de datos que tengan habilitado el reenvío de escritura.
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
:
-
EVENTUAL
: los resultados de las operaciones de escritura de la misma sesión no están visibles hasta que la operación de escritura se realice en la instancia de base de datos del escritor. La consulta no espera a que los resultados actualizados estén disponibles. Por lo tanto, podría recuperar los datos antiguos o los datos actualizados, en función del momento de las instrucciones y la cantidad de retraso de replicación. Se trata de la misma coherencia que en los clústeres de bases de datos de Aurora MySQL que no utilizan el reenvío de escritura. -
SESSION
: todas las consultas que utilizan el reenvío de escritura ven los resultados de todos los cambios realizados en esa sesión. Los cambios son visibles independientemente de si la transacción está confirmada. Si es necesario, la consulta espera a que se repliquen los resultados de las operaciones de escritura reenviadas. -
GLOBAL
: una sesión ve todos los cambios confirmados en todas las sesiones e instancias del clúster de base de datos. Cada consulta puede esperar un tiempo, que variará en función de la cantidad de retardo de la sesión. La consulta continúa cuando el clúster de base de datos está actualizado con todos los datos confirmados del escritor, a partir del momento en que comenzó la consulta.
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.
nota
También puede usar aurora_replica_read_consistency
como una variable de sesión, por ejemplo:
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.
ejemplo con aurora_replica_read_consistency
establecido en EVENTUAL
Ejecutar una instrucción INSERT
, seguida inmediatamente de una instrucción SELECT
, devuelve un valor para COUNT(*)
con el número de filas antes de insertar la nueva fila. Al ejecutar SELECT
de nuevo poco tiempo después se devuelve el recuento de filas actualizado. Las instrucciones SELECT
no esperan.
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)
ejemplo con aurora_replica_read_consistency
establecido en SESSION
Una instrucción SELECT
inmediatamente después de una instrucción INSERT
espera hasta que los cambios de la instrucción INSERT
sean visibles. Las instrucciones SELECT
posteriores no esperan.
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)
Con la configuración de coherencia de lectura todavía establecida en SESSION
, al introducir una breve espera después de realizar una instrucción INSERT
, el recuento de filas actualizado estará disponible para cuando se ejecute la siguiente instrucción SELECT
.
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)
ejemplo con aurora_replica_read_consistency
establecido en GLOBAL
Cada instrucción SELECT
espera a que todos los cambios de datos que se realicen a partir de la hora de inicio de la instrucción sean visibles antes de realizar la consulta. El tiempo de espera para cada instrucción SELECT
varía según la cantidad de retraso de replicación.
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
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.
Parámetro | Ámbito | Tipo | Valor predeterminado | Valores válidos |
---|---|---|---|---|
aurora_fwd_writer_idle_timeout |
Clúster | Entero sin signo | 60 | 1-86 400 |
aurora_fwd_writer_max_connections_pct |
Clúster | Entero largo sin signo | 10 | 0–90 |
aurora_replica_read_consistency |
Instancia o clúster | Enum | '' (null) | EVENTUAL , SESSION , GLOBAL |
Para controlar las solicitudes de escritura entrantes, utilice esta configuración:
-
aurora_fwd_writer_idle_timeout
: el número de segundos que la instancia de base de datos del escritor espera a que se produzca actividad en una conexión que se reenvía desde una instancia del lector antes de cerrarla. Si la sesión permanece inactiva al finalizar este período, Aurora la cancela. -
aurora_fwd_writer_max_connections_pct
: el límite superior en conexiones de base de datos que se puede utilizar en una instancia de base de datos del escritor para gestionar las consultas reenviadas desde las instancias del lector. Se expresa como un porcentaje de la configuraciónmax_connections
del escritor. Por ejemplo, simax_connections
es 800 yaurora_fwd_master_max_connections_pct
oaurora_fwd_writer_max_connections_pct
es 10, el escritor permite un máximo de 80 sesiones reenviadas simultáneas. Estas conexiones provienen del mismo grupo de conexiones administrado por la configuraciónmax_connections
.Esta configuración solo se aplica al escritor cuando tiene habilitado el reenvío de escritura. Si disminuye el valor, las conexiones existentes no se ven afectadas. Aurora tendrá en cuenta el nuevo valor de la configuración al intentar crear una nueva conexión desde un clúster de base de datos. El valor predeterminado es 10, que representa el 10% del valor
max_connections
.
nota
Como aurora_fwd_writer_idle_timeout
y aurora_fwd_writer_max_connections_pct
son parámetros de clúster de base de datos, todas las instancias de base de datos de cada clúster tienen los mismos valores para estos parámetros.
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.
Métrica de CloudWatch | Variable de estado de Aurora MySQL | Unidad | Descripción |
---|---|---|---|
|
– | Milisegundos |
Tiempo medio para procesar cada instrucción DML reenviada en la instancia de base de datos de escritor. No incluye el tiempo que tarda el clúster de base de datos en reenviar la solicitud de escritura ni el tiempo necesario para replicar los cambios en el escritor. |
|
– | Recuento por segundo | Número de instrucciones DML reenviadas procesadas cada segundo por esta instancia de base de datos de escritor. |
|
Aurora_fwd_writer_open_sessions |
Recuento | Número de sesiones reenviadas en la instancia de base de datos de escritor. |
– |
Aurora_fwd_writer_dml_stmt_count |
Recuento | Número total de instrucciones DML reenviadas a esta instancia de base de datos de escritor. |
– |
Aurora_fwd_writer_dml_stmt_duration |
Microsegundos | Duración total de las instrucciones DML reenviadas a esta instancia de base de datos de escritor. |
– |
Aurora_fwd_writer_select_stmt_count |
Recuento | Número total de instancias SELECT reenviadas a esta instancia de base de datos de escritor. |
– |
Aurora_fwd_writer_select_stmt_duration |
Microsegundos | Duración total de las instrucciones SELECT reenviadas a esta instancia de base de datos de 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.
Métrica de CloudWatch | Variable de estado de Aurora MySQL | Unidad | Descripción |
---|---|---|---|
|
– | Milisegundos | Tiempo medio de respuesta de DML reenviadas en la réplica. |
|
– | Recuento por segundo | Número de sentencias DML reenviadas procesadas por segundo. |
|
Aurora_fwd_replica_open_sessions |
Recuento | Número de sesiones que utilizan el reenvío de escritura en una instancia de base de datos del lector. |
|
– | Milisegundos |
Tiempo de espera medio que una instrucción El grado en que la instancia de base de datos de lector espera antes de procesar una consulta depende de la configuración |
|
– | Recuento por segundo | Número total de SELECT instrucciones procesadas cada segundo en todas las sesiones que reenvían escrituras. |
|
– | Milisegundos | Latencia SELECT reenviada, promediada sobre todas las instrucciones SELECT reenviadas dentro del período de supervisión. |
|
– | Recuento por segundo | Rendimiento SELECT reenviado, media por segundo dentro del período de supervisión. |
– |
Aurora_fwd_replica_dml_stmt_count |
Recuento | Número total de instrucciones DML reenviadas desde esta instancia de base de datos de lector. |
– |
Aurora_fwd_replica_dml_stmt_duration |
Microsegundos | Duración total de las instrucciones DML reenviadas desde esta instancia de base de datos de lector. |
– |
Aurora_fwd_replica_errors_session_limit |
Recuento |
Número de sesiones rechazadas por el clúster principal debido a una de las siguientes condiciones de error:
|
– |
Aurora_fwd_replica_read_wait_count |
Recuento | Número total de esperas de lectura tras escritura en esta instancia de base de datos del lector. |
– |
Aurora_fwd_replica_read_wait_duration |
Microsegundos | Duración total de las esperas debido a la configuración de coherencia de lectura en esta instancia de base de datos de lector. |
– |
Aurora_fwd_replica_select_stmt_count |
Recuento | Número total de instrucciones SELECT reenviadas desde esta instancia de base de datos de lector. |
– |
Aurora_fwd_replica_select_stmt_duration |
Microsegundos | Duración total de las instrucciones SELECT reenviadas desde esta instancia de base de datos de lector. |
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)