Cette page a été traduite par l'API Cloud Translation.
Switch to English

Migrer des données depuis Teradata

La combinaison du service de transfert de données BigQuery et d'un agent de migration spécial vous permet de copier vos données d'une instance d'entrepôt de données sur site Teradata vers BigQuery. Ce document décrit le processus détaillé de migration des données depuis Teradata à l'aide du service de transfert de données BigQuery.

Avant de commencer

Pour garantir la réussite de la migration de l'entrepôt de données Teradata, assurez-vous que vous remplissez les conditions préalables suivantes.

Exigences de Google Cloud

  1. Sélectionnez ou créez un projet Google Cloud pour stocker vos données de migration. Vous devez disposer des autorisations owner sur le projet Google Cloud pour configurer le transfert.

    • Dans Google Cloud Console, accédez à la page de sélection du projet.

      Accéder à la page de sélection du projet

    • Sélectionnez ou créez un projet Google Cloud.

  2. Activez ces API Google Cloud.

    Console

    Dans Cloud Console, cliquez sur le bouton ENABLE (ACTIVER) sur les deux pages suivantes.

    BigQuery est automatiquement activé dans les nouveaux projets. Pour un projet existant, vous devrez peut-être activer l'API BigQuery.

    Exemple :

    Activer une API.

    Une coche verte indique que vous avez déjà activé l'API.

    API activée.

    gcloud

    Vous pouvez également utiliser l'outil de ligne de commande gcloud pour activer les API.

    Vous pouvez exécuter des commandes gcloud dans Cloud Shell ou télécharger l'outil gcloud et l'installer sur la machine locale, comme suit :

    • Java 8 doit être installé pour exécuter l'outil gcloud. Utilisez ce lien pour le télécharger.
    • Le SDK Cloud doit être installé et initialisé.

    Saisissez les commandes gcloud suivantes :

    gcloud services enable bigquerydatatransfer.googleapis.com
gcloud services enable storage-component.googleapis.com
gcloud services enable pubsub.googleapis.com

    BigQuery est automatiquement activé dans les nouveaux projets. Pour un projet existant, activez également l'API BigQuery.

    gcloud services enable bigquery.googleapis.com

  3. Créez un ensemble de données BigQuery pour stocker vos données. Vous n'avez pas besoin de créer de tables.

  4. Créez un compte de service IAM (Identity and Access Management). Consultez la page Créer et gérer des comptes de service pour obtenir plus d'informations sur la création d'un compte de service.

  5. Accordez au compte de service les rôles Cloud IAM suivants. Consultez la section Attribuer des rôles à un compte de service.

    • BigQuery : rôle Cloud IAM prédéfini bigquery.admin.
    • Cloud Storage : rôle Cloud IAM prédéfini storage.objectAdmin

  6. Créez un bucket Cloud Storage pour la préproduction des données. Vous utiliserez ce nom de bucket ultérieurement dans le processus de migration.

Configuration requise sur site

  1. Configuration requise pour la machine locale
    • L'agent de migration utilise une connexion JDBC avec l'instance Teradata et les API Google Cloud. Vérifiez que l'accès au réseau n'est pas bloqué par un pare-feu.
    • Assurez-vous que l'environnement d'exécution Java 8 ou version ultérieure est installé.
    • Assurez-vous que vous disposez de l'espace de stockage minimal recommandé, comme décrit dans la configuration requise pour l'espace de stockage.
  2. Détails de connexion à Teradata
    • Nom d'utilisateur et mot de passe d'un utilisateur disposant d'un accès en lecture aux tables système et aux tables en cours de migration.
    • Nom d'hôte et numéro de port pour se connecter à l'instance Teradata.
  3. Téléchargez les pilotes JDBC requis à partir de Teradata : tdgssconfig.jar et terajdbc4.jar.
  4. Téléchargez vos identifiants Google Cloud.

Modes et options de transfert

Comme chaque migration comporte ses propres exigences, l'agent de migration peut être personnalisé de différentes manières. Il existe trois choix principaux lors de la configuration d'un transfert de données de Teradata vers BigQuery :

Méthode d'extraction

Le service de transfert de données BigQuery offre deux méthodes d'extraction différentes pour transférer des données de Teradata vers BigQuery :

  1. Extraction à l'aide du pilote JDBC avec connexion FastExport Dans ce mode, une table est extraite dans une collection de fichiers AVRO à un emplacement spécifié sur un système de fichiers local. Les fichiers extraits sont ensuite importés dans un bucket Cloud Storage spécifié et, après un transfert réussi, les fichiers sont supprimés du système de fichiers local.
    • Les limitations de la quantité d'espace dans un système de fichiers local sont pleinement appliquées et l'extraction est mise en pause jusqu'à ce que les fichiers extraits aient été importés et supprimés du système de fichiers local.
    • S'il existe des contraintes strictes sur l'espace de stockage local ou si TPT n'est pas disponible, utilisez cette méthode d'extraction.
    • Le pilote JDBC avec FastExport est la méthode d'extraction par défaut.
  2. Extraction à l'aide de l'utilitaire Teradata Parallel Transporter (TPT) tbuild. Dans ce mode, un agent effectue le calcul des lots d'extraction à l'aide de lignes réparties par partitions. Pour chaque lot, un script d'extraction TPT est émis et exécuté, générant un ensemble de fichiers délimités par des barres verticales. Après chaque extraction par lots, les fichiers sont importés dans un bucket Cloud Storage spécifié et supprimés du système de fichiers local. Les limitations de la quantité d'espace de stockage dans le système de fichiers local ne sont pas appliquées. Vous devez donc vous assurer que le système de fichiers local dispose d'assez d'espace pour extraire la plus grande partition d'une table Teradata.
    • Nous vous recommandons d'extraire avec TPT et de personnaliser votre schéma pour indiquer les colonnes de partition. Ce mode d'extraction de données est le plus rapide.

Pour en savoir plus sur la spécification de la méthode d'extraction, reportez-vous à la section Configurer l'agent de migration de la procédure de configuration du transfert.

Fichier de schéma personnalisé

Un fichier de schéma est un fichier JSON qui décrit des objets de base de données. Le schéma comprend un ensemble de bases de données, chacune contenant un ensemble de tables, lesquelles contiennent chacune un ensemble de colonnes. Chaque colonne possède un champ type, le type attribué à une colonne dans BigQuery.

Dans un fichier de schéma, chaque objet possède un champ name, le nom qui lui sera attribué dans BigQuery. Chaque objet possède également un champ originalName, le nom de l'objet correspondant dans la base de données Teradata.

Le service de transfert de données BigQuery fournit une détection automatique de schéma et une conversion de données lors d'un transfert de données de Teradata vers BigQuery. Vous pouvez également spécifier un fichier de schéma personnalisé. Ceci est facultatif. Il est fortement recommandé de personnaliser le schéma dans certaines situations. Exemples :

  • Un fichier de schéma personnalisé est particulièrement utile pour inclure des informations supplémentaires sur une table, comme le partitionnement, qui seraient sinon perdues dans la migration si aucun fichier de schéma n'était spécifié.
  • Pendant le transfert de données, vous pouvez choisir de fournir un fichier de schéma personnalisé pour transformer les champs, par exemple le champ name d'un objet ou le tableau usageType d'une colonne.
  • Pour en savoir plus, consultez la section Migration Teradata : détails et options.

Transferts à la demande ou incrémentiels

Lors de la migration de données d'une instance de base de données Teradata vers BigQuery, le service de transfert de données BigQuery assure aussi bien les transferts de données instantanés (transferts à la demande) que les transferts récurrents et périodiques de lignes nouvelles et mises à jour (transferts incrémentiels) (bêta). Les modes de transfert à la demande ou incrémentiel sont définis dans les options de planification à l'étape Configurer un transfert.

  • Transfert de données à la demande
    • Si votre table est très volumineuse et que le mode d'extraction par TPT offrant de meilleures performances est disponible, nous vous recommandons de partitionner votre table Teradata pour pouvoir effectuer l'extraction partition par partition. Pour en savoir plus, consultez la section Migration Teradata : détails et options.
    • Si vos tables sont petites ou si vous ne pouvez pas utiliser TPT, suivez les instructions de base. La personnalisation du schéma n'est pas nécessaire.
  • Transfert de données incrémentiel
    • Si vous souhaitez migrer périodiquement les modifications de Teradata vers BigQuery, utilisez le mode incrémentiel. Les enregistrements nouveaux et modifiés de Teradata sont ajoutés aux tables BigQuery de manière récurrente.
    • Cette méthode nécessite de personnaliser votre schéma pour annoter les colonnes COMMIT_TIMESTAMP.
    • Certaines conditions s'appliquent lors de la configuration de transferts incrémentiels. Pour plus d'informations, reportez-vous à la section Transferts incrémentiels.

Configurer une migration Teradata

Cette section décrit le processus étape par étape de configuration d'une migration de données de Teradata vers BigQuery. Voici la procédure à suivre :

  • Téléchargez l'agent de migration.
  • Configurez un transfert avec le service de transfert de données BigQuery.
  • Initialisez l'agent de migration.
  • Exécutez l'agent de migration.

Télécharger l'agent de migration

Utilisez ce lien pour télécharger l'agent de migration sur la machine locale où se trouve l'entrepôt de données.

Après avoir installé l'agent de migration, configurez un transfert avec le service de transfert de données BigQuery, initialisez l'agent de migration, puis exécutez-le pour démarrer la migration des données.

Configurer un transfert

Créez un transfert avec le service de transfert de données BigQuery.

Console

  1. Dans Cloud Console, accédez à la page BigQuery.

    Accéder à BigQuery

  2. Cliquez sur Transferts.

  3. Cliquez sur Créer un transfert.

  4. Sous Source type (Type de source) :

    • Sélectionnez Migration: Teradata (Migration : Teradata).
    • Pour Transfer config name (Nom de la configuration de transfert), entrez un nom d'affichage pour le transfert tel que My Migration. Le nom à afficher peut correspondre à n'importe quelle valeur permettant d'identifier facilement le transfert si vous devez le modifier par la suite.
    • (Facultatif) Pour Schedule options (Options de programmation), vous pouvez conserver la valeur par défaut Daily (Tous les jours, en fonction de l'heure de création) en fonction de l'heure de création ou sélectionner une autre valeur.

    • Pour Destination settings (Paramètres de destination), sélectionnez l'ensemble de données approprié.

      Nouvelle migration Teradata générale.

  5. Sous Data Source Details (Détails de la source de données), poursuivez avec les détails spécifiques de votre transfert Teradata.

    • Dans le champ Database type (Type de base de données), sélectionnez Teradata.
    • Dans le champ Cloud Storage bucket (Bucket Cloud Storage), recherchez le nom du bucket Cloud Storage pour la préproduction des données de migration. Ne saisissez pas de préfixe gs:// : saisissez uniquement le nom du bucket.
    • Dans le champ Database name (Nom de la base de données), saisissez le nom de la base de données source dans Teradata.
    • Dans le champ Table name patterns (Modèles de nom de table), saisissez un ou plusieurs modèles pour faire correspondre les noms de tables dans la base de données source. Vous pouvez utiliser des expressions régulières pour spécifier le modèle. Le modèle doit suivre la syntaxe d'expression régulière Java.
    • Dans le champ Adresse e-mail du compte de service, saisissez l'adresse e-mail associée au compte de service Cloud IAM que vous avez créé.

    • (Facultatif) Pour Schema file path (Chemin d'accès au fichier du schéma), entrez le chemin d'accès et le nom d'un fichier de schéma JSON. Si aucun fichier de schéma n'est entré, BigQuery détecte automatiquement le schéma de la table en utilisant les données source en cours de transfert. Vous pouvez créer votre propre fichier de schéma, comme indiqué dans l'exemple de capture d'écran ci-dessous, ou vous pouvez utiliser l'agent de migration pour vous aider à créer un fichier de schéma. Pour plus d'informations sur la création d'un fichier de schéma, consultez la section initialisation de l'agent de migration.

      Nouvelle migration Teradata

    • (Facultatif) Dans la section Options de notification :

      • Cliquez sur le bouton pour activer les notifications par e-mail. Lorsque vous activez cette option, l'administrateur de transfert reçoit une notification par e-mail en cas d'échec de l'exécution du transfert.

      • Pour le champ Select a Pub/Sub topic (Sélectionner un sujet Pub/Sub), choisissez le nom de votre sujet ou cliquez sur Create a topic (Créer un sujet). Cette option configure les notifications d'exécution Cloud Pub/Sub pour votre transfert.

        Sujet Pub/Sub

  6. Cliquez sur Save.

  7. Cloud Console affiche tous les détails de configuration du transfert, y compris un nom de ressource pour ce transfert. Notez le nom de la ressource, car vous devrez l'entrer ultérieurement lors de l'exécution de l'agent de migration.

    Confirmation du transfert

bq

Saisissez la commande bq mk, puis spécifiez l'indicateur de création de transfert --transfer_config. Les paramètres suivants sont également requis :

  • --data_source
  • --display_name
  • --target_dataset
  • --params
bq mk \
--transfer_config \
--project_id=project ID \
--target_dataset=dataset \
--display_name=name \
--params='parameters' \
--data_source=data source

Où :

  • project ID est l'ID de votre projet. Si vous ne fournissez pas de --project_id afin de spécifier un projet particulier, le projet par défaut est utilisé.
  • dataset est le jeu de données que vous souhaitez cibler (--target_dataset) pour la configuration de transfert.
  • name est le nom à afficher (--display_name) pour la configuration de transfert. Le nom à afficher du transfert peut être n'importe quelle valeur vous permettant de l'identifier facilement si vous devez le modifier ultérieurement.
  • parameters contient les paramètres (--params) de la configuration de transfert créée au format JSON. Par exemple : --params='{"param":"param_value"}'.
    • Pour les migrations Teradata, ces paramètres sont obligatoires : bucket, database_type, agent_service_account, database_name, table_name_patterns.
      • bucket est le bucket Cloud Storage qui servira de zone de préproduction pendant la migration.
      • database_type est Teradata.
      • agent_service_account est l'adresse e-mail associée au compte de service que vous avez créé.
      • database_name est le nom de la base de données source dans Teradata.
      • table_name_patterns correspond à un ou plusieurs modèle(s) permettant de faire correspondre les noms de tables dans la base de données source. Vous pouvez utiliser des expressions régulières pour spécifier le modèle. Le modèle doit suivre la syntaxe d'expression régulière Java.
  • data_source correspond à la source de données (--data_source) : on_premises.

Par exemple, la commande suivante crée un transfert Teradata nommé My Transfer à l'aide du bucket Cloud Storage mybucket et de l'ensemble de données cible mydataset. Le transfert fera migrer toutes les tables de l'entrepôt de données Teradata mydatabase et le fichier de schéma facultatif est myschemafile.json.

bq mk \
--transfer_config \
--project_id=123456789876 \
--target_dataset=MyDataset \
--display_name='My Migration' \
--params='{"bucket": "mybucket", "database_type": "Teradata",
"database_name":"mydatabase", "table_name_patterns": ".*",
"agent_service_account":"myemail@mydomain.com", "schema_file_path":
"gs://mybucket/myschemafile.json"}' \
--data_source=on_premises

Après avoir exécuté la commande, vous recevez un message de ce type :

[URL omitted] Please copy and paste the above URL into your web browser and follow the instructions to retrieve an authentication code.

Suivez les instructions et collez le code d'authentification sur la ligne de commande.

API

Utilisez la méthode projects.locations.transferConfigs.create et fournissez une instance de la ressource TransferConfig.

Java 

import com.google.api.gax.rpc.ApiException;
import com.google.cloud.bigquery.datatransfer.v1.CreateTransferConfigRequest;
import com.google.cloud.bigquery.datatransfer.v1.DataTransferServiceClient;
import com.google.cloud.bigquery.datatransfer.v1.ProjectName;
import com.google.cloud.bigquery.datatransfer.v1.TransferConfig;
import com.google.protobuf.Struct;
import com.google.protobuf.Value;
import java.io.IOException;
import java.util.HashMap;
import java.util.Map;

// Sample to create a teradata transfer config.
public class CreateTeradataTransfer {

  public static void main(String[] args) throws IOException {
    // TODO(developer): Replace these variables before running the sample.
    final String projectId = "MY_PROJECT_ID";
    String datasetId = "MY_DATASET_ID";
    String databaseType = "Teradata";
    String bucket = "cloud-sample-data";
    String databaseName = "MY_DATABASE_NAME";
    String tableNamePatterns = "*";
    String serviceAccount = "MY_SERVICE_ACCOUNT";
    String schemaFilePath = "/your-schema-path";
    Map<String, Value> params = new HashMap<>();
    params.put("database_type", Value.newBuilder().setStringValue(databaseType).build());
    params.put("bucket", Value.newBuilder().setStringValue(bucket).build());
    params.put("database_name", Value.newBuilder().setStringValue(databaseName).build());
    params.put("table_name_patterns", Value.newBuilder().setStringValue(tableNamePatterns).build());
    params.put("agent_service_account", Value.newBuilder().setStringValue(serviceAccount).build());
    params.put("schema_file_path", Value.newBuilder().setStringValue(schemaFilePath).build());
    TransferConfig transferConfig =
        TransferConfig.newBuilder()
            .setDestinationDatasetId(datasetId)
            .setDisplayName("Your Teradata Config Name")
            .setDataSourceId("on_premises")
            .setParams(Struct.newBuilder().putAllFields(params).build())
            .setSchedule("every 24 hours")
            .build();
    createTeradataTransfer(projectId, transferConfig);
  }

  public static void createTeradataTransfer(String projectId, TransferConfig transferConfig)
      throws IOException {
    try (DataTransferServiceClient client = DataTransferServiceClient.create()) {
      ProjectName parent = ProjectName.of(projectId);
      CreateTransferConfigRequest request =
          CreateTransferConfigRequest.newBuilder()
              .setParent(parent.toString())
              .setTransferConfig(transferConfig)
              .build();
      TransferConfig config = client.createTransferConfig(request);
      System.out.println("Cloud teradata transfer created successfully :" + config.getName());
    } catch (ApiException ex) {
      System.out.print("Cloud teradata transfer was not created." + ex.toString());
    }
  }
}

Agent de migration

Vous pouvez éventuellement créer le transfert directement à partir de l'agent de migration, dans la section Initialiser l'agent de migration.

Pour créer le transfert à partir de l'agent de migration, vous devez d'abord attribuer le rôle Cloud IAM serviceAccessTokenCreator au compte de service que vous avez créé.

Vous pouvez accorder le rôle Cloud IAM de l'une des deux manières suivantes :

gcloud projects add-iam-policy-binding user_project_id \
--member='serviceAccount:service-user_project_number@gcp-sa-bigquerydatatransfer.iam.gserviceaccount.com' \
--role='roles/iam.serviceAccountTokenCreator'

Une fois que vous avez accordé l'autorisation serviceAccessTokenCreator au compte de service, vous pouvez passer au téléchargement de l'agent de migration, puis configurer le transfert dans le cadre de l'étape d'initialisation.

Initialiser l'agent de migration

Lorsque vous lancez une migration de données pour la première fois, initialisez l'agent de migration. L'initialisation n'est requise qu'une seule fois à chaque fois que vous configurez un transfert de migration, qu'il soit ou non récurrent.

Cette session ne démarre pas la migration. Elle ne sert que pour la configuration initiale.

  1. Ouvrez une nouvelle session. Sur la ligne de commande, émettez une commande permettant d'exécuter le fichier jar, avec des options spécifiques, au format suivant :

    java -cp \
OS-specific-separated-paths-to-jars (JDBC and agent) \
com.google.cloud.bigquery.dms.Agent \
--initialize

    Unix, Linux, Mac OS

    java -cp \
/usr/local/migration/Teradata/JDBC/tdgssconfig.jar:/usr/local/migration/Teradata/JDBC/terajdbc4.jar:/usr/local/migration/mirroring-agent.jar \
com.google.cloud.bigquery.dms.Agent \
--initialize

    Windows

    Copiez tous les fichiers dans le dossier C:\migration (ou ajustez les chemins d'accès dans la commande), puis exécutez la commande suivante :

    java -cp C:\migration\tdgssconfig.jar;C:\migration\terajdbc4.jar;C:\migration\mirroring-agent.jar com.google.cloud.bigquery.dms.Agent --initialize

  2. Lorsque vous y êtes invité, saisissez les paramètres suivants :

    • Si vous souhaitez enregistrer le modèle Teradata Parallel Transporter (TPT) sur le disque. Si vous prévoyez d'utiliser la méthode d'extraction TPT, vous pouvez modifier le modèle enregistré avec des paramètres adaptés à votre instance Teradata.
    • L'URI de la base de données source. Indiquez le numéro de port, si nécessaire.
    • Chemin vers un espace de travail local pour la migration. Assurez-vous que vous disposez de l'espace de stockage minimal recommandé, comme décrit dans la configuration requise pour l'espace de stockage.
    • Si vous allez utiliser Teradata Parallel Transporter (TPT) comme méthode d'extraction.
    • (Facultatif) Chemin d'accès à un fichier d'identifiants de base de données.

  3. Lorsque vous êtes invité à indiquer un nom de ressource pour le service de transfert de données BigQuery :

    Vous pouvez saisir le nom de ressource du transfert que vous avez configuré dans Cloud Console, ou créer le transfert à ce stade, via l'agent de migration lui-même. Vous pouvez éventuellement utiliser la commande d'initialisation de l'agent de migration pour créer un fichier de schéma. Voir l'onglet Agent de migration ci-dessous pour cette option.

    Console

    Saisissez le nom de ressource du transfert que vous avez précédemment configuré dans l'onglet "Console" de la section sur la configuration d'un transfert.

    Agent de migration

    • Saisissez l'ID de projet Google Cloud.
    • Saisissez le nom de la base de données source dans Teradata.
    • Entrez un modèle pour faire correspondre les noms des tables dans la base de données source. Vous pouvez utiliser des expressions régulières pour spécifier le modèle. Le modèle doit suivre la syntaxe d'expression régulière Java.
    • Facultatif : Saisissez le chemin d'accès à un fichier de schéma JSON local (recommandé pour les transferts récurrents). Ce fichier de schéma sera importé dans votre bucket Cloud Storage.
      • Choisissez de créer un nouveau fichier de schéma. Dans ce cas, vous serez invité à entrer un nom d'utilisateur et un mot de passe Teradata, et l'agent produira un fichier JSON avec un schéma converti. Le fichier sera créé dans un dossier local, en suivant ce modèle : <localpath>/schema/DO_NOT_REMOVE_td2bq_table_schemas_<string>.json. Après le téléchargement vers votre bucket Cloud Storage, le chemin et le nom de fichier suivront ce modèle : gs://mybucket/myproject_id/schema/DO_NOT_REMOVE_td2bq_table_schemas_<string>.json.
      • Modifiez le fichier de schéma pour marquer le partitionnement, le clustering, les clés primaires et les colonnes de suivi des modifications, et vérifiez que vous souhaitez utiliser ce schéma pour la configuration de transfert. Consultez la section Fichier de schéma personnalisé pour obtenir des conseils.
    • Entrez le nom de l'ensemble de données de destination dans BigQuery.
    • Saisissez le nom du bucket Cloud Storage dans lequel les données de migration seront préproduites avant leur chargement dans BigQuery.
    • Saisissez le nom de la configuration de transfert.

  4. Après avoir entré tous les paramètres demandés, l'agent de migration crée un fichier de configuration et le place dans le chemin local fourni dans les paramètres. Voir la section suivante pour regarder de plus près le fichier de configuration.

Fichier de configuration pour l'agent de migration

Le fichier de configuration créé à l'étape d'initialisation se présente comme suit :


   {
    "agent-id": "0eebc1ad-621d-4386-87f1-8eca96991f63",
    "transfer-configuration": {
      "project-id": "123456789876",
      "location": "us",
      "id": "5d533a90-0000-2e89-89a0-94eb2c059a76"
    },
    "source-type": "teradata",
    "console-log": false,
    "silent": false,
    "teradata-config": {
      "connection": {
       "host": "localhost"
      },
      "local-processing-space": "extracted",
      "database-credentials-file-path": "",
      "max-local-storage": "200GB",
      "use-tpt": false,
      "max-sessions": 0,
      "max-parallel-upload": 1,
      "max-unload-file-size": "2GB"
     }
   }

Toutes les options du fichier de configuration de l'agent de migration

  • transfer-configuration : informations sur cette configuration de transfert dans le service de transfert de données BigQuery.

  • teradata-config : informations spécifiques à cette extraction Teradata :

    • connection : informations sur le nom d'hôte et le port
    • local-processing-space : dossier d'extraction dans lequel l'agent va extraire les données de tables, avant de les importer dans Cloud Storage.
    • database-credentials-file-path : (facultatif) chemin d'accès à un fichier qui contient les identifiants permettant de se connecter automatiquement à la base de données Teradata. Le fichier doit contenir deux lignes, par exemple : 
      username=abc
password=123
      Lorsque vous utilisez un fichier d'informations d'identification, veillez à contrôler l'accès au dossier dans lequel vous le stockez sur le système de fichiers local, car il ne sera pas chiffré. Si aucun chemin d'accès n'est fourni, vous serez invité à entrer un nom d'utilisateur et un mot de passe lorsque vous démarrez un agent.

    • max-local-storage : quantité maximale d'espace de stockage local à utiliser pour l'extraction dans le répertoire de préproduction spécifié. La valeur par défaut est 200GB. Le format accepté est le suivant : numberKB|MB|GB|TB.

      Dans tous les modes d'extraction, les fichiers sont supprimés de votre répertoire de transfert local après avoir été téléchargés sur Cloud Storage.

      La quantité réelle d'espace de stockage de préproduction nécessaire dépend de la méthode d'extraction :

      • Dans la méthode d'extraction par défaut (pilote JDBC avec FastExport), de petits fragments de données sont écrits et importés en continu dans le bucket Cloud Storage spécifié. L'extraction se met en pause lorsque la limite max_local_storage spécifiée est atteinte.
      • En cas d'extraction avec Teradata Parallel Transporter (TPT) sans colonne de partitionnement, l'intégralité de votre table est extraite, quel que soit le paramètre max_local_storage.
      • En cas d'extraction avec Teradata Parallel Transporter (TPT) avec une colonne de partitionnement, l'agent extrait des ensembles de partitions. Les besoins en espace de stockage de préproduction sont égaux à la valeur la plus élevée entre max_local_storage et la taille de la plus grande partition de votre table extraite au format CSV.

    • use-tpt : demande à l'agent de migration d'utiliser Teradata Parallel Transporter (TPT) comme méthode d'extraction.

      Pour chaque table, l'agent de migration génère un script TPT, démarre un processus tbuild et attend la fin. Une fois le processus tbuild terminé, l'agent répertorie et télécharge les fichiers extraits vers Cloud Storage, puis supprime le script TPT.

      Pour utiliser la méthode d'extraction TPT, procédez comme suit :

      • L'utilitaire tbuild doit être installé et disponible pour que l'agent de migration puisse utiliser et démarrer le processus tbuild.
      • Le dossier d'extraction local doit disposer de suffisamment d'espace pour extraire la plus grande partition de la table au format CSV. En raison du formatage, la taille du fichier CSV sera supérieure à celle de la table d'origine dans Teradata.

    • max-sessions : spécifie le nombre maximal de sessions utilisées par la tâche d'exportation (FastExport ou TPT). S'il est défini sur 0, la base de données Teradata détermine le nombre maximal de sessions pour chaque tâche d'exportation.

    • max-parallel-uploads : détermine le nombre de fichiers téléchargés sur Cloud Storage en parallèle. En fonction de la bande passante de votre réseau et d'autres paramètres (tels que l'analyse DLP), l'augmentation de ce paramètre peut améliorer les performances.

    • max-unload-file-size : détermine la taille maximale du fichier extrait. Ce paramètre n'est pas appliqué pour les extractions TPT.

Exécuter l'agent de migration

Après avoir initialisé l'agent de migration et créé le fichier de configuration, procédez comme suit pour exécuter l'agent et démarrer la migration :

  1. Commencez à exécuter l'agent en utilisant le chemin de classe vers les pilotes JDBC et le chemin d'accès au fichier de configuration créé lors de l'étape d'initialisation précédente.

    java -cp \
OS-specific-separated-paths-to-jars (JDBC and agent) \
com.google.cloud.bigquery.dms.Agent \
--configuration-file=path to configuration file

    Unix, Linux, Mac OS

    java -cp \
/usr/local/migration/Teradata/JDBC/tdgssconfig.jar:/usr/local/migration/Teradata/JDBC/terajdbc4.jar:mirroring-agent.jar \
com.google.cloud.bigquery.dms.Agent \
--configuration-file=config.json

    Windows

    Copiez tous les fichiers dans le dossier C:\migration (ou ajustez les chemins d'accès dans la commande), puis exécutez la commande suivante :

    java -cp C:\migration\tdgssconfig.jar;C:\migration\terajdbc4.jar;C:\migration\mirroring-agent.jar com.google.cloud.bigquery.dms.Agent --configuration-file=config.json

    Si vous êtes prêt à poursuivre la migration, appuyez sur Enter. L'agent procédera si le chemin d'accès aux classes fourni lors de l'initialisation est valide.

  2. Lorsque vous y êtes invité, entrez le nom d'utilisateur et le mot de passe pour la connexion à la base de données. Si le nom d'utilisateur et le mot de passe sont valides, la migration des données démarre.

    Facultatif Dans la commande pour démarrer la migration, vous pouvez également utiliser un indicateur qui transmet un fichier d'informations d'identification à l'agent, au lieu d'entrer à chaque fois le nom d'utilisateur et le mot de passe. Voir le paramètre facultatif database-credentials-file-path dans le fichier de configuration de l'agent pour plus d'informations. Lorsque vous utilisez un fichier d'informations d'identification, prenez les mesures appropriées pour contrôler l'accès au dossier dans lequel vous le stockez sur le système de fichiers local, car il ne sera pas chiffré.

  3. Laissez cette session ouverte jusqu'à la fin de la migration. Si vous avez créé un transfert de migration récurrent, laissez cette session ouverte indéfiniment. Si cette session est interrompue, les exécutions de transfert actuelles et futures échoueront.

  4. Vérifiez régulièrement si l'agent est en cours d'exécution. Si un transfert est en cours et qu'aucun agent ne répond dans les 24 heures, le transfert échoue.

  5. Si l'agent de migration cesse de fonctionner alors que le transfert est en cours ou planifié, Cloud Console affiche l'état de l'erreur et vous invite à redémarrer l'agent. Pour redémarrer l'agent de migration, reprenez depuis le début de cette section, exécuter l'agent de migration, avec la commande pour exécuter l'agent de migration. Vous n'avez pas besoin de répéter la commande d'initialisation. Le transfert reprendra à partir du moment où les tables n'ont pas été complétées.

Suivre la progression de la migration

Vous pouvez afficher l'état de la migration dans Cloud Console. Vous pouvez également configurer des notifications Pub/Sub ou par e-mail. Voir Notifications du service de transfert de données BigQuery.

Le service de transfert de données BigQuery planifie et lance une exécution de transfert selon un calendrier spécifié lors de la création de la configuration de transfert. Il est important que l'agent de migration s'exécute lorsqu'une exécution de transfert est active. S'il n'y a aucune mise à jour du côté de l'agent dans les 24 heures, une exécution de transfert échouera.

Exemple d'état de la migration dans Cloud Console :

État de la migration

Mettre à jour l'agent de migration

Si une nouvelle version de l'agent de migration est disponible, vous devrez mettre à jour manuellement l'agent de migration. Pour recevoir des notifications sur le service de transfert de données BigQuery, abonnez-vous aux notes de version.

Étape suivante