Utilisation du transfert d'écriture local dans un cluster de bases de données Amazon Aurora MySQL

Le transfert d'écriture local (intracluster) permet à vos applications d'émettre des transactions de lecture/écriture directement sur un réplica Aurora. Ces transactions 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 lorsque vos applications exigent une cohérence de lecture après écriture, qui est la capacité à lire la dernière écriture dans une transaction.

Les réplicas en lecture reçoivent des mises à jour de manière asynchrone de la part de l'enregistreur. Sans transfert d'écriture, 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. Ou vous devez développer une logique d'application personnalisée complexe pour tirer parti de plusieurs réplicas en lecture pour assurer la capacité de mise à l'échelle. Vos applications doivent diviser entièrement l'ensemble du trafic de lecture et d'écriture, en conservant deux ensembles de connexions de base de données pour envoyer le trafic au point de terminaison correct. Cette surcharge de développement complique la conception de l'application lorsque les requêtes font partie d'une seule session logique, ou transaction, au sein de l'application. 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 toutes les instances dans la base de données.

Le transfert d'écriture évite d'avoir à diviser ces transactions ou à les envoyer exclusivement à l'enregistreur, ce qui simplifie le développement des applications. Cette nouvelle fonctionnalité permet d'effectuer facilement la mise à l'échelle en lecture des charges de travail qui doivent lire la dernière écriture dans une transaction et qui ne sont pas sensibles à la latence d'écriture.

Le transfert d'écriture local est différent du transfert d'écriture global, qui transfère les écritures d'un cluster de bases de données secondaire vers le cluster de bases de données principal dans une base de données globale Aurora. Vous pouvez utiliser le transfert d'écriture local dans un cluster de bases de données faisant partie d'une base de données globale Aurora. Pour de plus amples informations, veuillez consulter Utilisation du transfert d'écriture dans une base de données globale Amazon Aurora.

Le transfert d'écriture local nécessite Aurora MySQL version 3.04 ou ultérieure.

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 MySQL. Vous activez le transfert d'écriture local au niveau du cluster, et non au niveau de l'instance.

aws rds create-db-cluster \
  --db-cluster-identifier write-forwarding-test-cluster \
  --enable-local-write-forwarding \
  --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.04.0 \
  --master-username myuser \
  --master-user-password mypassword \
  --backup-retention 1

Activation du transfert d'écriture pour les sessions de base de données

Le paramètre aurora_replica_read_consistency 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 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 Cohérence de lecture pour le transfert d'écriture.

Les règles suivantes s'appliquent à ce paramètre :

Vérification de l'activation du transfert d'écriture dans un cluster de bases de données

Pour déterminer si vous pouvez utiliser le transfert d'écriture dans un cluster de bases de données, vérifiez que le cluster possède l'attribut LocalWriteForwardingStatus réglé 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 pour tous vos clusters, exécutez la commande AWS CLI suivante.

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-mysql-v2-cluster"
    }
]

Un cluster de bases de données peut avoir les valeurs suivantes pour LocalWriteForwardingStatus :

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

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

Certaines instructions ne sont pas autorisées ou peuvent produire des résultats obsolètes lorsque vous les utilisez dans un cluster de bases de données avec transfert d'écriture. Ainsi, 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 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 de bases de données avec le transfert d'écriture activé. 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. Si vous essayez d'utiliser une instruction alors qu'elle n'est pas autorisée en raison du transfert d'écriture, vous verrez un message d'erreur semblable au suivant :

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

Niveaux d'isolation pour le transfert d'écriture

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 réplicas Aurora, 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.

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.

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 :

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.

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.

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)

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)

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)

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

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.

Transactions avec transfert d'écriture

Si le mode d'accès aux transactions est réglé sur lecture seule, le transfert d'écriture n'est pas utilisé. 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 définir le paramètre aurora_fwd_writer_idle_timeout pour l'augmenter jusqu'à un jour. Une transaction qui dépasse le délai d'inactivité est annulée par l'instance d'enregistreur. 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 de bases de données ou si vous désactivez le transfert d'écriture.

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.

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

Les groupes de paramètres de base de données Aurora incluent des paramètres pour la fonctionnalité de transfert d'écriture. 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, utilisez les paramètres suivants :

Pour plus d'informations sur aurora_replica_read_consistency, consultez Cohérence de lecture pour le transfert d'écriture.

Pour plus d'informations sur les groupes de paramètres de base de données, consultez Groupes de paramètres pour Amazon Aurora.

Métriques Amazon CloudWatch et variables d'état Aurora MySQL pour le transfert d'écriture

Les métriques Amazon CloudWatch et les variables d'état Aurora MySQL suivantes s'appliquent lorsque vous utilisez le transfert d'écriture sur un ou plusieurs clusters de bases de données. Ces métriques et variables d'état sont toutes mesurées sur l'instance de base de données d'enregistreur.

Les métriques CloudWatch et les variables d'état Aurora MySQL suivantes 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é.

Identification des transactions et des requêtes transférées

Vous pouvez utiliser la table information_schema.aurora_forwarding_processlist pour identifier les transactions et les requêtes transférées. Pour plus d'informations sur cette table, consultez information_schema.aurora_forwarding_processlist.

L'exemple suivant montre toutes les connexions transférées sur une instance de base de données d'enregistreur.

mysql> select * from information_schema.AURORA_FORWARDING_PROCESSLIST where IS_FORWARDED=1 order by REPLICA_SESSION_ID;

+-----+----------+--------------------+----------+---------+------+--------------+--------------------------------------------+--------------+--------------------+---------------------------------+----------------------+----------------+
| ID  | USER     | HOST               | DB       | COMMAND | TIME | STATE        | INFO                                       | IS_FORWARDED | REPLICA_SESSION_ID | REPLICA_INSTANCE_IDENTIFIER     | REPLICA_CLUSTER_NAME | REPLICA_REGION |
+-----+----------+--------------------+----------+---------+------+--------------+--------------------------------------------+--------------+--------------------+---------------------------------+---------------------------------------+
| 648 | myuser   | IP_address:port1   | sysbench | Query   |    0 | async commit | UPDATE sbtest58 SET k=k+1 WHERE id=4802579 |            1 |                637 | my-db-cluster-instance-2        | my-db-cluster        | us-west-2      |
| 650 | myuser   | IP_address:port2   | sysbench | Query   |    0 | async commit | UPDATE sbtest54 SET k=k+1 WHERE id=2503953 |            1 |                639 | my-db-cluster-instance-2        | my-db-cluster        | us-west-2      |
+-----+----------+--------------------+----------+---------+------+--------------+--------------------------------------------+--------------+--------------------+---------------------------------+----------------------+----------------+

Sur l'instance de base de données du lecteur de transfert, vous pouvez voir les threads associés à ces connexions de base de données d'écriture en exécutant SHOW PROCESSLIST. Les valeurs de REPLICA_SESSION_ID sur l'enregistreur, 637 et 639, sont les mêmes que les valeurs de Id sur le lecteur.

mysql> select @@aurora_server_id;

+---------------------------------+
| @@aurora_server_id              |
+---------------------------------+
| my-db-cluster-instance-2        |
+---------------------------------+
1 row in set (0.00 sec)

mysql> show processlist;

+-----+----------+--------------------+----------+---------+------+--------------+---------------------------------------------+
| Id  | User     | Host               | db       | Command | Time | State        | Info                                        |
+-----+----------+--------------------+----------+---------+------+--------------+---------------------------------------------+
| 637 | myuser   | IP_address:port1   | sysbench | Query   |    0 | async commit | UPDATE sbtest12 SET k=k+1 WHERE id=4802579  |
| 639 | myuser   | IP_address:port2   | sysbench | Query   |    0 | async commit | UPDATE sbtest61 SET k=k+1 WHERE id=2503953  |
+-----+----------+--------------------+----------+---------+------+--------------+---------------------------------------------+
12 rows in set (0.00 sec)