Lorsqu'une rétroalimentation Datastream standard prend trop de temps ou présente des limites de produit, vous pouvez copier les données initiales dans une table BigQuery existante séparément. La diffusion en flux continu des mises à jour de capture de données modifiées (CDC) dans BigQuery à partir d'une position de journal spécifique vous permet de synchroniser la table sans exécuter de rétroalimentation intégrée.
Problème
Une table BigQuery remplie à l'aide de l' API BigQuery Storage Write n'autorise pas les opérations de langage de manipulation de données (LMD) régulières. Cela signifie qu'une fois qu'un flux CDC commence à écrire dans une table BigQuery, il n'est plus possible d'ajouter des données historiques qui n'ont pas déjà été préremplies dans la table.
Imaginez le scénario suivant :
- TIMESTAMP 1: l'opération de copie de la table est lancée.
- TIMESTAMP 2 : pendant la copie de la table, les opérations LMD au niveau de la source entraînent des modifications des données (des lignes sont ajoutées, mises à jour ou supprimées).
- TIMESTAMP 3 : la CDC démarre, mais les modifications survenues pendant TIMESTAMP 2 ne sont pas capturées, ce qui entraîne une incohérence des données.
Solution
Pour garantir l'intégrité des données, le processus CDC doit capturer toutes les modifications apportées à la source à partir du moment qui suit immédiatement la dernière mise à jour copiée dans la table BigQuery.
La solution suivante vous permet de vous assurer que le processus CDC capture toutes les modifications à partir de TIMESTAMP 2, sans empêcher l'opération de copie d'écrire des données dans la table BigQuery.
Prérequis
- La table cible dans BigQuery doit avoir exactement le même schéma et la même configuration que si elle avait été créée par Datastream. Pour ce faire, vous pouvez utiliser le kit d'outils de migration BigQuery de Datastream.
- Pour les sources MySQL et Oracle, vous devez pouvoir identifier la position du journal au moment où l'opération de copie est lancée.
- La base de données doit disposer d'un espace de stockage suffisant et d'une stratégie de conservation des journaux appropriée pour permettre au processus de copie de la table de se terminer.
Sources MySQL et Oracle
- Créez le flux que vous comptez utiliser pour la réplication CDC continue, mais ne le démarrez pas. Le flux doit être à l'état CREATED (CRÉÉ).
- Lorsque vous êtes prêt à démarrer l'opération de copie de la table, identifiez la position actuelle du journal de la base de données :
- Pour MySQL, consultez la documentation MySQL pour savoir comment obtenir les coordonnées du journal binaire de réplication. Une fois que vous avez identifié la position du journal, fermez la session pour libérer tous les verrous de la base de données.
- Pour Oracle, exécutez la requête suivante :
SELECT current_scn FROM V$DATABASE.
- Copiez la table de la base de données source dans BigQuery.
- Une fois l'opération de copie terminée, suivez les étapes décrites sur la page Gérer les flux pour démarrer le flux à partir de la position du journal que vous avez identifiée précédemment.
Sources PostgreSQL
- Lorsque vous êtes prêt à commencer à copier la table, créez l'emplacement de réplication. Pour en savoir plus, consultez Configurer une base de données source PostgreSQL.
- Copiez la table de la base de données source dans BigQuery.
- Une fois l'opération de copie terminée, créez et démarrez le flux.