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.
# 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).