Cette page décrit les bonnes pratiques à suivre dans les cas d'utilisation suivants :
- Les utilisateurs disposent d'une table existante dans BigQuery et doivent répliquer leurs données à l'aide de la capture de données modifiées (CDC) dans la même table BigQuery.
- Les utilisateurs doivent copier des données dans une table BigQuery existante sans utiliser la fonctionnalité de remplissage Datastream, soit en raison du temps que cela prendrait, soit en raison des limites du produit.
Problème
Une table BigQuery remplie à l'aide de l'API BigQuery Storage Write n'autorise pas les opérations régulières du langage de manipulation de données (LMD). 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 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 est lancée, mais les modifications apportées à 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 de migration Datastream vers BigQuery.
- Pour les sources MySQL et Oracle, l'utilisateur doit 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'une capacité de stockage et d'une stratégie de conservation des journaux suffisantes pour permettre au processus de copie des tables de se terminer.
Sources MySQL et Oracle
- Créez, mais ne démarrez pas le flux que vous comptez utiliser pour la réplication CDC continue. Le flux doit être à l'état CREATED.
- Lorsque vous êtes prêt à démarrer l'opération de copie de table, identifiez la position actuelle du journal de la base de données :
- Pour MySQL, consultez la documentation MySQL afin de 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 les verrous sur 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 la procédure décrite 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.