Uso del reenvío de escritura en una base de datos Aurora PostgreSQL global

Disponibilidad regional y de versiones del reenvío de escritura en Aurora PostgreSQL

El reenvío de escritura es compatible con Aurora PostgreSQL 15.4 y versiones secundarias superiores, y con la versión 14.9 y versiones secundarias superiores. El reenvío de escritura está disponible en todas las regiones en las que hay bases de datos Aurora basadas en PostgreSQL.

Para obtener más información acerca de la disponibilidad regional y de versiones de las bases de datos Aurora PostgreSQL globales, consulte Bases de datos globales de Aurora con Aurora PostgreSQL.

Habilitación del reenvío de escritura en Aurora PostgreSQL

De forma predeterminada, el reenvío de escritura no está habilitado cuando se agrega un clúster secundario a una base de datos global de Aurora. Puede habilitar el reenvío de escritura para un clúster de base de datos secundario al crearlo o en cualquier momento posterior. Si lo necesita, podrá desactivarlo más adelante. La activación o desactivación del reenvío de escritura no provoca tiempos de inactividad ni un reinicio.

Consola

En la consola, puede activar o desactivar el reenvío de escritura al crear o modificar un clúster secundario de base de datos.

Habilitar o deshabilitar el reenvío de escritura al crear un clúster de base de datos secundario

Al crear un nuevo clúster de base de datos secundario, el reenvío de escritura se activa seleccionando la casilla Turn on global write forwarding (Activar el reenvío de escritura global) en Read replica write forwarding (Reenvío de escritura de réplica de lectura. También puede quitar la marca de la casilla para desactivarla. Para crear un clúster de base de datos secundario, siga las instrucciones indicadas en Creación de un clúster de base de datos de Amazon Aurora para su motor de base de datos.

La siguiente captura de pantalla muestra la sección Read replica write forwarding (Reenvío de escritura de réplica de lectura) con la casilla Turn on global write forwarding (Activar el reenvío de escritura global) seleccionada.

Habilitar o desactivar el reenvío de escritura al modificar un clúster de base de datos secundario

En la consola, puede modificar un clúster de base de datos secundario para habilitar o desactivar el reenvío de escritura.

Habilitar o desactivar el reenvío de escritura para un clúster de base de datos secundario con la consola

1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

2. Seleccione Databases (Bases de datos).

3. Elija el clúster de base de datos secundario y elija Modify (Modificar).

4. En la sección Reenvío de escritura de réplica de lectura en la que aparece la casilla Turn on global write forwarding (Activar el reenvío de escritura global) seleccionada.

5. Elija Continuar.

6. En Schedule modifications (Programación de modificaciones), elija Apply immediately (Aplicar inmediatamente). Si elige Apply during the next scheduled maintenance window (Aplicar durante la próxima ventana de mantenimiento programada), Aurora ignora esta configuración y activa de inmediato el reenvío de escritura.

7. Elija Modify Cluster (Modificar clúster).

AWS CLI

Para habilitar el reenvío de escritura mediante AWS CLI, utilice la opción --enable-global-write-forwarding. Esta opción funciona cuando crea un nuevo clúster secundario mediante el comando create-db-cluster. También funciona cuando modifica un clúster secundario existente mediante el comando modify-db-cluster. Requiere que la base de datos global utilice una versión de Aurora que admita el reenvío de escritura. Puede deshabilitar el reenvío de escritura mediante la opción --no-enable-global-write-forwarding con estos mismos comandos de la CLI.

Los siguientes procedimientos describen cómo habilitar o deshabilitar el reenvío de escritura para un clúster de base de datos secundario de su clúster global mediante AWS CLI.

Habilitar o desactivar el reenvío de escritura para un clúster de base de datos secundario existente

• Llame al comando AWS CLI de modify-db-cluster y suministre los siguientes valores:

  • --db-cluster-identifier: el nombre del clúster de bases de datos.

  • --enable-global-write-forwarding para activar o --no-enable-global-write-forwarding para desactivar.

  El siguiente ejemplo habilita el reenvío de escritura para un clúster de base de datos sample-secondary-db-cluster.

  Para Linux, macOS o Unix:

  aws rds modify-db-cluster \
      --db-cluster-identifier sample-secondary-db-cluster \
      --enable-global-write-forwarding

  En Windows:

  aws rds modify-db-cluster ^
      --db-cluster-identifier sample-secondary-db-cluster ^
      --enable-global-write-forwarding

API de RDS

Para habilitar el reenvío de escritura mediante la API de Amazon RDS, establezca el parámetro EnableGlobalWriteForwarding en true. Este parámetro funciona cuando crea un nuevo clúster secundario mediante la operación CreateDBCluster. También funciona cuando modifica un clúster secundario existente mediante la operación ModifyDBCluster. Requiere que la base de datos global utilice una versión de Aurora que admita el reenvío de escritura. Puede deshabilitar el reenvío de escritura estableciendo el parámetro EnableGlobalWriteForwarding en false.

Comprobación de si un clúster secundario tiene habilitado el reenvío de escritura en Aurora PostgreSQL

Para determinar si puede utilizar el reenvío de escritura desde un clúster secundario, puede comprobar si el clúster tiene el atributo "GlobalWriteForwardingStatus": "enabled".

En la AWS Management Console, verá Read replica write forwarding en la pestaña Configuration (Configuración) de la página de detalles del clúster. Para ver el estado de la configuración de reenvío de escritura global de todos los clústeres, ejecute el siguiente comando de AWS CLI.

Un clúster secundario muestra el valor "enabled" o "disabled" para indicar si el reenvío de escritura está activado o desactivado. Un valor de null indica que el reenvío de escritura no está disponible para ese clúster. O el clúster no forma parte de una base de datos global o es el clúster principal en lugar de un clúster secundario. El valor también puede ser "enabling" o "disabling" si el reenvío de escritura está en proceso de ser activado o desactivado.

ejemplo

aws rds describe-db-clusters --query '*[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus}'
[
    {
        "GlobalWriteForwardingStatus": "enabled",
        "DBClusterIdentifier": "aurora-write-forwarding-test-replica-1"
    },
    {
        "GlobalWriteForwardingStatus": "disabled",
        "DBClusterIdentifier": "aurora-write-forwarding-test-replica-2"
    },
    {
        "GlobalWriteForwardingStatus": null,
        "DBClusterIdentifier": "non-global-cluster"
    }
]

Para buscar todos los clústeres secundarios que tienen habilitado el reenvío de escritura global, ejecute el siguiente comando. Este comando también devuelve el punto de enlace del lector del clúster. Utilice el punto de conexión del lector del clúster secundario para cuando se utiliza el reenvío de escritura desde el secundario al primario en la base de datos Aurora global.

ejemplo

aws rds describe-db-clusters --query 'DBClusters[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus,ReaderEndpoint:ReaderEndpoint} | [?GlobalWriteForwardingStatus == `enabled`]'
[
    {
        "GlobalWriteForwardingStatus": "enabled",
        "ReaderEndpoint": "aurora-write-forwarding-test-replica-1.cluster-ro-cnpexample.us-west-2.rds.amazonaws.com",
        "DBClusterIdentifier": "aurora-write-forwarding-test-replica-1"
    }
]

Compatibilidad de las aplicaciones con el reenvío de escritura en Aurora PostgreSQL

Algunas instrucciones no están permitidas o pueden producir resultados obsoletos cuando se utilizan en una base de datos global con reenvío de escritura. Además, no se admiten funciones ni procedimientos definidos por el usuario. Por ello, la configuración EnableGlobalWriteForwarding está desactivada de forma predeterminada para los clústeres secundarios. Antes de activarla, asegúrese de que el código de la aplicación no se vea afectado por ninguna de estas restricciones.

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 y UPDATE

• Instrucciones SELECT FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE }

• Instrucciones PREPARE y EXECUTE

• Instrucciones EXPLAIN con las instrucciones de esta lista

Los siguientes tipos de instrucciones SQL no son compatibles con el reenvío de escritura:

• Instrucciones en lenguaje de definición de datos (DDL)

• ANALYZE

• CLUSTER

• COPY

• Cursores: los cursores no son compatibles, así que debe asegurarse de cerrarlos antes de utilizar el reenvío de escritura.

• GRANT|REVOKE|REASSIGN OWNED|SECURITY LABEL

• LOCK

• Instrucciones SAVEPOINT

• SELECT INTO

• SET CONSTRAINTS

• TRUNCATE

• VACUUM

Aislamiento y coherencia del reenvío de escritura en Aurora PostgreSQL

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.

Puede controlar cuál es el grado de coherencia de lectura en un clúster secundario. El nivel de coherencia de lectura determina cuánto espera el clúster secundario antes de cada operación de lectura para garantizar que algunos de los cambios o todos los cambios se repliquen desde el clúster principal. 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 secundario antes de cualquier consulta posterior. También puede utilizar esta configuración para asegurarse de que las consultas del clúster secundario siempre vean las actualizaciones más recientes del clúster principal. 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 clústeres secundarios donde está habilitado el reenvío de escritura.

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 desactiva el reenvío de escritura en la sesión.

A medida que aumenta el nivel de coherencia, la aplicación pasa más tiempo esperando que los cambios se propaguen entre las regiones de AWS. Puede buscar el equilibrio entre un tiempo de respuesta rápido 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: todas las consultas de una región secundaria de AWS que utiliza el reenvío de escritura verán 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 región actual. No espera a que se actualicen los resultados de las operaciones de escritura realizadas en otras regiones o en otras sesiones dentro de la región actual.

• EVENTUAL: las consultas en una región secundaria de AWS que utiliza el reenvío de escritura pueden ver datos ligeramente obsoletos debido al retardo de reproducción. Los resultados de las operaciones de escritura de la misma sesión no son visibles hasta que la operación de escritura se realiza en la región principal y se replica en la región actual. 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 región secundaria de AWS puede ver los cambios realizados por esa sesión. También puede ver todos los cambios confirmados tanto de la región principal de AWS como de otras regiones secundarias de AWS. 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 secundario está actualizado con todos los datos confirmados del clúster principal, a partir del momento en que comenzó la consulta.

• OFF: el reenvío de escritura está desactivado en la sesión.

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

Ejecutar instrucciones multiparte con reenvío de escritura en Aurora PostgreSQL

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 al clúster principal y se ejecuta allí.

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

Los grupos de parámetros del clúster de Aurora contienen nuevos ajustes para la característica de reenvío de escritura. 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.

Nombre	Ámbito	Tipo	Valor predeterminado	Valores válidos
apg_write_forward.connect_timeout	Sesión	segundos	30	0–2147483647
apg_write_forward.consistency_mode	Session	enum	Sesión	SESSION, EVENTUAL, GLOBAL, OFF
apg_write_forward.idle_in_transaction_session_timeout	Sesión	milisegundos	86400000	0–2147483647
apg_write_forward.idle_session_timeout	Sesión	milisegundos	300000	0–2147483647
apg_write_forward.max_forwarding_connections_percent	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 de escritor en el clúster principal. 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 en el clúster principal, cuando al menos uno de los clústeres secundarios tiene habilitado el reenvío de escritura.

Utilice la siguiente configuración en el clúster secundario:

• apg_write_forward.consistency_mode: un parámetro de nivel de sesión que controla el grado de coherencia de lectura en el clúster secundario. Los valores válidos son SESSION, EVENTUAL, GLOBAL o OFF. De forma predeterminada, el valor se establece en SESSION. Si se establece este valor en OFF, se desactiva el reenvío de escritura en la sesión. Para obtener más información sobre los niveles de consistencia, consulte Aislamiento y coherencia del reenvío de escritura en Aurora PostgreSQL. Este parámetro solo es relevante en instancias de lector de clústeres secundarios que tienen habilitado el reenvío de escritura y que se encuentran en una base de datos global de Aurora.

• apg_write_forward.connect_timeout: el número máximo de segundos que espera el clúster secundario al establecer una conexión con el clúster principal antes de desistirse. Un valor de 0 significa esperar indefinidamente.

• apg_write_forward.idle_in_transaction_session_timeout: la cantidad de milisegundos que el clúster principal espera actividad en una conexión que se reenvía desde un clúster secundario 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: la cantidad de milisegundos que el clúster principal espera actividad en una conexión que se reenvía desde un clúster secundario 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.

Métricas de Amazon CloudWatch para el reenvío de escritura en Aurora PostgreSQL

Las siguientes métricas de Amazon CloudWatch se aplican al clúster principal cuando se utiliza el reenvío de escritura en uno o más clústeres secundarios. Todas estas métricas se miden en la instancia de base de datos de escritor del clúster principal.

Métrica de CloudWatch	Unidades y descripción
AuroraForwardingWriterDMLThroughput	Recuento por segundo Número de instrucciones DML reenviadas procesadas cada segundo por esta instancia de base de datos de escritor.
AuroraForwardingWriterOpenSessions	Recuento Número de sesiones abiertas en esta instancia de base de datos de escritor que procesa las consultas reenviadas.
AuroraForwardingWriterTotalSessions	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 clúster secundario. Estas métricas se miden en cada instancia de base de datos de lector de un clúster secundario con reenvío de escritura 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 el clúster primario 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.
AuroraForwardingReplicaReadWaitLatency	Milisegundos. Tiempo de espera medio en milisegundos que la réplica espera para ser coherente con el LSN del clúster principal. El grado en que la instancia de base de datos de lector espera depende de la configuración apg_write_forward.consistency_mode. Para obtener información sobre esta configuración, consulte Parámetros de configuración para el reenvío de escritura en Aurora PostgreSQL.

Eventos de espera para el reenvío de escritura en Aurora PostgreSQL

Amazon Aurora genera los siguientes eventos de espera cuando utiliza el reenvío de escritura con Aurora PostgreSQL.

Temas

• IPC:AuroraWriteForwardConnect
• IPC:AuroraWriteForwardConsistencyPoint
• IPC:AuroraWriteForwardExecute
• IPC:AuroraWriteForwardGetGlobalConsistencyPoint
• IPC:AuroraWriteForwardXactAbort
• IPC:AuroraWriteForwardXactCommit
• IPC:AuroraWriteForwardXactStart

IPC:AuroraWriteForwardConnect

El evento IPC:AuroraWriteForwardConnect se produce cuando un proceso de backend del cluster de base de datos secundario espera a que se abra una conexión con el nodo escritor del cluster de base de datos primario.

Causas probables del aumento del tiempo de espera

Este evento aumenta a medida que aumenta el número de intentos de conexión desde el nodo lector de una región secundaria al nodo escritor del clúster de base de datos principal.

Acciones

Reduzca el número de conexiones simultáneas desde un nodo secundario al nodo escritor de la región principal.

IPC:AuroraWriteForwardConsistencyPoint

El evento IPC:AuroraWriteForwardConsistencyPoint describe cuánto tiempo esperará una consulta de un nodo del clúster de base de datos secundario 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 un nodo secundario esperan los resultados de todos los cambios realizados en esa sesión.

• GLOBAL: las consultas de un nodo secundario esperan los resultados de los cambios realizados en esa sesión, además de todos los cambios confirmados tanto de la región principal como de otras regiones secundarias del clúster global.

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.

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.

• Aumento de la carga en el nodo de escritor de la región principal o en el nodo secundario.

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 del cluster de base de datos secundario está esperando a que una consulta reenviada se complete y se obtengan los resultados del nodo escritor del cluster de base de datos primario.

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 escritor de la región principal.

• El aumento de la latencia de la red entre el nodo secundario y el nodo escritor de la región principal incrementa el tiempo que tarda el nodo secundario en recibir datos del nodo escritor.

• El aumento de la carga en el nodo secundario puede retrasar la transmisión de la solicitud de consulta desde el nodo secundario al nodo escritor de la región principal.

• El aumento de la carga en el nodo escritor de la región principal puede retrasar la transmisión de la solicitud de consulta desde el nodo escritor al nodo secundario.

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 el nodo escritor de la región principal o el nodo secundario está limitado 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 IPC:AuroraWriteForwardGetGlobalConsistencyPoint evento se produce cuando un proceso de backend del clúster de base de datos secundario que utiliza el modo de coherencia GLOBAL está esperando para obtener el punto de coherencia global del nodo 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 el nodo secundario y el nodo escritor de la región principal incrementa el tiempo que tarda el nodo secundario en recibir datos del nodo escritor.

• El aumento de la carga en el nodo secundario puede retrasar la transmisión de la solicitud de consulta desde el nodo secundario al nodo escritor de la región principal.

• El aumento de la carga en el nodo escritor de la región principal puede retrasar la transmisión de la solicitud de consulta desde el nodo escritor al nodo secundario.

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 el nodo escritor de la región principal o el nodo secundario está limitado 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 del clúster de base de datos secundario 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 el nodo secundario y el nodo escritor de la región principal incrementa el tiempo que tarda el nodo secundario en recibir datos del nodo escritor.

• El aumento de la carga en el nodo secundario puede retrasar la transmisión de la solicitud de consulta de limpieza desde el nodo secundario al nodo escritor de la región principal.

• El aumento de la carga en el nodo escritor de la región principal puede retrasar la transmisión de la solicitud de consulta desde el nodo escritor al nodo secundario.

Acciones

Recomendamos diferentes acciones en función de las causas del evento de espera.

• Investigue por qué se ha cancelado la transacción.

• Si el nodo escritor de la región principal o el nodo secundario está limitado 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 del clúster de base de datos secundario 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 el nodo secundario y el nodo escritor de la región principal incrementa el tiempo que tarda el nodo secundario en recibir datos del nodo escritor.

• El aumento de la carga en el nodo secundario puede retrasar la transmisión de la solicitud de consulta desde el nodo secundario al nodo escritor de la región principal.

• El aumento de la carga en el nodo escritor de la región principal puede retrasar la transmisión de la solicitud de consulta desde el nodo escritor al nodo secundario.

Acciones

Si el nodo escritor de la región principal o el nodo secundario está limitado 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 del clúster de base de datos secundario 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 el nodo secundario y el nodo escritor de la región principal incrementa el tiempo que tarda el nodo secundario en recibir datos del nodo escritor.

• El aumento de la carga en el nodo secundario puede retrasar la transmisión de la solicitud de consulta desde el nodo secundario al nodo escritor de la región principal.

• El aumento de la carga en el nodo escritor de la región principal puede retrasar la transmisión de la solicitud de consulta desde el nodo escritor al nodo secundario.

Acciones

Si el nodo escritor de la región principal o el nodo secundario está limitado 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.