Servez-vous de l'utilitaire dumpInstance shell MySQL pour exporter une instance MySQL vers un bucket Object Storage.

1. Exécutez le shell MySQL sur l'ordinateur client contenant le fichier de configuration de l'interface de ligne de commande.
2. Passez au type d'entrée JavaScript en saisissant \js et en appuyant sur Entrée.
3. Exécutez la commande suivante pour démarrer une session globale en vous connectant à l'instance MySQL :

   \c <UserName>@<MySQLIPAddress>

   • \c : indique la commande Shell permettant d'établir une nouvelle connexion.
   • <UserName> : indique le nom utilisateur de l'instance MySQL.
   • <MySQLIPAddress> : indique l'adresse IP ou le nom d'hôte de l'instance MySQL.
4. (Etape facultative recommandée) Exécutez la commande suivante pour tester l'exécution de l'export de l'ensemble de l'instance MySQL. Il recherche les problèmes de compatibilité du système de base de données et répertorie ces problèmes avec les solutions suggérées dans la sortie.

   util.dumpInstance("", {mode: "dryrun", ocimds: true})

   Identifiez toutes les options de compatibilité qui suppriment les problèmes détectés. Vous devez inclure ces options de compatibilité pour exporter l'instance MySQL lorsque l'option ocimds est activée.
5. Exécutez la commande suivante pour exporter l'intégralité de l'instance MySQL vers un bucket Object Storage :

   util.dumpInstance("<BucketPrefix>", {osBucketName: "<MDSBucket>", threads: <ThreadSize>, ocimds: true, 
       compatibility: ["<comma separated list of compatibility options>], bytesPerChunk: "<ChunkSize>"})

   • util.dumpInstance : indique la commande permettant d'exporter l'intégralité d'une instance MySQL.
   • <BucketPrefix> : (facultatif) ajoute un préfixe aux fichiers téléchargés vers le bucket. Si cette option est spécifiée, les fichiers sont téléchargés vers le bucket défini avec le préfixe, au format suivant : <BucketPrefix>/filename, comme pour un chemin de fichier. Par exemple, si <BucketPrefix> est défini sur test, chaque fichier téléchargé vers le bucket défini, <MDSBucket>, prend la forme test/filename. Si vous téléchargez le fichier en local, le préfixe est traité comme un dossier dans le téléchargement. Pour les exports locaux, ce paramètre correspond au chemin du répertoire local d'export.

     Bien que le contenu de ce paramètre soit facultatif, les apostrophes ne le sont pas. Même si vous n'avez pas l'intention d'utiliser un préfixe, vous devez inclure les guillemets dans la syntaxe de la commande.

   • osBucketName : indique le nom sensible à la casse du bucket Object Storage vers lequel effectuer l'export. MySQL Shell utilise la location et les informations utilisateur définies dans le fichier config.
   • threads (facultatif) : indique le nombre de threads de traitement à utiliser pour la tâche. La valeur par défaut est 4. Pour de meilleures performances, il est recommandé de définir ce paramètre sur le nombre de coeurs de processeur disponibles sur le serveur de base de données.
   • ocimds : vérifie la compatibilité des données avec le service HeatWave. Lorsque cette valeur est définie sur true, vous ne pouvez pas exporter une instance si elle est incompatible avec le service HeatWave.
     Remarque
     
     L'import des données dans un système de base de données HeatWave à l'aide de l'utilitaire util.loadDump requiert la création du fichier dump avec l'option ocimds.
   • compatibility : répertoriez les paramètres indiquant les modifications apportées aux données exportées. Vous devez spécifier la liste des options de compatibilité suggérées en mode dryrun. Reportez-vous à Vérifications de compatibilité.
   • bytesPerChunk : (facultatif) pour les ensembles de données volumineux, il est recommandé d'utiliser ce paramètre afin de définir des blocs plus importants. La taille de bloc par défaut est 64 Mo. Par exemple, bytesPerChunk: 128M, indique une taille de bloc de 128 Mo.

Le service HeatWave comporte plusieurs restrictions liées à la sécurité qui ne sont pas présentes dans une instance MySQL. Utilisez l'option ocimds de l'utilitaire de vidage pour effectuer des vérifications de compatibilité sur les données vidées. En cas de problème, l'utilitaire abandonne le vidage et génère une liste détaillée des problèmes et suggère des étapes pour les corriger.

La commande suivante indique comment effectuer des vérifications de compatibilité à l'aide de l'option ocimds en mode dryrun. Certains problèmes détectés par l'option ocimds peuvent nécessiter que vous modifiiez manuellement le schéma pour qu'il puisse être chargé dans le service HeatWave.

util.dumpInstance("", {mode: "dryrun", ocimds: true})

Après avoir identifié les problèmes de compatibilité et les options de compatibilité, vous pouvez spécifier les options de la commande qui exporte les données.

util.dumpInstance("<BucketPrefix>", {osBucketName: "<MDSBucket>", ocimds: true, 
    compatibility: ["force_innodb", "strip_definers", "strip_restricted_grants", 
    "skip_invalid_accounts", "strip_tablespaces", "ignore_missing_pks"] } )

Vous pouvez utiliser les options de compatibilité séparées par des virgules suivantes pour modifier automatiquement les données exportées, ce qui résout certains des problèmes de compatibilité suivants :

• force_innodb : le service HeatWave prend uniquement en charge le moteur de stockage InnoDB. Cette option modifie la clause ENGINE des instructions CREATE TABLE qui utilisent des moteurs de stockage incompatibles. Elle remplace ces derniers par InnoDB.
• strip_definers : supprime la clause "DEFINER=account" des vues, des routines, des événements et des déclencheurs. Le service HeatWave nécessite des privilèges spéciaux pour créer les objets avec un créateur autre que l'utilisateur qui charge le schéma. Si la clause DEFINER est supprimée, les objets sont créés avec le créateur par défaut. Dans la clause SQL SECURITY des vues et des routines, DEFINER est remplacé par INVOKER. Cela garantit que les droits d'accès du compte interrogeant ou appelant ces objets sont appliqués, au lieu de ceux de l'utilisateur qui les a créés. Si votre modèle de sécurité de base de données requiert que les vues et les routines disposent de plus de privilèges que leur appelant, modifiez le schéma manuellement avant de le charger. Reportez-vous à DEFINER et à Sécurité SQL.
• strip_restricted_grants : certains privilèges sont limités dans le service HeatWave. Privilèges tels que RELOAD, FILE, SUPER, BINLOG_ADMIN et SET_USER_ID. Vous ne pouvez pas octroyer ces privilèges aux utilisateurs que vous créez. Cette option supprime ces privilèges des instructions GRANT vidées.
• skip_invalid_accounts : vous ne pouvez pas exporter un utilisateur pour lequel aucun mot de passe n'est défini. Cette option permet d'ignorer ce type d'utilisateur.
• strip_tablespaces : le service HeatWave comporte des restrictions sur les tablespaces. Cette option supprime l'option TABLESPACE des instructions CREATE TABLE afin que toutes les tables soient créées dans leurs tablespaces par défaut.
• Indicateurs de clé primaire :
  • create_invisible_pks : les clés primaires sont requises par les systèmes de base de données haute disponibilité. Si vous prévoyez d'exporter des données pour leur utilisation dans un système de base de donnée hautement disponible, ajoutez les clés primaires si elles ne sont pas définies sur les tables. Cet indicateur de compatibilité ajoute des clés primaires invisibles à chaque table qui en a besoin. Reportez-vous à Prérequis.
  • ignore_missing_pks : si vous n'avez pas l'intention d'importer dans un système de base de données haute disponibilité, cet indicateur de compatibilité ignore les clés primaires manquantes dans le fichier dump.

En outre, les options DATA DIRECTORY, INDEX DIRECTORY et ENCRYPTION des instructions CREATE TABLE sont toujours mises en commentaire dans les scripts DDL si l'option ocimds est activée.