Bonnes pratiques pour l'importation et l'exportation de données

Cette page présente les bonnes pratiques à suivre pour importer et exporter des données avec Cloud SQL. Pour obtenir des instructions détaillées sur l'importation de données dans Cloud SQL, consultez la page Importer des données.

Pour exporter des données depuis Cloud SQL afin de les utiliser dans une instance MySQL que vous gérez, consultez la page Exporter et importer à l'aide de fichiers de vidage SQL ou la page Exporter et importer à l'aide de fichiers CSV.

Bonnes pratiques pour l'importation et l'exportation

Voici les bonnes pratiques à adopter lors de l'importation et de l'exportation de données :

Utiliser le même mode SQL pour l'importation et l'exportation

Le paramètre Mode SQL a une incidence sur la façon dont Cloud SQL interprète les requêtes SQL. Par exemple, si vous exportez depuis une base de données sans SQL Strict, puis que vous essayez d'importer dans Cloud SQL (qui active le mode SQL Strict par défaut), l'importation peut échouer. La bonne pratique consiste à utiliser le même mode SQL pour l'importation et pour l'exportation.

Pour éviter tout problème de compatibilité, examinez les modes SQL sur les bases de données source et cible. Portez une attention particulière aux options qui activent le mode SQL Strict. Si le mode SQL Strict n'est pas activé sur votre base de données, vous devrez probablement le supprimer dans Cloud SQL. Si vous supprimez l'option SQL Strict, vous devez en définir une autre à la place.

Pour vérifier que le mode défini sur votre instance Cloud SQL est le bon, exécutez la commande SELECT @@GLOBAL.sql_mode;.

Ne pas utiliser les buckets "Paiements" du demandeur Cloud Storage

Vous ne pouvez pas utiliser de buckets Cloud Storage pour lesquels les paiements du demandeur sont activés pour réaliser des importations et des exportations depuis Cloud SQL.

Minimiser l'impact sur les performances des exportations

Pour une exportation standard depuis Cloud SQL, l'exportation est exécutée tant que la base de données est en ligne. Lorsque la quantité des données exportées est faible, l'impact est susceptible d'être minime. Toutefois, en cas de bases de données ou d'objets volumineux, tels que des BLOB dans la base de données, il est possible que l'exportation réduise les performances de la base de données. Cela peut avoir un impact sur le temps nécessaire pour exécuter des requêtes et des opérations sur la base de données. Une fois que vous avez lancé une exportation, il n'est pas possible de l'arrêter si votre base de données commence à répondre lentement.

Pour éviter les réponses lentes lors d'une exportation, vous pouvez agir de la façon suivante :

  1. Effectuer l'exportation à partir d'une instance dupliquée avec accès en lecture. Cette option peut être appropriée si vous effectuez des exportations fréquemment (tous les jours ou plus souvent), mais que la quantité de données exportées est faible. Pour effectuer une exportation depuis une instance dupliquée avec accès en lecture, utilisez les fonctions d'exportation de la console Google Cloud, de gcloud ou de l'API REST sur votre instance dupliquée avec accès en lecture. Pour en savoir plus sur la création et la gestion des instances dupliquées avec accès en lecture, consultez la page Créer des instances dupliquées avec accès en lecture.

  2. Utiliser l'exportation sans serveur. Avec l'exportation sans serveur, Cloud SQL crée une instance temporaire distincte pour décharger l'opération d'exportation. Le déchargement de l'opération d'exportation permet aux bases de données de l'instance principale de continuer à diffuser des requêtes et d'effectuer des opérations au débit de performances habituel. Une fois l'exportation des données terminée, l'instance temporaire est automatiquement supprimée. Cette option est judicieuse si vous effectuez une exportation ponctuelle d'une grande base de données. Utilisez les fonctions d'exportation de la console Google Cloud, de gcloud ou de l'API REST avec l'option offload pour effectuer une opération d'exportation sans serveur.

    Lors d'une opération d'exportation sans serveur, vous pouvez effectuer d'autres opérations, telles que la modification, l'importation et le basculement d'instances. Toutefois, si vous sélectionnez delete, l'opération d'exportation s'arrête après la suppression de l'instance et n'exporte aucune donnée.

    Consultez le tableau suivant pour découvrir les opérations pouvant être bloquées lorsqu'une opération d'exportation sans serveur est en cours d'exécution :
    Opération en cours Nouvelle opération Blocage ?
    Toute opération Exportation sans serveur Yes
    Exportation sans serveur Toute opération, à l'exception de l'exportation sans serveur Non
    Toute opération, à l'exception de l'exportation sans serveur Toute opération, à l'exception de l'exportation sans serveur Yes

    Une exportation sans serveur prend plus de temps qu'une exportation standard, car la création de l'instance temporaire prend du temps. La durée minimale est de 5 minutes, mais pour les bases de données plus volumineuses, cela peut prendre plus de temps. Prenez en compte l'impact sur le temps, les performances et les coûts avant de déterminer le type d'exportation à utiliser.

Utiliser les indicateurs appropriés lors de la création d'un fichier de vidage SQL

Si vous n'utilisez pas les bonnes options lorsque vous exportez vos données vers un fichier de vidage SQL, l'importation peut échouer. Pour en savoir plus sur la création d'un fichier de vidage SQL à importer dans Cloud SQL, consultez la section Créer un fichier de vidage SQL.

Compresser les données afin de réduire les coûts

Cloud SQL permet d'importer et d'exporter des fichiers compressés ou non. Grâce à la compression, vous pouvez économiser un espace de stockage considérable sur Cloud Storage et réduire les coûts de stockage, en particulier lorsque vous exportez des instances volumineuses.

Lorsque vous exportez un fichier de vidage SQL ou CSV, utilisez l'extension de fichier .gz pour compresser les données. Lorsque vous importez un fichier avec une extension .gz, il est automatiquement décompressé.

Réduire les processus d'importation et d'exportation de longue durée

L'exécution d'opérations d'importation dans Cloud SQL et d'exportations à partir de Cloud SQL peut prendre beaucoup de temps selon la taille des données traitées. Cela peut avoir les conséquences suivantes :

  • Vous ne pouvez pas arrêter une opération d'instance Cloud SQL de longue durée.
  • Vous ne pouvez effectuer qu'une seule opération d'importation ou d'exportation à la fois pour chaque instance, tandis qu'une importation ou une exportation de longue durée bloque d'autres opérations, telles que les sauvegardes automatiques quotidiennes. Les exportations sans serveur vous permettent d'exécuter d'autres opérations, comme la modification d'instances, l'importation, le basculement et le déblocage des sauvegardes quotidiennes.

Vous pouvez réduire le temps nécessaire à l'exécution de chaque opération en utilisant la fonctionnalité d'importation ou d'exportation Cloud SQL avec de plus petits lots de données.

Pour les exportations, vous pouvez effectuer l'exportation à partir d'une instance dupliquée avec accès en lecture ou utiliser l'exportation sans serveur afin de minimiser l'impact sur les performances de la base de données et de permettre que d'autres opérations s'exécutent sur votre instance pendant l'exécution d'une exportation.

Pour obtenir plus de conseils, consultez la section Diagnostiquer les problèmes liés aux instances Cloud SQL.

Utiliser InnoDB

InnoDB est le seul moteur de stockage compatible avec les instances MySQL.

Vous pouvez convertir vos tables du format MyISAM au format InnoDB en redirigeant la sortie de "mysqldump" via un script sed, comme décrit ci-dessous :

mysqldump --databases [DATABASE_NAME] \
-h [INSTANCE_IP] -u [USERNAME] -p [PASSWORD] \
--hex-blob --default-character-set=utf8mb4 | sed 's/ENGINE=MyISAM/ENGINE=InnoDB/g' > [DATABASE_FILE].sql

Tâches d'importation et de migration MySQL contenant des métadonnées avec la clause DEFINER

Étant donné qu'une tâche d'importation ou de migration MySQL ne migre pas les données utilisateur, les sources et les fichiers de vidage contenant des métadonnées définies par les utilisateurs avec la clause DEFINER ne seront pas importés ni transférés, car les utilisateurs n'existent pas encore dans l'instance cible.

Pour identifier les valeurs DEFINER présentes dans vos métadonnées, utilisez les requêtes suivantes (ou effectuez une recherche dans votre fichier de vidage) et vérifiez la présence d'entrées pour root%localhost ou d'utilisateurs qui n'existent pas dans l'instance cible.

SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.EVENTS;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.ROUTINES;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.TRIGGERS;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.VIEWS;

Pour exécuter une tâche d'importation ou de migration à partir d'une source qui inclut ces métadonnées, vous pouvez effectuer l'une des opérations suivantes :

  • Créez les utilisateurs sur l'instance Cloud SQL cible avant de démarrer votre tâche d'importation ou de migration.
  • Mettez à jour la clause DEFINER sur INVOKER sur votre instance ou fichier de vidage MySQL source avant de démarrer votre tâche d'importation ou de migration.

Vérifier la base de données importée

Une fois l'importation terminée, connectez-vous à votre base de données et exécutez les commandes de base de données appropriées pour vous assurer que le contenu est correct. Par exemple, connectez et répertoriez les bases de données, les tables et les entrées spécifiques.

Limites connues

Pour obtenir la liste des limites connues, consultez la section Problèmes d'importation et d'exportation des données.

Automatiser les opérations d'exportation

Bien que Cloud SQL ne dispose pas d'une méthode intégrée pour automatiser les exportations de base de données, vous pouvez créer votre propre outil d'automatisation à l'aide de plusieurs composants Google Cloud. Pour en savoir plus, consultez ce tutoriel.

Dépannage

Résoudre les problèmes liés aux opérations d'importation

Problème Dépannage
HTTP Error 409: Operation failed because another operation was already in progress. Une opération est déjà en attente pour votre instance. Il n'est possible d'exécuter qu'une seule opération à la fois. Envoyez votre requête lorsque l'opération en cours est terminée.
L'opération d'importation prend trop de temps. Un trop grand nombre de connexions actives peut interférer avec les opérations d'importation.

Fermez les opérations inutilisées. Vérifiez l'utilisation du processeur et de la mémoire de votre instance Cloud SQL pour vous assurer que de nombreuses ressources sont disponibles. Le meilleur moyen de s'assurer de la présence d'un nombre maximal de ressources pour l'opération d'importation consiste à redémarrer l'instance avant de lancer l'importation.

Un redémarrage :

  • ferme toutes les connexions ;
  • met fin à toutes les tâches susceptibles de consommer des ressources.
Une opération d'importation peut échouer lorsqu'un ou plusieurs utilisateurs référencés dans le fichier de vidage n'existent pas. Avant d'importer un fichier de vidage, tous les utilisateurs de la base de données qui possèdent des objets ou disposent d'autorisations sur les objets qu'elle contient doivent exister dans la base de données cible. Si ce n'est pas le cas, l'opération d'importation ne parvient pas à recréer les objets en rétablissant les propriétaires ou les autorisations d'origine.

Créez les utilisateurs de la base de données avant de l'importer.
Une importation échoue et une erreur indiquant qu'une table n'existe pas s'affiche. Les tables peuvent comporter des dépendances de clés étrangères sur d'autres tables. En fonction de l'ordre des opérations, il est possible qu'une ou plusieurs de ces tables n'existent pas encore lors de l'importation.

Solutions possibles

Ajoutez la ligne suivante au début du fichier de vidage :


SET FOREIGN_KEY_CHECKS=0;

Ajoutez également cette ligne à la fin du fichier de vidage :


SET FOREIGN_KEY_CHECKS=1;

Ces paramètres désactivent les vérifications de l'intégrité des données pendant que l'opération d'importation est en cours, et les réactivent une fois les données chargées. Cela n'affecte pas l'intégrité des données de la base de données, car elles ont déjà été validées lors de la création du fichier de vidage.

Résoudre les problèmes liés aux opérations d'exportation

Problème Dépannage
HTTP Error 409: Operation failed because another operation was already in progress. Une opération est déjà en attente pour votre instance. Il n'est possible d'exécuter qu'une seule opération à la fois. Envoyez votre requête lorsque l'opération en cours est terminée.
HTTP Error 403: The service account does not have the required permissions for the bucket. Assurez-vous que le bucket existe et que le compte de service de l'instance Cloud SQL (qui effectue l'exportation) dispose du rôle Storage Object Creator (roles/storage.objectCreator) pour autoriser l'exportation vers le bucket. Consultez la page Rôles IAM pour Cloud Storage.
L'exportation au format CSV a fonctionné, mais pas l'exportation au format SQL. Les formats CSV et SQL sont exportés de manière différente. Comme le format SQL exporte l'intégralité de la base de données, l'exportation prend probablement plus de temps. Le format CSV vous permet de définir les éléments de la base de données à exporter.

Exportez uniquement les données dont vous avez besoin à l'aide du format CSV.
L'exportation prend trop de temps. Cloud SQL n'est pas compatible avec les opérations synchrones simultanées.

Utilisez le déchargement des exportations. En règle générale, lors du déchargement des exportations, au lieu d'exécuter une exportation sur l'instance source, Cloud SQL lance une instance de déchargement pour effectuer l'exportation. Le déchargement des exportations présente plusieurs avantages, y compris une amélioration des performances sur l'instance source et le déblocage des opérations d'administration pendant l'exportation. Avec le déchargement des exportations, la latence totale peut augmenter en fonction du temps nécessaire à l'affichage de l'instance de déchargement. En règle générale, la latence n'est pas significative pour les exportations de taille raisonnable. Toutefois, si votre exportation est suffisamment petite, vous pouvez constater une augmentation de la latence.
Vous souhaitez automatiser les exportations. Cloud SQL ne permet pas d'automatiser les exportations.

Vous pouvez créer votre propre système d'exportation automatisé à l'aide de produits Google Cloud tels que Cloud Scheduler, Pub/Sub et Cloud Functions, de manière semblable à cet article sur l'automatisation des sauvegardes.

Étapes suivantes