Utilisation du transfert d'écriture local dans un cluster Amazon Aurora My SQL DB

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 ont besoin de read-after-write cohérence, c'est-à-dire de la capacité de lire la dernière écriture d'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 effectuer toutes les lectures nécessitant de la read-after-write cohérence sur l'instance de base de données du rédacteur. 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 à la 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 My SQL version 3.04 ou supérieure.

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

Pour connaître l'état du paramètre de transfert d'écriture pour tous vos clusters, exécutez ce qui suit AWS CLI commande.

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 :

Application et SQL compatibilité avec le transfert d'écriture

Vous pouvez utiliser les types d'SQLinstructions 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 SQL instructions que vous utilisez pour 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.

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

Une DML déclaration peut être composée de plusieurs parties, telles qu'une INSERT ... SELECT déclaration ou une DELETE ... WHERE déclaration. 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.

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)