View a markdown version of this page

Migrer les données à l'aide de la capture des données de modification (CDC) - Amazon Keyspaces (pour Apache Cassandra)

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.

Migrer les données à l'aide de la capture des données de modification (CDC)

Si vous êtes déjà familiarisé avec la configuration d'un pipeline de capture des données de modification (CDC) avec Debezium, vous pouvez utiliser cette option pour migrer des données vers Amazon Keyspaces au lieu d'utiliser CQLReplicator. Debezium est une plate-forme distribuée open source pour le CDC, conçue pour surveiller une base de données et capturer les modifications au niveau des lignes de manière fiable.

Le connecteur Debezium pour Apache Cassandra télécharge les modifications vers Amazon Managed Streaming pour Apache Kafka (Amazon MSK) afin qu'elles puissent être consommées et traitées par les consommateurs en aval qui, à leur tour, écrivent les données dans Amazon Keyspaces. Pour plus d'informations, consultez les conseils pour la migration continue des données d'Apache Cassandra vers Amazon Keyspaces.

Pour résoudre tout problème potentiel de cohérence des données, vous pouvez implémenter un processus avec Amazon MSK dans le cadre duquel un consommateur compare les clés ou les partitions de Cassandra à celles d'Amazon Keyspaces.

Pour mettre en œuvre cette solution avec succès, nous vous recommandons de prendre en compte les points suivants.

  • Comment analyser le journal des validations du CDC, par exemple comment supprimer les événements dupliqués.

  • Comment gérer le répertoire CDC, par exemple comment supprimer les anciens journaux.

  • Comment gérer les échecs partiels dans Apache Cassandra, par exemple si une écriture ne réussit que dans une des trois répliques.

  • Comment gérer l'allocation des ressources, par exemple en augmentant la taille de l'instance pour tenir compte des exigences supplémentaires en matière de processeur, de mémoire, de DISQUE et d'E/S pour le processus CDC qui se produit sur un nœud.

Ce modèle traite les modifications apportées par Cassandra comme un « indice » indiquant qu'une touche peut avoir changé par rapport à son état précédent. Pour déterminer si des modifications doivent être propagées à la base de données de destination, vous devez d'abord lire depuis le cluster Cassandra source en effectuant une LOCAL_QUORUM opération pour recevoir les derniers enregistrements, puis les écrire dans Amazon Keyspaces.

Dans le cas de suppressions ou de mises à jour de plages, vous devrez peut-être effectuer une comparaison avec l'ensemble de la partition pour déterminer quels événements d'écriture ou de mise à jour doivent être écrits dans votre base de données de destination.

Dans les cas où les écritures ne sont pas idempotentes, vous devez également comparer vos écritures avec ce qui se trouve déjà dans la base de données de destination avant d'écrire sur Amazon Keyspaces.

Le schéma suivant montre l'architecture typique d'un pipeline CDC utilisant Debezium et Amazon MSK.

Utilisation d'un pipeline de capture des données de modification pour migrer les données d'Apache Cassandra vers Amazon Keyspaces.