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

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

Le transfert d'écriture est pris en charge par Aurora MySQL 2.08.1 et versions ultérieures, dans toutes les régions où les bases de données globales Aurora MySQL sont présentes.

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

Activation du transfert d'écriture dans Aurora MySQL

Par défaut, le transfert d'écriture n'est pas activé lorsque vous ajoutez un cluster secondaire à une base de données globale Aurora.

Pour activer le transfert d'écriture à l'aide du AWS Management Console, cochez la case Activer le transfert d'écriture global sous Lire le transfert d'écriture répliqué lorsque vous ajoutez une région pour une base de données globale. Pour un cluster secondaire existant, modifiez le cluster pour Activer le transfert d'écriture global. Pour désactiver le transfert d'écriture, décochez la case Activer le transfert d'écriture global lors de l'ajout de la région ou de la modification du cluster secondaire.

Pour activer le transfert d'écriture à l'aide de AWS CLI, utilisez l'--enable-global-write-forwardingoption. Cette option est utile lorsque vous créez un nouveau cluster secondaire à l'aide de la commande create-db-cluster. Elle est également utile lorsque vous modifiez un cluster secondaire existant à l'aide de la commande modify-db-cluster. Elle 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 de CLI.

Pour activer le transfert d'écriture à l'aide de l'API Amazon RDS, définissez le paramètre EnableGlobalWriteForwarding sur true. Ce paramètre agit lorsque vous créez un cluster secondaire à l'aide de l'opération CreateDBCluster. Il agit également lorsque vous modifiez un cluster secondaire existant à l'aide de l'opération ModifyDBCluster. Elle 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.

Les exemples de CLI suivants montrent comment configurer une base de données Aurora globale avec le transfert d'écriture activé ou désactivé. Les éléments en surbrillance représentent les commandes et les options qui sont importantes pour spécifier et conserver la cohérence lors de la configuration de l'infrastructure d'une base de données Aurora globale.

L'exemple suivant crée une base de données Aurora globale, un cluster principal et un cluster secondaire avec le transfert d'écriture activé. Remplacez vos propres choix par le nom d'utilisateur, le mot de passe et les régions AWS principales et secondaires.

# Create overall global database.
aws rds create-global-cluster --global-cluster-identifier write-forwarding-test \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-east-1

# Create primary cluster, in the same AWS Region as the global database.
aws rds create-db-cluster --global-cluster-identifier write-forwarding-test \
  --db-cluster-identifier write-forwarding-test-cluster-1 \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --master-username user_name --master-user-password password \
  --region us-east-1

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-1 \
  --db-instance-identifier write-forwarding-test-cluster-1-instance-1 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-east-1

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-1 \
  --db-instance-identifier write-forwarding-test-cluster-1-instance-2 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-east-1

# Create secondary cluster, in a different AWS Region than the global database,
# with write forwarding enabled.
aws rds create-db-cluster --global-cluster-identifier write-forwarding-test \
  --db-cluster-identifier write-forwarding-test-cluster-2 \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-east-2 \
  --enable-global-write-forwarding

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
  --db-instance-identifier write-forwarding-test-cluster-2-instance-1 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-east-2

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
  --db-instance-identifier write-forwarding-test-cluster-2-instance-2 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-east-2

L'exemple suivant est la suite de l'exemple précédent. Il crée un cluster secondaire sans le transfert d'écriture activé, puis active le transfert d'écriture. A la fin de cet exemple, le transfert d'écriture est activé sur tous les clusters secondaires de la base de données globale.

# Create secondary cluster, in a different AWS Region than the global database,
# without write forwarding enabled.
aws rds create-db-cluster --global-cluster-identifier write-forwarding-test \
  --db-cluster-identifier write-forwarding-test-cluster-2 \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-west-1

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
  --db-instance-identifier write-forwarding-test-cluster-2-instance-1 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-west-1

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
  --db-instance-identifier write-forwarding-test-cluster-2-instance-2 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-west-1

aws rds modify-db-cluster --db-cluster-identifier write-forwarding-test-cluster-2 \
  --region us-east-2 \
  --enable-global-write-forwarding

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

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 l' AWS Management Console onglet Configuration de la page de détails du cluster, le statut Activé pour le transfert d'écriture global en lecture et en réplique s'affiche.

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.

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.

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 MySQL

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

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

Les restrictions suivantes s'appliquent aux instructions SQL que vous utilisez avec le transfert d'écriture. Dans certains cas, vous pouvez utiliser les instructions sur des clusters secondaires avec le transfert d'écriture activé au niveau du cluster. Cette approche fonctionne si le transfert d'écriture n'est pas activé dans la session par le paramètre de configuration aurora_replica_read_consistency. Essayer d'utiliser une instruction lorsqu'elle n'est pas autorisée en raison du transfert d'écriture provoque un message d'erreur au format suivant.

ERROR 1235 (42000): This version of MySQL doesn't yet support 'operation with write forwarding'.

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

Dans les sessions qui utilisent le transfert d'écriture, vous ne pouvez utiliser uniquement le niveau d'isolement REPEATABLE READ. Bien que vous puissiez également utiliser le niveau d'isolement READ COMMITTED avec des clusters en lecture seule dans des régions AWS secondaires, ce niveau d'isolement ne fonctionne pas avec le transfert d'écriture. Pour de plus amples informations sur les niveaux d'isolement REPEATABLE READ et READ COMMITTED, veuillez consulter Niveaux d'SQLisolation d'Aurora My.

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 une valeur pour le paramètre de niveau session aurora_replica_read_consistency.

Pour le paramètre aurora_replica_read_consistency, vous pouvez spécifier les valeurs EVENTUAL, SESSION et GLOBAL.

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.

Lorsque la cohérence de lecture est définie surEVENTUAL, les requêtes d'une AWS région secondaire qui utilise le transfert d'écriture peuvent voir 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.

Lorsque la cohérence de lecture est définie surSESSION, 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.

Lorsque la cohérence de lecture est définie surGLOBAL, une session d'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é.

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 MySQL.

Exemples d'utilisation du transfert d'écriture

Ces exemples utilisent aurora_replica_read_consistency en tant que variable de session. Pour Aurora MySQL version 3.04 ou ultérieure, vous pouvez utiliser aurora_replica_read_consistency en tant que variable de session ou en tant que paramètre de cluster de base de données.

Dans l'exemple suivant, le cluster principal se trouve dans la région US East (N. Virginia). Le cluster secondaire se trouve dans la région USA Est (Ohio). L'exemple montre les effets de l'exécution d'instructions INSERT suivies d'instructionsSELECT. Selon la valeur du paramètre aurora_replica_read_consistency, les résultats peuvent différer en fonction 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.

Cet exemple comporte un paramètre de cohérence en lecture de eventual. L'exécution d'une instruction INSERT immédiatement suivie d'une instruction SELECT renvoie toujours la valeur de COUNT(*). Cette valeur reflète 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> set aurora_replica_read_consistency = 'eventual';
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)

Avec un paramètre de cohérence en lecture session, une instruction SELECT 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> set aurora_replica_read_consistency = 'session';
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)

Avec un paramètre de cohérence en lecture global, chaque instruction SELECT attend de s'assurer que toutes les modifications de données au début de l'instruction sont visibles avant d'effectuer la requête. La longueur de l'attente pour chaque instruction SELECT varie en fonction du décalage de réplication entre les clusters principal et secondaire.

mysql> set aurora_replica_read_consistency = 'global';
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)

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

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.

Transactions avec transfert d'écriture dans Aurora MySQL

Le transfert de la transaction vers le cluster principal dépend du mode d'accès de la transaction. Vous pouvez spécifier le mode d'accès de la transaction à l'aide de l'instruction SET TRANSACTION ou de l'instruction START TRANSACTION. Vous pouvez également spécifier le mode d'accès aux transactions en modifiant la valeur de la variable de session transaction_read_only. Vous pouvez modifier cette valeur de session seulement lorsque vous êtes connecté à un cluster de bases de données pour lequel le transfert d'écriture est activé.

Si une transaction de longue durée n'émet aucune instruction pendant une longue période, elle peut dépasser le délai d'inactivité. La valeur par défaut de cette période est d'une minute. Vous pouvez l'augmenter jusqu'à un jour. Une transaction qui dépasse le délai d'inactivité est annulée par le cluster principal. L'instruction suivante que vous soumettez reçoit une erreur de délai d'attente. Puis Aurora restaure la transaction.

Ce type d'erreur peut se produire dans d'autres cas, lorsque le transfert d'écriture devient indisponible. Par exemple, Aurora annule toutes les transactions qui utilisent le transfert d'écriture si vous redémarrez le cluster principal ou si vous désactivez le paramètre de configuration de transfert d'écriture.

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

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.

Pour contrôler les demandes d'écriture entrantes à partir de clusters secondaires, utilisez ces paramètres sur le cluster principal :

Le aurora_replica_read_consistency paramètre active le transfert d'écriture. Vous l'utilisez dans chaque session. Vous pouvez spécifier EVENTUAL, SESSION ou GLOBAL pour le niveau de cohérence de lecture. Pour en savoir plus sur les niveaux de cohérence, consultez la section Isolement et cohérence pour le transfert d'écriture dans Aurora MySQL. Les règles suivantes s'appliquent à ce paramètre :

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

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.

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é.

Variables d'état Aurora MySQL pour le transfert d'écriture

Les variables d'état Aurora MySQL 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.

Les variables d'état Aurora MySQL 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é.