Cette page décrit les bonnes pratiques à adopter dans les cas suivants:
- Les utilisateurs disposent d'une table BigQuery et doivent répliquer leurs données à l'aide de la capture de données modifiées (CDC, Change Data Capture) 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 prendra, soit en raison des limites du produit.
Problem (Problème)
Une table BigQuery insérée à l'aide de l'API BigQuery Storage Write n'autorise pas les opérations régulières en 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'étaient pas déjà 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 au niveau des données (des lignes sont ajoutées, mises à jour ou supprimées).
- TIMESTAMP 3: la CDC est lancée. Les modifications apportées à TIMESTAMP 2 ne sont pas capturées, ce qui entraîne un écart de données.
Solution
Pour garantir l'intégrité des données, la CDC doit capturer toutes les modifications de la source survenues à partir du moment suivant la dernière mise à jour effectuée et copiée dans la table BigQuery.
La solution suivante vous permet de vous assurer que le processus CDC capture toutes les modifications 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 la table avait été créée par Datastream. Pour ce faire, vous pouvez utiliser le kit de migration BigQuery Datastream.
- Pour les sources MySQL et Oracle, l'utilisateur doit être en mesure d'identifier la position dans le journal au moment du lancement de l'opération de copie.
- La base de données doit disposer de règles de stockage et de conservation des journaux suffisantes pour que le processus de copie de la table puisse se terminer.
Sources MySQL et Oracle
- Créez, mais ne démarrez pas le flux que vous avez l'intention d'utiliser pour la réplication CDC en cours. Le flux doit présenter l'état CREATED.
- Lorsque vous êtes prêt à lancer 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 dans le journal, fermez la session pour libérer 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 à la page Gérer les flux pour démarrer le flux à partir de la position dans le 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 PostgreSQL source.
- 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.