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.
Cohérence de lecture pour le transfert d'écriture
Vous pouvez contrôler le degré de cohérence de lecture sur un cluster de bases de données. Le niveau de cohérence de lecture détermine le temps que le cluster de bases de données doit attendre avant chaque opération de lecture, afin de s'assurer que certaines ou toutes les modifications sont répliquées à partir de l'enregistreur. Vous pouvez ajuster le niveau de cohérence de lecture pour vous assurer que toutes les opérations d'écriture transférées de votre session sont visibles dans le cluster de bases de données avant toute requête ultérieure. Vous pouvez également utiliser ce paramètre pour vous assurer que les requêtes sur le cluster de bases de données voient toujours les mises à jour les plus récentes de l'enregistreur. Ce paramètre s'applique également aux requêtes soumises par d'autres sessions ou d'autres clusters. Pour spécifier ce type de comportement pour votre application, choisissez une valeur pour le paramètre de base de données ou le paramètre de cluster de bases de données aurora_replica_read_consistency.
Important
Définissez toujours le paramètre de base de données ou le paramètre de cluster de bases de données aurora_replica_read_consistency lorsque vous souhaitez transférer des écritures. Si ce n'est pas le cas, Aurora ne transfère pas les écritures. Ce paramètre a une valeur vide par défaut, alors choisissez une valeur spécifique lorsque vous utilisez ce paramètre. Le paramètre aurora_replica_read_consistency affecte uniquement les clusters de bases de données et les instances pour lesquels le transfert d'écriture est activé.
Plus vous augmentez le niveau de cohérence, plus votre application passe de temps à attendre que les modifications se propagent entre les instances de base de données. Avant l'exécution de vos requêtes, vous pouvez choisir l'équilibre entre un temps de réponse rapide et l'assurance que les modifications apportées à d'autres instances de base de données seront entièrement disponibles.
Vous pouvez spécifier les valeurs suivantes pour le paramètre aurora_replica_read_consistency :
-
EVENTUAL: 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. 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 retard de réplication. Il s'agit de la même cohérence que pour les clusters Aurora My SQL DB qui n'utilisent pas le transfert d'écriture. -
SESSION: toutes les requêtes qui utilisent 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. -
GLOBAL: une session affiche toutes les modifications validées dans toutes les sessions et instances du cluster de bases de données. 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 de base up-to-date de données contient toutes les données validées par le rédacteur, au moment où la requête a commencé.
Pour obtenir des informations sur les paramètres de configuration impliqués dans le transfert d'écriture, consultez Paramètres de configuration pour le transfert d'écriture.
Note
Vous pouvez également utiliser aurora_replica_read_consistency en tant que variable de session, par exemple :
mysql> set aurora_replica_read_consistency = 'session';
Exemples d'utilisation du transfert d'écriture
Les exemples suivants montrent les effets du paramètre aurora_replica_read_consistency sur l'exécution d'instructions INSERT suivies d'instructions SELECT. Les résultats peuvent différer en fonction de la valeur de aurora_replica_read_consistency et de l'heure des instructions.
Pour obtenir une plus grande cohérence, vous pouvez attendre brièvement avant d'émettre l'instruction SELECT. Sinon, Aurora peut attendre automatiquement la fin de la réplication des résultats avant d'effectuer l'instruction SELECT.
Pour obtenir des informations sur la définition des paramètres de base de données, consultez Groupes de paramètres pour Amazon Aurora.
Exemple avec aurora_replica_read_consistency défini sur EVENTUAL
L'exécution d'une instruction INSERT, immédiatement suivie d'une instruction SELECT, renvoie une valeur pour COUNT(*) avec le nombre de lignes avant l'insertion de la nouvelle ligne. L'exécution répétée de l'instruction SELECT après une courte période renvoie le nombre de lignes mis à jour. Les instructions SELECT n'attendent pas.
mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 5 | +----------+ 1 row in set (0.00 sec) mysql> insert into t1 values (6); select count(*) from t1; +----------+ | count(*) | +----------+ | 5 | +----------+ 1 row in set (0.00 sec) mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 6 | +----------+ 1 row in set (0.00 sec)
Exemple avec aurora_replica_read_consistency défini sur SESSION
Une instruction SELECT placée immédiatement après une instruction INSERT attend que les modifications de l'instruction INSERT soient visibles. Les instructions SELECT suivantes n'attendent pas.
mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 6 | +----------+ 1 row in set (0.01 sec) mysql> insert into t1 values (6); select count(*) from t1; select count(*) from t1; Query OK, 1 row affected (0.08 sec) +----------+ | count(*) | +----------+ | 7 | +----------+ 1 row in set (0.37 sec) +----------+ | count(*) | +----------+ | 7 | +----------+ 1 row in set (0.00 sec)
Le paramètre de cohérence en lecture étant toujours défini sur SESSION, l'introduction d'une brève attente après l'exécution d'une instruction INSERT rend le nombre de lignes mis à jour disponible au moment de l'exécution de l'instruction SELECT suivante.
mysql> insert into t1 values (6); select sleep(2); select count(*) from t1; Query OK, 1 row affected (0.07 sec) +----------+ | sleep(2) | +----------+ | 0 | +----------+ 1 row in set (2.01 sec) +----------+ | count(*) | +----------+ | 8 | +----------+ 1 row in set (0.00 sec)
Exemple avec aurora_replica_read_consistency défini sur GLOBAL
Chaque instruction SELECT attend que toutes les modifications de données, depuis l'heure de début de l'instruction, soient visibles avant d'effectuer la requête. Le temps d'attente pour chaque instruction SELECT varie en fonction de l'ampleur du retard de réplication.
mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 8 | +----------+ 1 row in set (0.75 sec) mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 8 | +----------+ 1 row in set (0.37 sec) mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 8 | +----------+ 1 row in set (0.66 sec)
