Utilisation du transfert d'écriture dans une base de données globale Aurora PostgreSQL

Régions et versions disponibles pour le transfert d'écriture dans Aurora PostgreSQL

Le transfert d'écriture est pris en charge par Aurora PostgreSQL 14.9 et 15.4 ainsi que leurs versions mineures ultérieures. Il est disponible dans toutes les régions où les bases de données globales Aurora PostgreSQL sont présentes.

Pour en savoir plus sur les régions et les versions disponibles des bases de données globales Aurora PostgreSQL, consultez Bases de données globales Aurora avec Aurora PostgreSQL.

Activation du transfert d'écriture dans Aurora PostgreSQL

Par défaut, le transfert d'écriture n'est pas activé lorsque vous ajoutez un cluster secondaire à une base de données globale Aurora. Vous pouvez l'activer pendant que vous créez votre cluster de base de données secondaire ou ultérieurement à tout moment. Si nécessaire, vous pouvez le désactiver plus tard. L'activation ou la désactivation du transfert d'écriture n'entraîne pas de temps d'arrêt ni de redémarrage.

Console

Dans la console, vous pouvez activer ou désactiver le transfert d'écriture lorsque vous créez ou modifiez un cluster de base de données secondaire.

Activation ou désactivation du transfert d'écriture lors de la création d'un cluster de base de données secondaire

Lorsque vous créez un cluster de base de données secondaire, activez le transfert d'écriture en cochant la case Activer le transfert d'écriture global sous Transfert d'écriture de réplica en lecture. Ou décochez la case pour le désactiver. Pour créer un cluster de base de données secondaire, suivez les instructions pour votre moteur de base de données dans Création d'un cluster de base de données Amazon Aurora.

La capture d'écran suivante montre la section Transfert d'écriture de réplica en lecture avec la case Activer le transfert d'écriture global cochée.

Activation ou désactivation du transfert d'écriture lors de la modification d'un cluster de base de données secondaire

Dans la console, vous pouvez modifier un cluster de base de données secondaire pour activer ou désactiver le transfert d'écriture.

Pour activer ou désactiver le transfert d'écriture sur un cluster de base de données secondaire à l'aide de la console

1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/.

2. Choisissez Databases (Bases de données).

3. Choisissez le cluster de base de données secondaire, puis Modifier.

4. Dans la section Transfert d'écriture de réplica en lecture, cochez ou décochez la case Activer le transfert d'écriture global.

5. Choisissez Continuer.

6. Pour Planification des modifications, choisissez Appliquer immédiatement. Si vous choisissez Au cours de la prochaine fenêtre de maintenance planifiée, Aurora ignore ce paramètre et active immédiatement le transfert d'écriture.

7. Choisissez Modifier le cluster.

AWS CLI

Pour activer le transfert d'écriture à l'aide de AWS CLI, utilisez l'--enable-global-write-forwardingoption. Cette option fonctionne lorsque vous créez un nouveau cluster secondaire à l'aide de la create-db-clustercommande. Cela fonctionne également lorsque vous modifiez un cluster secondaire existant à l'aide de la modify-db-clustercommande. Il nécessite que la base de données globale utilise une version d'Aurora qui prend en charge le transfert d'écriture. Vous pouvez désactiver le transfert d'écriture en utilisant l'option --no-enable-global-write-forwarding avec ces mêmes commandes CLI.

Les procédures suivantes expliquent comment activer ou désactiver le transfert d'écriture sur un cluster de base de données secondaire dans votre cluster global à l'aide d' AWS CLI.

Pour activer ou désactiver le transfert d'écriture d'un cluster de base de données secondaire

• Appelez la modify-db-cluster AWS CLI commande et entrez les valeurs suivantes :

  • --db-cluster-identifier : nom du cluster de base de données.

  • --enable-global-write-forwarding pour l'activer ou --no-enable-global-write-forwarding pour le désactiver.

  L'exemple suivant active le transfert d'écriture pour le cluster de base de données sample-secondary-db-cluster.

  Pour LinuxmacOS, ou Unix :

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

  Dans Windows :

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

API RDS

Pour activer le transfert d'écriture à l'aide de l'API Amazon RDS, définissez le paramètre EnableGlobalWriteForwarding sur true. Ce paramètre s'applique lorsque vous créez un cluster secondaire à l'aide de l'opération CreateDBCluster. Il s'applique également lorsque vous modifiez un cluster secondaire à l'aide de l'opération ModifyDBCluster. Il nécessite que la base de données globale utilise une version d'Aurora qui prend en charge le transfert d'écriture. Vous pouvez désactiver le transfert d'écriture en définissant le paramètre EnableGlobalWriteForwarding sur false.

Vérification de l'activation du transfert d'écriture dans un cluster secondaire dans Aurora PostgreSQL

Pour déterminer si vous pouvez utiliser le transfert d'écriture à partir d'un cluster secondaire, vous pouvez vérifier si le cluster possède l'attribut "GlobalWriteForwardingStatus": "enabled".

Dans le AWS Management Console, vous pouvez voir l'Read replica write forwardingonglet Configuration de la page de détails du cluster. Pour connaître l'état du paramètre global de transfert d'écriture pour tous vos clusters, exécutez la AWS CLI commande suivante.

Un cluster secondaire affiche la valeur "enabled" ou "disabled" pour indiquer si le transfert d'écriture est activé ou désactivé. La valeur null indique que le transfert d'écriture n'est pas disponible pour ce cluster. Soit le cluster ne fait pas partie d'une base de données globale, soit il s'agit du cluster principal et non d'un cluster secondaire. La valeur peut également être "enabling" ou "disabling" si le transfert d'écriture est en cours d'activation ou de désactivation.

Exemple

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"
    }
]

Pour rechercher uniquement les clusters secondaires pour lesquels le transfert d'écriture global est activé, exécutez la commande suivante. Cette commande renvoie également le point de terminaison du lecteur du cluster. Vous utilisez le point de terminaison du lecteur du cluster secondaire lorsque vous utilisez le transfert d'écriture du secondaire vers le principal dans votre base de données Aurora globale.

Exemple

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"
    }
]

Compatibilité des applications et de SQL avec le transfert d'écriture dans Aurora PostgreSQ

Utilisées dans une base de données globale avec transfert d'écriture, certaines instructions ne sont pas autorisées ou peuvent produire des résultats obsolètes. En outre, les fonctions définies par l'utilisateur et les procédures définies par l'utilisateur ne sont pas prises en charge. Par conséquent, le paramètre EnableGlobalWriteForwarding est désactivé par défaut pour les clusters secondaires. Avant de l'activer, vérifiez que votre code d'application n'est affecté par aucune de ces restrictions.

Vous pouvez utiliser les types d'instructions SQL suivants avec le transfert d'écriture :

• Instructions DML (Data Manipulation Language) comme INSERT, DELETE et UPDATE

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

• Instructions PREPARE et EXECUTE

• Instructions EXPLAIN comprenant les instructions de cette liste

Les types d'instructions SQL suivants ne sont pas pris en charge par le transfert d'écriture :

• Instructions DDL (Data Definition Language)

• ANALYZE

• CLUSTER

• COPY

• Curseurs : les curseurs ne sont pas pris en charge. Assurez-vous donc de les fermer avant d'utiliser le transfert d'écriture.

• GRANT|REVOKE|REASSIGN OWNED|SECURITY LABEL

• LOCK

• Instructions SAVEPOINT

• SELECT INTO

• SET CONSTRAINTS

• TRUNCATE

• VACUUM

Isolement et cohérence pour le transfert d'écriture dans Aurora PostgreSQL

Dans les sessions qui utilisent le transfert d'écriture, vous pouvez utiliser les niveaux d'isolement REPEATABLE READ et READ COMMITTED. En revanche, le niveau d'isolement SERIALIZABLE n'est pas pris en charge.

Vous pouvez contrôler le degré de cohérence en lecture sur un cluster secondaire. Le niveau de cohérence en lecture détermine la durée d'attente du cluster secondaire avant chaque opération de lecture, afin de s'assurer que certaines ou toutes les modifications sont répliquées à partir du cluster principal. Vous pouvez ajuster le niveau de cohérence en lecture pour vous assurer que toutes les opérations d'écriture transférées de votre session sont visibles dans le cluster secondaire avant toute requête ultérieure. Vous pouvez également utiliser ce paramètre pour vous assurer que les requêtes sur le cluster secondaire voient toujours les mises à jour les plus récentes du cluster principal. C'est le cas même pour celles soumises par d'autres sessions ou d'autres clusters. Pour spécifier ce type de comportement pour votre application, vous choisissez la valeur appropriée pour le paramètre de niveau session apg_write_forward.consistency_mode. Le paramètre apg_write_forward.consistency_mode n'a un effet que sur les clusters secondaires dans lesquels le transfert d'écriture est activé.

Note

Pour le paramètre apg_write_forward.consistency_mode, vous pouvez spécifier les valeurs SESSION, EVENTUAL, GLOBAL ou OFF. Par défaut, cette valeur indique SESSION. Le réglage de la valeur sur OFF désactive le transfert d'écriture dans la session.

Au fur et à mesure que vous augmentez le niveau de cohérence, votre application passe plus de temps à attendre que les modifications soient propagées entre les AWS régions. Vous pouvez choisir l'équilibre entre le temps de réponse rapide et l'assurance que les modifications apportées à d'autres emplacements sont entièrement disponibles avant l'exécution de vos requêtes.

Pour chaque paramètre de cohérence disponible, l'effet est le suivant :

• SESSION— Toutes les requêtes d'une AWS région secondaire qui utilise le transfert d'écriture voient les résultats de toutes les modifications apportées au cours de cette session. Les modifications sont visibles que la transaction soit validée ou non. Si nécessaire, la requête attend que les résultats des opérations d'écriture transférées soient répliqués dans la région actuelle. Elle n'attend pas les résultats mis à jour des opérations d'écriture effectuées dans d'autres régions ou dans d'autres sessions au sein de la région actuelle.

• EVENTUAL— Les requêtes d'une AWS région secondaire qui utilise le transfert d'écriture peuvent afficher des données légèrement périmées en raison du retard de réplication. Les résultats des opérations d'écriture dans la même session ne sont pas visibles tant que l'opération d'écriture n'est pas effectuée dans la région principale et répliquée dans la région actuelle. La requête n'attend pas que les résultats mis à jour soient disponibles. Ainsi, elle peut récupérer les données plus anciennes ou les données mises à jour, en fonction de l'heure des instructions et de la durée du décalage de réplication.

• GLOBAL— Une session dans une AWS région secondaire voit les modifications apportées par cette session. Il prend également en compte tous les changements engagés à la fois dans la AWS région principale et dans les autres AWS régions secondaires. Chaque requête peut attendre pendant une période qui varie en fonction du décalage de la session. La requête se poursuit lorsque le cluster secondaire up-to-date contient toutes les données validées du cluster principal, au moment où la requête a commencé.

• OFF : le transfert d'écriture est désactivé dans la session.

Pour de plus amples informations sur tous les paramètres impliqués dans le transfert d'écriture, veuillez consulter Paramètres de configuration pour le transfert d'écriture dans Aurora PostgreSQL.

Exécution d'instructions en plusieurs parties avec le transfert d'écriture dans Aurora PostgreSQL

Une instruction DML peut être composée de plusieurs parties, notamment une instruction INSERT ... SELECT ou une instruction DELETE ... WHERE. Dans ce cas, l'instruction entière est transférée vers le cluster principal pour y être exécutée.

Paramètres de configuration pour le transfert d'écriture dans Aurora PostgreSQL

Les groupes de paramètres de cluster Aurora incluent des paramètres pour la fonction de transfert d'écriture. Comme il s'agit de paramètres de cluster, toutes les instances de base de données de chaque cluster ont les mêmes valeurs pour ces variables. Les détails sur ces paramètres sont résumés dans le tableau suivant, avec des notes d'utilisation après le tableau.

Nom	Portée	Type	Valeur par défaut	Valeurs valides
apg_write_forward.connect_timeout	Session	secondes	30	0–2147483647
apg_write_forward.consistency_mode	Session	enum	Session	SESSION, EVENTUAL, GLOBAL, OFF
apg_write_forward.idle_in_transaction_session_timeout	Session	millisecondes	86400000	0–2147483647
apg_write_forward.idle_session_timeout	Session	millisecondes	300 000	0–2147483647
apg_write_forward.max_forwarding_connections_percent	Globale	int	25	1–100

Le paramètre apg_write_forward.max_forwarding_connections_percent est la limite supérieure des emplacements de connexion à la base de données qui peuvent être utilisés pour traiter les requêtes transmises par les lecteurs. Il est exprimé en pourcentage du paramètre max_connections de l'instance de base de données d'enregistreur dans le cluster principal. Par exemple, si la valeur de max_connections est 800 et celle de apg_write_forward.max_forwarding_connections_percent est 10, l'enregistreur autorise un maximum de 80 sessions transférées simultanées. Ces connexions proviennent du même groupe de connexions géré par le paramètre max_connections. Ce paramètre s'applique uniquement au cluster principal, lorsque le transfert d'écriture est activé dans au moins un cluster secondaire.

Utilisez les paramètres suivants sur le cluster secondaire :

• apg_write_forward.consistency_mode : paramètre de niveau session qui contrôle le degré de cohérence en lecture sur le cluster secondaire. Les valeurs valides sont SESSION, EVENTUAL, GLOBAL ou OFF. Par défaut, cette valeur indique SESSION. Le réglage de la valeur sur OFF désactive le transfert d'écriture dans la session. Pour en savoir plus sur les niveaux de cohérence, consultez Isolement et cohérence pour le transfert d'écriture dans Aurora PostgreSQL. Ce paramètre n'est pertinent que dans les instances de lecteur de clusters secondaires dont le transfert d'écriture est activé et qui se trouvent dans une base de données Aurora globale.

• apg_write_forward.connect_timeout : nombre maximal de secondes pendant lesquelles le cluster secondaire attend lors de l'établissement d'une connexion au cluster principal avant d'abandonner. Une valeur de 0 correspond à un temps d'attente indéfini.

• apg_write_forward.idle_in_transaction_session_timeout : nombre de millisecondes pendant lesquelles le cluster principal attend une activité sur une connexion transférée à partir d'un cluster secondaire ayant une transaction ouverte avant de la fermer. Si la session reste inactive au-delà de cette durée, Aurora y met fin. La valeur 0 désactive le délai d'attente.

• apg_write_forward.idle_session_timeout : nombre de millisecondes pendant lesquelles le cluster principal attend une activité sur une connexion transférée à partir d'un cluster secondaire avant de la fermer. Si la session reste inactive au-delà de cette durée, Aurora y met fin. La valeur 0 désactive le délai d'attente.

CloudWatch Métriques Amazon pour le transfert d'écriture dans Aurora PostgreSQL

Les CloudWatch métriques Amazon suivantes s'appliquent au cluster principal lorsque vous utilisez le transfert d'écriture sur un ou plusieurs clusters secondaires. Ces métriques sont toutes mesurées sur l'instance de base de données d'enregistreur dans le cluster principal.

CloudWatch Métrique	Unités et description
AuroraForwardingWriterDMLThroughput	Nombre (par seconde). Nombre d'instructions DML transférées traitées chaque seconde par cette instance de base de données d'enregistreur.
AuroraForwardingWriterOpenSessions	Nombre. Nombre de sessions ouvertes sur cette instance de base de données d'enregistreur traitant les requêtes transmises.
AuroraForwardingWriterTotalSessions	Nombre. Nombre total de sessions transférées sur cette instance de base de données d'enregistreur.

Les CloudWatch mesures suivantes s'appliquent à chaque cluster secondaire. Ces métriques sont mesurées sur chaque instance de base de données de lecteur dans un cluster secondaire avec le transfert d'écriture activé.

CloudWatch Métrique	Unité et description
AuroraForwardingReplicaCommitThroughput	Nombre (par seconde). Nombre d'engagements dans les sessions transmises chaque seconde par ce réplica.
AuroraForwardingReplicaDMLLatency	Millisecondes. Temps de réponse moyen en millisecondes des DML transférées sur le réplica.
AuroraForwardingReplicaDMLThroughput	Nombre (par seconde). Nombre d'instructions DML transférées que ce réplica traite chaque seconde.
AuroraForwardingReplicaErrorSessionsLimit	Nombre. Nombre de sessions rejetées par le cluster principal, car le nombre maximal de connexions ou de connexions de transfert d'écriture a été atteint.
AuroraForwardingReplicaOpenSessions	Nombre. Nombre de sessions qui utilisent le transfert d'écriture sur une instance de réplica.
AuroraForwardingReplicaReadWaitLatency	Millisecondes. Durée moyenne en millisecondes que le réplica attend pour être cohérent avec le LSN du cluster principal. Le temps d'attente de l'instance en lecture de la base de données dépend du paramètre apg_write_forward.consistency_mode. Pour plus d'informations sur ce paramètre, consultez Paramètres de configuration pour le transfert d'écriture dans Aurora PostgreSQL.

Événements d'attente pour le transfert d'écriture dans Aurora PostgreSQL

Amazon Aurora génère les événements d'attente suivants lorsque vous utilisez le transfert d'écriture avec Aurora PostgreSQL.

Rubriques

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

IPC : AuroraWriteForwardConnect

L'événement IPC:AuroraWriteForwardConnect se produit lorsqu'un processus de backend sur le cluster de base de données secondaire attend l'ouverture d'une connexion au nœud d'enregistreur du cluster de base de données principal.

Causes probables de l'allongement des temps d'attente

Cet événement augmente à mesure que le nombre de tentatives de connexion du nœud de lecteur d'une région secondaire au nœud d'enregistreur du cluster de base de données principal augmente.

Actions

Réduisez le nombre de connexions simultanées du nœud secondaire au nœud d'enregistreur de la région principale.

IPC : AuroraWriteForwardConsistencyPoint

L'événement IPC:AuroraWriteForwardConsistencyPoint décrit la durée pendant laquelle une requête d'un nœud du cluster de base de données secondaire attend la réplication des résultats des opérations d'écriture transférées dans la région actuelle. Cet événement n'est généré que si le paramètre de niveau session apg_write_forward.consistency_mode est défini sur l'une des valeurs suivantes :

• SESSION : les requêtes d'un nœud secondaire attendent les résultats de toutes les modifications apportées au cours de cette session.

• GLOBAL : les requêtes d'un nœud secondaire attendent les résultats des modifications apportées par cette session, ainsi que toutes les modifications validées de la région principale et des autres régions secondaires du cluster global.

Pour plus d'informations sur la configuration du paramètre apg_write_forward.consistency_mode, consultez Paramètres de configuration pour le transfert d'écriture dans Aurora PostgreSQL.

Causes probables de l'allongement des temps d'attente

Les causes fréquentes de l'allongement des temps d'attente sont les suivantes :

• Augmentation du délai de réplication, tel que mesuré par la CloudWatch ReplicaLag métrique Amazon. Pour plus d'informations sur cette métrique, consultez Surveillance de la réplication Aurora PostgreSQL.

• Charge accrue sur le nœud d'enregistreur de la région principale ou sur le nœud secondaire.

Actions

Modifiez votre mode de cohérence en fonction des besoins de votre application.

IPC : AuroraWriteForwardExecute

L'événement IPC:AuroraWriteForwardExecute se produit lorsqu'un processus backend sur le cluster de base de données secondaire attend qu'une requête transférée se termine et obtienne des résultats du nœud d'enregistreur du cluster de base de données principal.

Causes probables de l'allongement des temps d'attente

Les causes fréquentes de l'allongement des temps d'attente sont les suivantes :

• Un grand nombre de lignes est récupéré du nœud d'enregistreur de la région principale.

• Une augmentation de la latence du réseau entre le nœud secondaire et le nœud d'enregistreur de la région principale augmente le temps nécessaire au nœud secondaire pour recevoir les données du nœud d'enregistreur.

• Une augmentation de la charge sur le nœud secondaire peut retarder la transmission de la requête du nœud secondaire au nœud d'enregistreur de la région principale.

• Une augmentation de la charge sur le nœud d'enregistreur de la région principale peut retarder la transmission des données du nœud d'enregistreur au nœud secondaire.

Actions

Nous vous recommandons différentes actions en fonction des causes de votre événement d'attente.

• Optimisez les requêtes pour récupérer uniquement les données nécessaires.

• Optimisez les opérations DML (Data Manipulation Language) pour ne modifier que les données nécessaires.

• Si le nœud secondaire ou le nœud d'enregistreur de la région principale est limité par le processeur ou la bande passante du réseau, envisagez de le remplacer par un type d'instance doté d'une plus grande capacité de processeur ou de bande passante.

IPC : AuroraWriteForwardGetGlobalConsistencyPoint

L'événement IPC:AuroraWriteForwardGetGlobalConsistencyPoint se produit lorsqu'un processus backend sur le cluster de base de données secondaire qui utilise le mode de cohérence GLOBAL attend d'obtenir le point de cohérence global auprès du nœud d'enregistreur avant d'exécuter une requête.

Causes probables de l'allongement des temps d'attente

Les causes fréquentes de l'allongement des temps d'attente sont les suivantes :

• Une augmentation de la latence du réseau entre le nœud secondaire et le nœud d'enregistreur de la région principale augmente le temps nécessaire au nœud secondaire pour recevoir les données du nœud d'enregistreur.

• Une augmentation de la charge sur le nœud secondaire peut retarder la transmission de la requête du nœud secondaire au nœud d'enregistreur de la région principale.

• Une augmentation de la charge sur le nœud d'enregistreur de la région principale peut retarder la transmission des données du nœud d'enregistreur au nœud secondaire.

Actions

Nous vous recommandons différentes actions en fonction des causes de votre événement d'attente.

• Modifiez votre mode de cohérence en fonction des besoins de votre application.

• Si le nœud secondaire ou le nœud d'enregistreur de la région principale est limité par le processeur ou la bande passante du réseau, envisagez de le remplacer par un type d'instance doté d'une plus grande capacité de processeur ou de bande passante.

IPC : AuroraWriteForwardXactAbort

L'événement IPC:AuroraWriteForwardXactAbort se produit lorsqu'un processus backend sur le cluster de base de données secondaire attend le résultat d'une requête de nettoyage à distance. Des requêtes de nettoyage sont émises pour remettre le processus dans l'état approprié après l'abandon d'une transaction de transfert d'écriture. Amazon Aurora les exécute soit parce qu'une erreur a été détectée, soit parce qu'un utilisateur a émis une commande ABORT explicite ou annulé une requête en cours d'exécution.

Causes probables de l'allongement des temps d'attente

Les causes fréquentes de l'allongement des temps d'attente sont les suivantes :

• Une augmentation de la latence du réseau entre le nœud secondaire et le nœud d'enregistreur de la région principale augmente le temps nécessaire au nœud secondaire pour recevoir les données du nœud d'enregistreur.

• Une augmentation de la charge sur le nœud secondaire peut retarder la transmission de la requête du nœud secondaire au nœud d'enregistreur de la région principale.

• Une augmentation de la charge sur le nœud d'enregistreur de la région principale peut retarder la transmission des données du nœud d'enregistreur au nœud secondaire.

Actions

Nous vous recommandons différentes actions en fonction des causes de votre événement d'attente.

• Recherchez la cause de l'annulation de la transaction.

• Si le nœud secondaire ou le nœud d'enregistreur de la région principale est limité par le processeur ou la bande passante du réseau, envisagez de le remplacer par un type d'instance doté d'une plus grande capacité de processeur ou de bande passante.

IPC : AuroraWriteForwardXactCommit

L'événement IPC:AuroraWriteForwardXactCommit se produit lorsqu'un processus backend sur le cluster de base de données secondaire attend le résultat d'une commande commit transaction transférée.

Causes probables de l'allongement des temps d'attente

Les causes fréquentes de l'allongement des temps d'attente sont les suivantes :

• Une augmentation de la latence du réseau entre le nœud secondaire et le nœud d'enregistreur de la région principale augmente le temps nécessaire au nœud secondaire pour recevoir les données du nœud d'enregistreur.

• Une augmentation de la charge sur le nœud secondaire peut retarder la transmission de la requête du nœud secondaire au nœud d'enregistreur de la région principale.

• Une augmentation de la charge sur le nœud d'enregistreur de la région principale peut retarder la transmission des données du nœud d'enregistreur au nœud secondaire.

Actions

Si le nœud secondaire ou le nœud d'enregistreur de la région principale est limité par le processeur ou la bande passante du réseau, envisagez de le remplacer par un type d'instance doté d'une plus grande capacité de processeur ou de bande passante.

IPC : AuroraWriteForwardXactStart

L'événement IPC:AuroraWriteForwardXactStart se produit lorsqu'un processus backend sur le cluster de base de données secondaire attend le résultat d'une commande start transaction transférée.

Causes probables de l'allongement des temps d'attente

Les causes fréquentes de l'allongement des temps d'attente sont les suivantes :

• Une augmentation de la latence du réseau entre le nœud secondaire et le nœud d'enregistreur de la région principale augmente le temps nécessaire au nœud secondaire pour recevoir les données du nœud d'enregistreur.

• Une augmentation de la charge sur le nœud secondaire peut retarder la transmission de la requête du nœud secondaire au nœud d'enregistreur de la région principale.

• Une augmentation de la charge sur le nœud d'enregistreur de la région principale peut retarder la transmission des données du nœud d'enregistreur au nœud secondaire.

Actions

Si le nœud secondaire ou le nœud d'enregistreur de la région principale est limité par le processeur ou la bande passante du réseau, envisagez de le remplacer par un type d'instance doté d'une plus grande capacité de processeur ou de bande passante.