Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Transfert d’écriture local dans Aurora PostgreSQL
Le *transfert d’écriture local (intracluster)* permet à vos applications d’émettre des transactions de lecture/écriture directement sur un réplica Aurora. Les commandes d’écriture sont ensuite transférées à l’instance de base de données d’enregistreur pour être validées. Vous pouvez utiliser le transfert d’écriture local pour les applications qui font l’objet d’écritures occasionnelles et qui nécessitent une *cohérence de lecture après écriture*, ce qui permet de lire la dernière écriture dans une transaction.
Sans transfert d’écritures, vos applications doivent diviser entièrement l’ensemble du trafic de lecture et d’écriture, en conservant deux ensembles de connexions à la base de données pour envoyer le trafic au point de terminaison approprié. Les réplicas en lecture reçoivent les mises à jour de manière asynchrone de la part de l’instance d’enregistreur. De plus, comme le retard de réplication peut différer entre les réplicas en lecture, il est difficile d’obtenir une cohérence de lecture globale entre tous les réplicas. Vous devez traiter toutes les lectures qui nécessitent une cohérence de lecture après écriture sur l’instance de base de données d’enregistreur. Sinon, vous devez développer une logique d’application personnalisée complexe permettant de tirer parti de plusieurs réplicas en lecture pour assurer la capacité de mise à l’échelle tout en garantissant la cohérence.
Avec le transfert d’écriture, vous évitez d’avoir à diviser ces transactions ou d’avoir à les envoyer exclusivement à l’instance d’enregistreur. Vous n’avez pas non plus à développer une logique d’application complexe pour assure une cohérence de *lecture après écriture*.
Le transfert d’écriture local est disponible dans toutes les régions où Aurora PostgreSQL est proposé. Il est pris en charge par les versions Aurora PostgreSQL suivantes :
+ 16.4 et versions 16 ultérieures
+ 15.8 et versions 15 ultérieures
+ 14.13 et versions 14 ultérieures
Le transfert d’écriture local est utilisé pour transférer les écritures provenant des réplicas qui se trouvent dans la même région. Pour transférer des écritures à partir d’un réplica global, consultez [Utilisation du transfert d'écriture dans une base de données globale Amazon Aurora](aurora-global-database-write-forwarding.md).
**Topics**
+ [Limites et considérations relatives au transfert d’écriture local dans Aurora PostgreSQL](aurora-postgresql-write-forwarding-limitations.md)
+ [Configuration d’Aurora PostgreSQL pour le transfert d’écriture local](aurora-postgresql-write-forwarding-configuring.md)
+ [Utilisation du transfert d’écriture local pour Aurora PostgreSQL](aurora-postgresql-write-forwarding-understanding.md)
+ [Surveillance du transfert d’écriture local dans Aurora PostgreSQL](aurora-postgresql-write-forwarding-monitoring.md)
# Limites et considérations relatives au transfert d’écriture local dans Aurora PostgreSQL
Les limites suivantes s’appliquent actuellement au transfert d’écriture local dans Aurora PostgreSQL.
+ Le transfert d’écriture local n’est pas pris en charge avec le proxy RDS.
+ Certaines instructions ne sont pas autorisées ou peuvent produire des résultats obsolètes lorsque vous les utilisez dans Aurora PostgreSQL avec transfert d’écriture. En outre, les fonctions et les procédures définies par l’utilisateur ne sont pas prises en charge. Par conséquent, le paramètre `EnableLocalWriteForwarding` est désactivé par défaut pour les clusters de bases de données. Avant de l’activer, vérifiez que votre code d’application n’est affecté par aucune de ces restrictions.
+ Les types d’instructions SQL suivants ne sont pas pris en charge par le transfert d’écriture :
**Note**
Ces instructions peuvent être utilisées implicitement par vous-même dans votre application ou peuvent être déduites par le protocole PostgreSQL. Par exemple, la gestion des exceptions PL/SQL peut entraîner l’utilisation de SAVEPOINT, qui n’est pas une instruction prise en charge.
+ `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 local.
+ Instructions DDL (Data Definition Language)
+ `GRANT`\$1`REVOKE`\$1`REASSIGN OWNED`\$1`SECURITY LABEL`
+ `LISTEN / NOTIFY`
+ `LOCK`
+ `SAVEPOINT`
+ `SELECT INTO`
+ `SET CONSTRAINTS`
+ Mises à jour des séquences : `nextval()`, `setval()`
+ `TRUNCATE`
+ Commandes de validation en deux phases : `PREPARE TRANSACTION`, `COMMIT PREPARED`, `ROLLBACK PREPARED`
+ Fonctions et procédures définies par l’utilisateur.
+ `VACUUM`
Envisagez d’utiliser les types d’instructions SQL suivants avec le transfert d’écriture :
+ Une instruction DML peut être composée de plusieurs parties, notamment d’une instruction `INSERT ... SELECT` et d’une instruction `DELETE ... WHERE`. Dans ce cas, l’instruction entière est transférée vers l’instance de base de données d’enregistreur pour y être exécutée.
+ Instructions DML (Data Manipulation Language) comme `INSERT`, `DELETE` et `UPDATE`.
+ Instructions `EXPLAIN` comprenant les instructions de cette liste
+ Instructions `PREPARE` et `EXECUTE`.
+ Instructions `SELECT FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE }`
# Configuration d’Aurora PostgreSQL pour le transfert d’écriture local
À l’aide des sections suivantes, vous pouvez activer le transfert d’écriture local pour votre cluster de bases de données Amazon Aurora PostgreSQL, configurer les niveaux de cohérence et gérer les transactions avec le transfert d’écriture.
## Activation du transfert d’écriture local
Par défaut, le transfert d’écriture local n’est pas activé pour les clusters de bases de données Aurora PostgreSQL. Vous activez le transfert d’écriture local au niveau du cluster, et non au niveau de l’instance.
### Console
À l’aide de la AWS Management Console, cochez la case **Activer le transfert d’écriture local** sous **Transfert d’écriture de réplica en lecture** lorsque vous créez ou modifiez un cluster de bases de données.
### AWS CLI
Pour activer le transfert d’écriture local à l’aide de l’interface AWS CLI, utilisez l’option `--enable-local-write-forwarding`. Cette option est utile lorsque vous créez un nouveau cluster de bases de données à l’aide de la commande `create-db-cluster`. Elle est également utile lorsque vous modifiez un cluster de bases de données existant à l’aide de la commande `modify-db-cluster`. Vous pouvez désactiver le transfert d’écriture local en utilisant l’option `--no-enable-local-write-forwarding` avec ces mêmes commandes CLI.
L’exemple suivant crée un cluster de bases de données Aurora PostgreSQL avec le transfert d’écriture local activé.
```
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
```
Vous créez ensuite des instances de base de données d’enregistreur et de lecteur afin de pouvoir utiliser le transfert d’écriture. Pour plus d’informations, consultez [Création d’un cluster de bases de données Amazon Aurora](Aurora.CreateInstance.md).
### API RDS
Pour activer le transfert d’écriture local à l’aide de l’API Amazon RDS, définissez le paramètre `EnableLocalWriteForwarding` sur `true`. Ce paramètre agit lorsque vous créez un nouveau cluster de bases de données à l’aide de l’opération `CreateDBCluster`. Il agit également lorsque vous modifiez un cluster de bases de données existant à l’aide de l’opération `ModifyDBCluster`. Vous pouvez désactiver le transfert d’écriture local en définissant le paramètre `EnableLocalWriteForwarding` sur `false`.
### Activation du transfert d’écriture local pour les sessions de base de données
Le paramètre `apg_write_forward.consistency_mode` est un paramètre de base de données et un paramètre de cluster de bases de données qui permet le transfert d’écriture. Vous pouvez spécifier `SESSION`, `EVENTUAL`, `GLOBAL` ou `OFF` pour le niveau de cohérence de lecture. Pour en savoir plus sur les niveaux de cohérence, consultez la section [Cohérence et isolement pour le transfert d’écriture local dans Aurora PostgreSQL](#aurora-postgresql-write-forwarding-isolation).
Les règles suivantes s’appliquent à ce paramètre :
+ La valeur par défaut est `SESSION`.
+ Le transfert d’écriture local est disponible seulement si vous définissez `apg_write_forward.consistency_mode` sur `EVENTUAL`, `SESSION` ou `GLOBAL`. Ce paramètre n’est pertinent que dans les instances de lecteur des clusters de bases de données où le transfert d’écriture local est activé.
+ Le réglage de la valeur sur `OFF` désactive le transfert d’écriture local dans la session.
## Cohérence et isolement pour le transfert d’écriture local dans Aurora PostgreSQL
Vous pouvez contrôler le degré de cohérence de lecture sur un réplica en lecture. 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 réplica en lecture avant toute requête ultérieure. Vous pouvez également utiliser ce paramètre pour vous assurer que les requêtes sur le réplica en lecture voient toujours les mises à jour les plus récentes de l’instance de base de données de l’enregistreur. 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 d’effet que sur les réplicas secondaires dans lesquels le transfert d’écriture local 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.
À mesure que vous augmentez le niveau de cohérence, votre application passe plus de temps à attendre que les modifications soient propagées entre les réplicas en lecture. Vous pouvez choisir l’équilibre entre une faible latence et l’assurance que les modifications apportées à d’autres emplacements seront 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` : une session sur un réplica en lecture qui utilise le transfert d’écriture local voit 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 l’instance de base de données de lecteur actuelle. Elle n’attend pas les résultats mis à jour des opérations d’écriture effectuées dans d’autres sessions au sein du cluster de bases de données actuel.
+ `EVENTUAL` : une session sur un réplica en lecture qui utilise le transfert d’écriture local peut voir des données légèrement obsolètes en raison d’un 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 sur l’instance de base de données d’enregistreur et répliquée vers le réplica en lecture. 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 sur un réplica en lecture voit les modifications apportées par cette session. Elle voit également toutes les modifications validées à partir de l’instance de base de données de l’enregistreur et des autres réplicas en lecture. 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 réplica en lecture est à jour avec toutes les données validées de l’instance de base de données de l’enregistreur, à compter du début de la requête.
**Note**
Le mode de cohérence globale a un impact sur la latence des requêtes exécutées au cours d’une session. Il applique un délai d’attente même lorsque la session n’a envoyé aucune requête d’écriture.
+ `OFF` : le transfert d’écriture local est désactivé.
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.
Pour plus d’informations sur tous les paramètres impliqués dans le transfert d’écriture, consultez [Paramètres par défaut pour le transfert d’écriture](aurora-postgresql-write-forwarding-understanding.md#aurora-postgresql-write-forwarding-params).
## Modes d’accès aux transactions avec transfert d’écriture
Si le mode d’accès aux transactions est réglé sur lecture seule, le transfert d’écriture local n’est pas utilisé. Vous pouvez définir le mode d’accès en lecture et en écriture seules lorsque vous êtes connecté à un cluster de bases de données pour lequel le transfert d’écriture local est activé.
Pour plus d’informations sur les modes d’accès aux transactions, consultez [SET TRANSACTION](https://www.postgresql.org/docs/current/sql-set-transaction.html).
# Utilisation du transfert d’écriture local pour Aurora PostgreSQL
Reportez-vous aux sections suivantes pour vérifier si le transfert d’écriture local est activé dans un cluster de bases de données, pour consulter les considérations en matière de compatibilité et pour découvrir les paramètres configurables et la configuration de l’authentification. Ces informations vous fourniront les détails nécessaires pour utiliser efficacement la fonctionnalité de transfert d’écriture local d’Aurora PostgreSQL.
**Note**
Lorsqu’une instance d’enregistreur dans un cluster utilisant le transfert d’écriture local est redémarrée, toutes les transactions et requêtes actives et transférées sur les instances de lecteur utilisant le transfert d’écriture local sont automatiquement fermées. Une fois que l’instance d’enregistreur est à nouveau disponible, vous pouvez réessayer ces transactions.
## Vérification de l’activation du transfert d’écriture local dans un cluster de bases de données
Pour déterminer si vous pouvez utiliser le transfert d’écriture local dans un cluster de bases de données, vérifiez que l’attribut `LocalWriteForwardingStatus` du cluster est défini sur `enabled`.
Dans la AWS Management Console, dans l’onglet **Configuration** de la page de détails du cluster, vous pouvez voir l’état **Activé** pour **Transfert local d’écriture de réplica en lecture**.
Pour voir l’état du paramètre de transfert d’écriture local pour tous vos clusters, exécutez la commande AWS CLI suivante.
**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 cluster de bases de données peut avoir les valeurs suivantes pour `LocalWriteForwardingStatus` :
+ `disabled` : le transfert d’écriture local est désactivé.
+ `disabling` : le transfert d’écriture local est en cours de désactivation.
+ `enabled` : le transfert d’écriture local est activé.
+ `enabling` : le transfert d’écriture local est en cours d’activation.
+ `null` : le transfert d’écriture local n’est pas disponible pour ce cluster de bases de données.
+ `requested` : le transfert d’écriture local a été demandé, mais n’est pas encore actif.
## Paramètres par défaut pour le transfert d’écriture
Les groupes de paramètres de cluster Aurora incluent des paramètres pour la fonctionnalité de transfert d’écriture local. 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.
| Paramètre | Portée | Type | Valeur par défaut | Valeurs valides |
| --- | --- | --- | --- | --- |
| apg\$1write\$1forward.connect\$1timeout | Session | secondes | 30 | 0–2147483647 |
| apg\$1write\$1forward.consistency\$1mode | Session | enum | Session | SESSION, EVENTUAL, GLOBAL, et OFF |
| apg\$1write\$1forward.idle\$1in\$1transaction\$1session\$1timeout | Session | millisecondes | 86400000 | 0–2147483647 |
| apg\$1write\$1forward.idle\$1session\$1timeout | Session | millisecondes | 300000 | 0–2147483647 |
| apg\$1write\$1forward.max\$1forwarding\$1connections\$1percent | 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. 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 à l’instance de base de données d’enregistreur quand le transfert d’écriture local est activé sur le cluster.
Utilisez les paramètres suivants pour contrôler les demandes de transfert d’écriture local :
+ `apg_write_forward.consistency_mode` : paramètre de niveau session qui contrôle le degré de cohérence en lecture sur le réplica en lecture. 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 local dans la session. Pour en savoir plus sur les niveaux de cohérence, consultez la section [Cohérence et isolement pour le transfert d’écriture local dans Aurora PostgreSQL](aurora-postgresql-write-forwarding-configuring.md#aurora-postgresql-write-forwarding-isolation). Ce paramètre n’est pertinent que dans les instances de lecteur où le transfert d’écriture local est activé.
+ `apg_write_forward.connect_timeout` : nombre maximal de secondes pendant lesquelles le réplica en lecture attend lors de l’établissement d’une connexion à l’instance de base de données d’enregistreur 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 l’instance de base de données d’enregistreur attend une activité sur une connexion transférée depuis un réplica en lecture ayant une transaction en cours avant de le 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 l’instance de base de données d’enregistreur attend une activité sur une connexion transférée depuis un réplica en lecture avant de le 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.
## rdswriteforwarduser
`rdswriteforwarduser` est l’utilisateur qui nous permettra d’établir une connexion entre le réplica en lecture et l’instance de base de données d’enregistreur.
**Note**
`rdswriteforwarduser` héritera de ses privilèges CONNECT pour les bases de données clients via le rôle PUBLIC. Si les privilèges du rôle PUBLIC sont révoqués, vous devrez octroyer des privilèges GRANT CONNECT pour les bases de données vers lesquelles vous devez transférer les écritures.
# Surveillance du transfert d’écriture local dans Aurora PostgreSQL
À l'aide des sections suivantes, vous pouvez surveiller le transfert d'écriture local dans les clusters Aurora PostgreSQL, notamment les métriques CloudWatch pertinentes et les événements d'attente pour suivre les performances et identifier les problèmes potentiels.
## Amazon CloudWatch Metrics et variables d'état Aurora PostgreSQL pour le transfert d'écriture
Les CloudWatch métriques Amazon suivantes s'appliquent aux instances de base de données Writer lorsque vous utilisez le transfert d'écriture sur une ou plusieurs répliques de lecture.
| CloudWatch Métrique | Unités et description |
| --- | --- |
| `AuroraLocalForwardingWriterDMLThroughput` | Nombre (par seconde). Nombre d’instructions DML transférées traitées chaque seconde par cette instance de base de données d’enregistreur. |
| `AuroraLocalForwardingWriterOpenSessions` | Nombre. Nombre de sessions ouvertes sur cette instance de base de données d’enregistreur traitant les requêtes transmises. |
| `AuroraLocalForwardingWriterTotalSessions` | 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 réplique lue. Ces métriques sont mesurées sur chaque instance de base de données de lecteur dans un cluster de bases de données où le transfert d’écriture est 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 après le transfert lors de la réplication. DMLs |
| `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 l’instance de base de données de l’enregistreur, 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 local 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 de l’instance de base de données de l’enregistreur. Le temps d’attente de l’instance de base de données de lecteur dépend du paramètre apg\$1write\$1forward.consistency\$1mode. Pour plus d’informations sur ce paramètre, consultez [Paramètres de configuration pour le transfert d’écriture dans Aurora PostgreSQL](aurora-global-database-write-forwarding-apg.md#aurora-global-database-write-forwarding-params-apg). |
## Événements d’attente pour le transfert d’écriture local dans Aurora PostgreSQL
Amazon Aurora génère les événements d’attente suivants lorsque vous utilisez le transfert d’écriture avec 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
L’événement `IPC:AuroraWriteForwardConnect` se produit lorsqu’un processus dorsal sur le réplica en lecture attend l’ouverture d’une connexion à l’instance de base de données d’enregistreur.
**Causes probables de l’augmentation du nombre d’événements d’attente**
Cet événement augmente à mesure que le nombre de tentatives de connexion du réplica en lecture au nœud d’enregistreur augmente.
**Actions**
Réduisez le nombre de connexions simultanées du réplica en lecture au nœud d’enregistreur.
### IPC : AuroraWriteForwardConsistencyPoint
L’événement `IPC:AuroraWriteForwardConsistencyPoint` décrit la durée pendant laquelle une requête d’un nœud du réplica en lecture 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 réplica en lecture attendent les résultats de toutes les modifications apportées au cours de cette session.
+ `GLOBAL` : les requêtes d’un réplica en lecture attendent les résultats des modifications apportées par cette session, ainsi que toutes les modifications validées de l’instance de base de données d’enregistreur et du réplica en lecture.
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](aurora-global-database-write-forwarding-apg.md#aurora-global-database-write-forwarding-params-apg).
**Causes probables de l’augmentation du nombre d’événements 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](AuroraPostgreSQL.Replication.md#AuroraPostgreSQL.Replication.Monitoring).
+ Charge accrue sur l’instance de base de données d’enregistreur ou sur le réplica en lecture.
**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 dorsal sur le réplica en lecture attend qu’une requête transférée se termine et obtienne des résultats du nœud d’enregistreur du cluster de bases de données.
**Causes probables de l’augmentation du nombre d’événements d’attente**
Les causes fréquentes de l’augmentation du nombre d’événements d’attente sont les suivantes :
+ Un grand nombre de lignes est récupéré à partir du nœud d’enregistreur.
+ Une augmentation de la latence du réseau entre le nœud d’enregistreur de et le réplica en lecture augmente le temps nécessaire au réplica en lecture pour recevoir les données du nœud d’enregistreur.
+ Une augmentation de la charge sur le réplica en lecture peut retarder la transmission de la demande de la requête entre le réplica en lecture et le nœud d’enregistreur.
+ Une augmentation de la charge sur le nœud d’enregistreur peut retarder la transmission des données entre le nœud d’enregistreur et le 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 réplica en lecture ou le nœud d’enregistreur 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 dorsal sur le réplica en lecture 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’augmentation du nombre d’événements d’attente**
Les causes fréquentes de l’augmentation du nombre d’événements d’attente sont les suivantes :
+ Une augmentation de la latence du réseau entre le réplica en lecture et le nœud d’enregistreur augmente le temps nécessaire au réplica en lecture pour recevoir les données du nœud d’enregistreur.
+ Une augmentation de la charge sur le réplica en lecture peut retarder la transmission de la demande de la requête entre le réplica en lecture et le nœud d’enregistreur.
+ Une augmentation de la charge sur le nœud d’enregistreur peut retarder la transmission des données entre le nœud d’enregistreur et le 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 réplica en lecture ou le nœud d’enregistreur 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 dorsal sur le réplica en lecture 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’augmentation du nombre d’événements d’attente**
Les causes fréquentes de l’augmentation du nombre d’événements d’attente sont les suivantes :
+ Une augmentation de la latence du réseau entre le réplica en lecture et le nœud d’enregistreur augmente le temps nécessaire au réplica en lecture pour recevoir les données du nœud d’enregistreur.
+ Une augmentation de la charge sur le réplica en lecture peut retarder la transmission de la demande associée à la requête de nettoyage du réplica en lecture au nœud d’enregistreur.
+ Une augmentation de la charge sur le nœud d’enregistreur peut retarder la transmission des données entre le nœud d’enregistreur et le 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 réplica en lecture ou l’instance de base de données d’enregistreur 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 dorsal sur le réplica en lecture attend le résultat d’une commande transférée de type commit transaction.
**Causes probables de l’augmentation du nombre d’événements d’attente**
Les causes fréquentes de l’augmentation du nombre d’événements d’attente sont les suivantes :
+ Une augmentation de la latence du réseau entre le réplica en lecture et le nœud d’enregistreur augmente le temps nécessaire au réplica en lecture pour recevoir les données du nœud d’enregistreur.
+ Une augmentation de la charge sur le réplica en lecture peut retarder la transmission de la demande de la requête entre le réplica en lecture et le nœud d’enregistreur.
+ Une augmentation de la charge sur le nœud d’enregistreur peut retarder la transmission des données entre le nœud d’enregistreur et le nœud secondaire.
**Actions**
Si le réplica en lecture ou le nœud d’enregistreur 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 dorsal sur le réplica en lecture attend le résultat d’une commande start transaction transférée.
**Causes probables de l’augmentation du nombre d’événements d’attente**
Les causes fréquentes de l’augmentation du nombre d’événements d’attente sont les suivantes :
+ Une augmentation de la latence du réseau entre le réplica en lecture et le nœud d’enregistreur augmente le temps nécessaire au réplica en lecture pour recevoir les données du nœud d’enregistreur.
+ Une augmentation de la charge sur le réplica en lecture peut retarder la transmission de la demande de la requête entre le réplica en lecture et le nœud d’enregistreur.
+ Une augmentation de la charge sur le nœud d’enregistreur peut retarder la transmission des données entre le nœud d’enregistreur et le nœud secondaire.
**Actions**
Si le réplica en lecture ou le nœud d’enregistreur 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.