# Reenvío de escritura local en Aurora PostgreSQL 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, los comandos de escritura se reenvían a la instancia de base de datos del escritor para su confirmación. Puede utilizar el reenvío de escritura local para las aplicaciones que tengan escrituras ocasionales y requieran *coherencia de lectura después de escritura*, que es la capacidad de leer la última escritura de una transacción. Sin el reenvío de escritura, 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 adecuado. Las réplicas de lectura reciben actualizaciones de la instancia del escritor de forma asincrónica. 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 réplicas. Debe 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, tendría que desarrollar una lógica de aplicación personalizada y compleja para aprovechar numerosas réplicas de lectura para la escalabilidad mientras se garantiza la coherencia. Con el reenvío de escritura evita la necesidad de dividir esas transacciones o enviarlas exclusivamente a la instancia del escritor. Tampoco es necesario desarrollar una lógica de aplicación compleja para lograr una coherencia en la *lectura después de la escritura*. El reenvío de escritura local está disponible en todas las regiones en las que Aurora PostgreSQL está disponible. Se admite en las siguientes versiones de Aurora PostgreSQL: + Versión 16.4 y otras versiones 16 superiores + Versión 15.8 y otras versiones 15 superiores + Versión 14.13 y otras versiones 14 superiores El reenvío de escritura local se utiliza para reenviar escrituras desde réplicas de la región. Para reenviar las escrituras desde una réplica global, consulte [Uso del reenvío de escritura en una base de datos Amazon Aurora global](aurora-global-database-write-forwarding.md). **Topics** + [Limitaciones y consideraciones del reenvío de escritura local en Aurora PostgreSQL](aurora-postgresql-write-forwarding-limitations.md) + [Configuración de Aurora PostgreSQL para el reenvío de escritura local](aurora-postgresql-write-forwarding-configuring.md) + [Procedimiento del reenvío de escritura local en Aurora PostgreSQL](aurora-postgresql-write-forwarding-understanding.md) + [Supervisión del reenvío de escritura local en Aurora PostgreSQL](aurora-postgresql-write-forwarding-monitoring.md) # Limitaciones y consideraciones del reenvío de escritura local en Aurora PostgreSQL Las limitaciones siguientes se aplican actualmente al reenvío de escritura local en Aurora PostgreSQL: + RDS Proxy no admite el reenvío de escritura local. + Algunas instrucciones no están permitidas o pueden producir resultados obsoletos cuando se utilizan en Aurora PostgreSQL con reenvío de escritura. Además, no se admiten funciones ni procedimientos definidos por el usuario. Por ello, la configuración `EnableLocalWriteForwarding` está desactivada de forma predeterminada para los clústeres de base de datos. Antes de activarla, asegúrese de que el código de la aplicación no se vea afectado por ninguna de estas restricciones. + Los siguientes tipos de instrucciones SQL no son compatibles con el reenvío de escritura: **nota** Puede utilizar estas declaraciones de forma implícita en su aplicación o inferirlas mediante el protocolo PostgreSQL. Por ejemplo, la gestión de excepciones de PL/SQL puede provocar el uso de SAVEPOINT, que no es una declaración admitida. + `ANALYZE` + `CLUSTER` + `COPY` + Cursores: los cursores no son compatibles, así que debe asegurarse de cerrarlos antes de utilizar el reenvío de escritura local. + Instrucciones en lenguaje de definición de datos (DDL) + `GRANT`\$1`REVOKE`\$1`REASSIGN OWNED`\$1`SECURITY LABEL` + `LISTEN / NOTIFY` + `LOCK` + `SAVEPOINT` + `SELECT INTO` + `SET CONSTRAINTS` + Actualizaciones de secuencias: `nextval()` y `setval()` + `TRUNCATE` + Comandos de confirmación en dos fases: `PREPARE TRANSACTION`, `COMMIT PREPARED` y `ROLLBACK PREPARED` + Funciones y procedimientos definidos por el usuario. + `VACUUM` Puede considerar el uso de las siguientes instrucciones SQL 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í. + Instrucciones de lenguaje de manipulación de datos (DML) como `INSERT`, `DELETE` y `UPDATE`. + Instrucciones `EXPLAIN` con las instrucciones de esta lista. + Instrucciones `PREPARE` y `EXECUTE`. + Instrucciones `SELECT FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE }` # Configuración de Aurora PostgreSQL para el reenvío de escritura local En las siguientes secciones, puede habilitar el reenvío de escritura local para su clúster de base de datos PostgreSQL de Amazon Aurora, configurar los niveles de consistencia y administrar las transacciones con el reenvío de escritura. ## 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 base de datos de Aurora PostgreSQL. El reenvío de escritura local se habilita a nivel de clúster, no a nivel de instancia. ### Consola Si usa la Consola de administración de AWS, 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. ### AWS CLI Para habilitar el reenvío de escritura local 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 local 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 PostgreSQL con el reenvío de escritura local habilitado. ``` aws rds create-db-cluster \ --db-cluster-identifier write-forwarding-test-cluster \ --enable-local-write-forwarding \ --engine aurora-postgresql \ --engine-version 16.4 \ --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](Aurora.CreateInstance.md). ### API de RDS Para habilitar el reenvío de escritura local 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 local estableciendo el parámetro `EnableLocalWriteForwarding` en `false`. ### Habilitación del reenvío de escritura local para las sesiones de bases de datos El parámetro `apg_write_forward.consistency_mode` 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 `SESSION`, `EVENTUAL`, `GLOBAL` o `OFF` para el nivel de coherencia de lectura. Para obtener más información sobre los niveles de consistencia, consulte [Coherencia y aislamiento del reenvío de escritura local en Aurora PostgreSQL](#aurora-postgresql-write-forwarding-isolation). Las siguientes reglas se aplican a este parámetro: + El valor predeterminado es `SESSION`. + El reenvío de escritura local solo está disponible si establece `apg_write_forward.consistency_mode` en `EVENTUAL`, `SESSION` o `GLOBAL`. 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 local. + Si se establece el valor en `OFF`, se deshabilita el reenvío de escritura local en la sesión. ## Coherencia y aislamiento del reenvío de escritura local en Aurora PostgreSQL Puede controlar cuál es el grado de coherencia de lectura en una réplica de lectura. 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 la réplica de lectura antes de cualquier consulta posterior. También puede utilizar esta configuración para asegurarse de que las consultas de la réplica de lectura siempre vean las actualizaciones más recientes de la instancia de base de datos del escritor. Esto es así incluso para los presentados por otros periodos de sesiones u otros grupos temáticos. Para especificar este tipo de comportamiento para la aplicación, elija el valor adecuado para el parámetro de nivel de sesión `apg_write_forward.consistency_mode`. El parámetro `apg_write_forward.consistency_mode` solo tiene efecto en réplicas de lectura donde está habilitado el reenvío de escritura local. **nota** Para el parámetro `apg_write_forward.consistency_mode`, puede especificar los valores `SESSION`, `EVENTUAL`, `GLOBAL` o `OFF`. De forma predeterminada, el valor se establece en `SESSION`. Si se establece este valor en `OFF`, se deshabilita 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 a las réplicas de lectura. Puede buscar el equilibrio entre una latencia más baja y asegurarse de que los cambios realizados en otras ubicaciones estén completamente disponibles antes de que se ejecuten las consultas. Con cada configuración del modo de coherencia disponible, el efecto es el siguiente: + `SESSION`: una sesión en una réplica de lectura que utiliza el reenvío de escritura verá 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 los resultados de las operaciones de escritura reenviadas se repliquen en la instancia de base de datos del lector actual. No espera a que se actualicen los resultados de las operaciones de escritura realizadas en otras sesiones dentro del clúster de base de datos actual. + `EVENTUAL`: una sesión en una réplica de lectura que utiliza el reenvío de escritura puede ver datos ligeramente obsoletos debido al retardo de replicación. 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 y se repliquen en la réplica de lectura. 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 retardo de replicación. + `GLOBAL`: una sesión de una réplica de lectura puede ver los cambios realizados por esa sesión. También verá todos los cambios confirmados tanto de la instancia de base de datos del escritor de como de otras réplicas de lectura. 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 la réplica de lectura está actualizada con todos los datos confirmados de la instancia de base de datos del escritor, a partir del momento en que comenzó la consulta. **nota** El modo de coherencia global afecta a la latencia de las consultas ejecutadas en una sesión. Esperará incluso cuando la sesión no haya enviado ninguna consulta de escritura. + `OFF`: el reenvío de escritura local está deshabilitado. En las sesiones que utilizan reenvío de escritura, solo puede utilizar los niveles de aislamiento `REPEATABLE READ` y `READ COMMITTED`. Sin embargo, no se admite el nivel de `SERIALIZABLE` aislamiento. Para obtener más información sobre todos los parámetros relacionados con el reenvío de escritura, consulte [Configuración de parámetros predeterminada para el reenvío de escritura](aurora-postgresql-write-forwarding-understanding.md#aurora-postgresql-write-forwarding-params). ## Modos de acceso a transacciones con reenvío de escritura Si el modo de acceso a la transacción está configurado en solo lectura, no se utiliza el reenvío de escritura local. Solo puede establecer el modo de acceso en lectura/escritura cuando esté conectado a un clúster de base de datos y a una sesión que tenga habilitado el reenvío de escritura local. Para obtener más información sobre los modos de acceso a las transacciones, consulte [SET TRANSACTION](https://www.postgresql.org/docs/current/sql-set-transaction.html). # Procedimiento del reenvío de escritura local en Aurora PostgreSQL En las siguientes secciones, puede comprobar si un clúster de base de datos tiene habilitado el reenvío de escritura local, ver las consideraciones de compatibilidad y ver los parámetros configurables y la configuración de la autenticación. Esta información le proporciona los detalles necesarios para utilizar la característica de reenvío de escritura local de Aurora PostgreSQL de forma eficaz. **nota** 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. ## Comprobación de si un clúster de base de datos tiene habilitado el reenvío de escritura local Para determinar si puede utilizar el reenvío de escritura local en un clúster de base de datos, confirme que el clúster tenga el atributo `LocalWriteForwardingStatus` establecido en `enabled`. En la Consola de administración de AWS, 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 local de todos los clústeres, ejecute el siguiente comando de la AWS CLI. **Example** ``` 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-postgresql-v2-cluster" } ] ``` Un clúster de base de datos puede tener los siguientes valores para `LocalWriteForwardingStatus`: + `disabled`: el reenvío de escritura local está deshabilitado. + `disabling`: el reenvío de escritura local está en proceso de deshabilitación. + `enabled`: el reenvío de escritura local está habilitado. + `enabling`: el reenvío de escritura local está en proceso de habilitación. + `null`: el reenvío de escritura local no está disponible para este clúster de base de datos. + `requested`: se ha solicitado el reenvío de escritura local, pero aún no está activo. ## Configuración de parámetros predeterminada para el reenvío de escritura Los grupos de parámetros del clúster de Aurora contienen nuevos ajustes para la característica de reenvío de escritura local. Como se trata de parámetros de clúster, todas las instancias de base de datos de cada clúster tienen los mismos valores para estas variables. Los detalles sobre estos parámetros se resumen en la tabla siguiente, con notas de uso después de la tabla. | Parámetro | Alcance | Tipo | Valor predeterminado | Valores válidos | | --- | --- | --- | --- | --- | | apg\$1write\$1forward.connect\$1timeout | Sesión | segundos | 30 | 0–2147483647 | | apg\$1write\$1forward.consistency\$1mode | Session | enum | Sesión | SESSION, EVENTUAL, GLOBAL, y OFF | | apg\$1write\$1forward.idle\$1in\$1transaction\$1session\$1timeout | Sesión | milisegundos | 86400000 | 0–2147483647 | | apg\$1write\$1forward.idle\$1session\$1timeout | Sesión | milisegundos | 300000 | 0–2147483647 | | apg\$1write\$1forward.max\$1forwarding\$1connections\$1percent | Global | int | 25 | 1–100 | El parámetro `apg_write_forward.max_forwarding_connections_percent` es el límite superior en slots de conexiones de base de datos que se puede utilizar para gestionar las consultas reenviadas desde los lectores. Se expresa como un porcentaje de la configuración `max_connections` de la instancia de base de datos del escritor. Por ejemplo, si `max_connections` es `800` y `apg_write_forward.max_forwarding_connections_percent` 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ón `max_connections`. Esta configuración solo se aplica a la instancia de base de datos del escritor cuando el clúster tiene habilitado el reenvío de escritura local. Utilice la siguiente configuración para controlar las solicitudes de reenvío de escritura local: + `apg_write_forward.consistency_mode`: un parámetro de nivel de sesión que controla el grado de coherencia de lectura en una réplica de lectura. Los valores válidos son `SESSION`, `EVENTUAL`, `GLOBAL` o `OFF`. De forma predeterminada, el valor se establece en `SESSION`. Si se establece el valor en `OFF`, se deshabilita el reenvío de escritura local en la sesión. Para obtener más información sobre los niveles de consistencia, consulte [Coherencia y aislamiento del reenvío de escritura local en Aurora PostgreSQL](aurora-postgresql-write-forwarding-configuring.md#aurora-postgresql-write-forwarding-isolation). Este parámetro solo es pertinente en instancias del lector que tengan habilitado el reenvío de escritura local. + `apg_write_forward.connect_timeout`: el número máximo de segundos que espera la réplica de lectura al establecer una conexión con la instancia de base de datos del escritor antes de desistir. Un valor de `0` significa esperar indefinidamente. + `apg_write_forward.idle_in_transaction_session_timeout`: el número de milisegundos 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 réplica de lectura que tiene una transacción abierta antes de cerrarla. Si la sesión permanece inactiva en la transacción al finalizar este período, Aurora la termina. Un valor de `0` deshabilita el tiempo de espera. + `apg_write_forward.idle_session_timeout`: el número de milisegundos 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 réplica de lectura antes de cerrarla. Si la sesión permanece inactiva al finalizar este período, Aurora la termina. Un valor de `0` desactiva el tiempo de espera. ## rdswriteforwarduser `rdswriteforwarduser` es un usuario que utilizaremos para establecer una conexión entre la réplica de lectura y la instancia de base de datos del escritor. **nota** `rdswriteforwarduser` hereda sus privilegios CONNECT en las bases de datos de los clientes mediante el rol PUBLIC. Si se revocan los privilegios del rol PUBLIC, tendrá que conceder los privilegios CONNECT para las bases de datos a las que deba reenviar las escrituras. # Supervisión del reenvío de escritura local en Aurora PostgreSQL En las siguientes secciones, puede supervisar el reenvío de escritura local en los clústeres de Aurora PostgreSQL, incluidas las métricas pertinentes de CloudWatch y los eventos de espera, para realizar un seguimiento del rendimiento e identificar posibles problemas. ## 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 se aplican a las instancias de base de datos del escritor cuando se utiliza el reenvío de escritura en una o más réplicas de lectura. | Métrica de CloudWatch | Unidades y descripción | | --- | --- | | `AuroraLocalForwardingWriterDMLThroughput` | Recuento por segundo Número de instrucciones DML reenviadas procesadas cada segundo por esta instancia de base de datos de escritor. | | `AuroraLocalForwardingWriterOpenSessions` | Recuento Número de sesiones abiertas en esta instancia de base de datos de escritor que procesa las consultas reenviadas. | | `AuroraLocalForwardingWriterTotalSessions` | Recuento Número total de sesiones reenviadas en esta instancia de base de datos de escritor. | Las siguientes métricas de CloudWatch se aplican a cada réplica de lectura. Estas métricas se miden en cada instancia de base de datos del lector de un clúster de base de datos con el reenvío de escritura local habilitado. | Métrica de CloudWatch | Unidad y descripción | | --- | --- | | `AuroraForwardingReplicaCommitThroughput` | Recuento por segundo Número de confirmaciones en las sesiones reenviadas por esta réplica cada segundo. | | `AuroraForwardingReplicaDMLLatency` | Milisegundos. Tiempo medio de respuesta en milisegundos de los DML reenviados durante la réplica. | | `AuroraForwardingReplicaDMLThroughput` | Recuento por segundo Número de instrucciones DML reenviadas procesadas en esta réplica por segundo. | | `AuroraForwardingReplicaErrorSessionsLimit` | Recuento Número de sesiones rechazadas por la instancia de base de datos del escritor porque se ha alcanzado el límite máximo de conexiones o el límite máximo de conexiones de reenvío de escritura. | | `AuroraForwardingReplicaOpenSessions` | Recuento Número de sesiones que utilizan el reenvío de escritura en una instancia de réplica local. | | `AuroraForwardingReplicaReadWaitLatency` | Milisegundos. Tiempo de espera medio en milisegundos que la réplica espera para ser coherente con el LSN de la instancia de base de datos de escritura. El grado en que la instancia de base de datos de lector espera depende de la configuración apg\$1write\$1forward.consistency\$1mode. Para obtener información sobre esta configuración, consulte [Parámetros de configuración para el reenvío de escritura en Aurora PostgreSQL](aurora-global-database-write-forwarding-apg.md#aurora-global-database-write-forwarding-params-apg). | ## Eventos de espera para el reenvío de escritura local en Aurora PostgreSQL Amazon Aurora genera los siguientes eventos de espera cuando utiliza el reenvío de escritura con Aurora PostgreSQL. **Topics** + [IPC:AuroraWriteForwardConnect](#apg-waits.ipcaurorawriteforwardconnect) + [IPC:AuroraWriteForwardConsistencyPoint](#apg-waits.ipcaurorawriteforwardconsistencypoint) + [IPC:AuroraWriteForwardExecute](#apg-waits.ipc:aurorawriteforwardexecute) + [IPC:AuroraWriteForwardGetGlobalConsistencyPoint](#apg-waits.ipc:aurorawriteforwardgetglobalconsistencypoint) + [IPC:AuroraWriteForwardXactAbort](#apg-waits.ipc:aurorawriteforwardxactabort) + [IPC:AuroraWriteForwardXactCommit](#apg-waits.ipc:aurorawriteforwardxactcommit) + [IPC:AuroraWriteForwardXactStart](#apg-waits.ipc:aurorawriteforwardxactstart) ### IPC:AuroraWriteForwardConnect El evento `IPC:AuroraWriteForwardConnect` se produce cuando un proceso de backend de la réplica de lectura espera a que se abra una conexión con la instancia de base de datos del escritor. **Causas probables del aumento del tiempo de espera** Este evento aumenta a medida que se incrementa el número de intentos de conexión desde una réplica de lectura en el nodo del escritor. **Acciones** Reduzca el número de conexiones simultáneas desde una réplica de lectura en el nodo del escritor. ### IPC:AuroraWriteForwardConsistencyPoint El evento `IPC:AuroraWriteForwardConsistencyPoint` describe cuánto tiempo esperará una consulta de un nodo en la réplica de lectura para que los resultados de las operaciones de escritura reenviadas se repliquen en la región actual. Este evento solo se genera si el parámetro de nivel de sesión `apg_write_forward.consistency_mode` se establece en uno de los siguientes valores: + `SESSION`: las consultas de una réplica de lectura esperan los resultados de todos los cambios realizados en esa sesión. + `GLOBAL`: las consultas de una réplica de lectura esperan los resultados de los cambios realizados en esa sesión, además de todos los cambios confirmados tanto de la instancia de base de datos del escritor como de la réplica de lectura. Para obtener más información sobre la configuración del parámetro `apg_write_forward.consistency_mode`, consulte [Parámetros de configuración para el reenvío de escritura en Aurora PostgreSQL](aurora-global-database-write-forwarding-apg.md#aurora-global-database-write-forwarding-params-apg). **Causas probables del aumento del tiempo de espera** Algunas de las causas más comunes que provocan tiempos de espera más largos son las siguientes: + Aumento del retraso de réplica, medido por la métrica `ReplicaLag` de Amazon CloudWatch. Para obtener más información sobre esta métrica, consulte [Monitoreo de replicación de Aurora PostgreSQL](AuroraPostgreSQL.Replication.md#AuroraPostgreSQL.Replication.Monitoring). + Aumento de la carga en la instancia de base de datos del escritor o en la réplica de lectura. **Acciones** Cambie el modo de coherencia según los requisitos de su aplicación. ### IPC:AuroraWriteForwardExecute El evento `IPC:AuroraWriteForwardExecute` se produce cuando un proceso de backend de la réplica de lectura está esperando a que una consulta reenviada se complete y se obtengan los resultados del nodo del escritor del clúster de base de datos. **Causas probables del aumento del tiempo de espera** Algunas de las causas más comunes que provocan tiempos de espera más largos son las siguientes: + Obtención de una gran cantidad de filas del nodo del escritor. + El aumento de la latencia de la red entre el nodo del escritor y la réplica de lectura incrementa el tiempo que tarda la réplica de lectura en recibir datos del nodo del escritor. + El aumento de la carga en la réplica de lectura puede retrasar la transmisión de la solicitud de consulta desde la réplica de lectura hasta el nodo del escritor. + El aumento de la carga en el nodo del escritor puede retrasar la transmisión de los datos desde el nodo del escritor hasta la réplica de lectura. **Acciones** Recomendamos diferentes acciones en función de las causas del evento de espera. + Optimice las consultas para recuperar solo los datos necesarios. + Optimice las operaciones de lenguaje de manipulación de datos (DML) para modificar únicamente los datos necesarios. + Si la réplica de lectura o el nodo del escritor están limitados por la CPU o por el ancho de banda de la red, puede cambiarlo por un tipo de instancia con más capacidad de CPU o más ancho de banda. ### IPC:AuroraWriteForwardGetGlobalConsistencyPoint El evento `IPC:AuroraWriteForwardGetGlobalConsistencyPoint` se produce cuando un proceso de backend de la réplica de lectura que utiliza el modo de coherencia GLOBAL está esperando para obtener el punto de coherencia global del nodo del escritor antes de ejecutar una consulta. **Causas probables del aumento del tiempo de espera** Algunas de las causas más comunes que provocan tiempos de espera más largos son las siguientes: + El aumento de la latencia de la red entre la réplica de lectura y el nodo del escritor incrementa el tiempo que tarda la réplica de lectura en recibir datos del nodo del escritor. + El aumento de la carga en la réplica de lectura puede retrasar la transmisión de la solicitud de consulta desde la réplica de lectura hasta el nodo del escritor. + El aumento de la carga en el nodo del escritor puede retrasar la transmisión de los datos desde el nodo del escritor hasta la réplica de lectura. **Acciones** Recomendamos diferentes acciones en función de las causas del evento de espera. + Cambie el modo de coherencia según los requisitos de su aplicación. + Si la réplica de lectura o el nodo del escritor están limitados por la CPU o por el ancho de banda de la red, puede cambiarlo por un tipo de instancia con más capacidad de CPU o más ancho de banda. ### IPC:AuroraWriteForwardXactAbort El evento `IPC:AuroraWriteForwardXactAbort` se produce cuando un proceso de backend de la réplica de lectura está esperando el resultado de una consulta de limpieza remota. Las consultas de limpieza se emiten para devolver el proceso al estado correspondiente después de cancelar una transacción de reenvío de escritura. Amazon Aurora las ejecuta porque ha detectado un error o porque un usuario ha emitido un comando `ABORT` explícito o ha cancelado una consulta en ejecución. **Causas probables del aumento del tiempo de espera** Algunas de las causas más comunes que provocan tiempos de espera más largos son las siguientes: + El aumento de la latencia de la red entre la réplica de lectura y el nodo del escritor incrementa el tiempo que tarda la réplica de lectura en recibir datos del nodo del escritor. + El aumento de la carga en la réplica de lectura puede retrasar la transmisión de la solicitud de consulta de limpieza desde la réplica de lectura al nodo del escritor. + El aumento de la carga en el nodo del escritor puede retrasar la transmisión de los datos desde el nodo del escritor hasta la réplica de lectura. **Acciones** Recomendamos diferentes acciones en función de las causas del evento de espera. + Investigue por qué se ha cancelado la transacción. + Si la réplica de lectura o la instancia de base de datos del escritor están limitadas por la CPU o por el ancho de banda de la red, puede cambiarlo por un tipo de instancia con más capacidad de CPU o más ancho de banda. ### IPC:AuroraWriteForwardXactCommit El evento `IPC:AuroraWriteForwardXactCommit` se produce cuando un proceso de backend de la réplica de lectura está esperando el resultado de un comando de transacción de confirmación reenviado. **Causas probables del aumento del tiempo de espera** Algunas de las causas más comunes que provocan tiempos de espera más largos son las siguientes: + El aumento de la latencia de la red entre la réplica de lectura y el nodo del escritor incrementa el tiempo que tarda la réplica de lectura en recibir datos del nodo del escritor. + El aumento de la carga en la réplica de lectura puede retrasar la transmisión de la solicitud de consulta desde la réplica de lectura hasta el nodo del escritor. + El aumento de la carga en el nodo del escritor puede retrasar la transmisión de los datos desde el nodo del escritor hasta la réplica de lectura. **Acciones** Si la réplica de lectura o el nodo del escritor están limitados por la CPU o por el ancho de banda de la red, puede cambiarlo por un tipo de instancia con más capacidad de CPU o más ancho de banda. ### IPC:AuroraWriteForwardXactStart El evento `IPC:AuroraWriteForwardXactStart` se produce cuando un proceso de backend de la réplica de lectura está esperando el resultado de un comando de transacción de inicio reenviado. **Causas probables del aumento del tiempo de espera** Algunas de las causas más comunes que provocan tiempos de espera más largos son las siguientes: + El aumento de la latencia de la red entre la réplica de lectura y el nodo del escritor incrementa el tiempo que tarda la réplica de lectura en recibir datos del nodo del escritor. + El aumento de la carga en la réplica de lectura puede retrasar la transmisión de la solicitud de consulta desde la réplica de lectura hasta el nodo del escritor. + El aumento de la carga en el nodo del escritor puede retrasar la transmisión de los datos desde el nodo del escritor hasta la réplica de lectura. **Acciones** Si la réplica de lectura o el nodo del escritor están limitados por la CPU o por el ancho de banda de la red, puede cambiarlo por un tipo de instancia con más capacidad de CPU o más ancho de banda.