Utilisez l'utilitaire dumpInstance MySQL Shell pour exporter une instance MySQL vers un seau de stockage d'objets.

1. Exécutez l'interpréteur de commandes MySQL sur l'ordinateur client qui contient le fichier de configuration de l'interface de ligne de commande.
2. Activez le type d'entrée JavaScript en entrant \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 : Spécifie la commande de l'interpréteur de commandes permettant d'établir une nouvelle connexion.
   • <UserName> : Spécifie le nom d'utilisateur de l'instance MySQL.
   • <MySQLIPAddress> : Spécifie l'adresse IP ou le nom d'hôte de l'instance MySQL.
4. (Étape facultative recommandée) Exécutez la commande suivante pour tester l'exécution en exportant l'ensemble de l'instance MySQL. Il vérifie les problèmes de compatibilité du système de base de données et répertorie ces problèmes ainsi que 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 avec succès lorsque l'option ocimds est activée.
5. Exécutez la commande suivante pour exporter toute l'instance MySQL vers un seau de stockage d'objets :

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

   • util.dumpInstance : Spécifie la commande pour exporter toute une instance MySQL.
   • <BucketPrefix> : (Facultatif) Ajoute un préfixe aux fichiers chargés dans le seau. Si cela est spécifié, les fichiers sont chargés dans le seau défini avec le préfixe au format suivant : <BucketPrefix>/filename, comme un chemin de fichier. Par exemple, si <BucketPrefix> est réglé à test, chaque fichier chargé dans le seau défini, <MDSBucket>, l'est en tant que test/filename. Si vous téléchargez le fichier, le préfixe est traité comme un dossier lors du téléchargement. Pour les exportations locales, ce paramètre est le chemin d'accès au répertoire local vers lequel vous souhaitez effectuer l'exportation.

     Bien que le contenu de ce paramètre soit facultatif, les guillemets 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 : Spécifie le nom sensible à la casse du seau de stockage d'objets vers lequel effectuer l'exportation. L'interpréteur de commandes MySQL utilise les informations de location et d'utilisateur définies dans le fichier config.
   • threads : (Facultatif) Spécifie le nombre d'unités d'exécution de traitement à utiliser pour cette tâche. La valeur par défaut est 4. Pour optimiser la performance, il est recommandé de définir ce paramètre sur le nombre de coeurs d'UC disponibles sur le serveur de base de données.
   • ocimds : Vérifie la compatibilité des données avec le service HeatWave. Lorsque cette option est réglée à true, vous ne pouvez pas exporter une instance si elle est incompatible avec le service HeatWave.
     Note
     
     L'importation des données dans un système de base de données HeatWave avec l'utilitaire util.loadDump nécessite que le vidage soit créé avec l'option ocimds.
   • compatibility : Liste de paramètres qui spécifient 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. Voir Vérifications de compatibilité.
   • bytesPerChunk : (Facultatif) Pour les jeux de données volumineux, il est recommandé d'utiliser ce paramètre pour définir des tranches de mémoire plus grandes. La taille de tranche de mémoire par défaut est de 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 montre 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 la modification manuelle du schéma avant son chargement 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 énoncés CREATE TABLE qui utilisent des moteurs de stockage incompatible et les remplace par InnoDB.
• strip_definers : Retire la clause "DEFINER=account" des vues, sous-programmes, événements et déclencheurs. Le service HeatWave nécessite des privilèges spéciaux pour créer ces objets avec un créateur autre que l'utilisateur qui charge le schéma. Retirer la clause DEFINER permet de créer ces objets avec cet auteur par défaut. La clause SQL SECURITY des vues et des sous-programmes est modifiée de DEFINER en INVOKER. Ainsi, les autorisations d'accès du compte qui les interroge ou les appelle sont appliquées, au lieu de celles de l'utilisateur qui les a créés. Si votre modèle de sécurité de base de données nécessite que les vues et les sous-programmes aient plus de privilèges que l'appelant, modifiez manuellement le schéma avant de le charger. Voir DEFINER et Sécurité SQL.
• strip_restricted_grants : Certains privilèges sont limités dans le service HeatWave. Il s'agit des privilèges RELOAD, FILE, SUPER, BINLOG_ADMIN et SET_USER_ID. Vous ne pouvez pas créer d'utilisateurs accordant ces privilèges. Cette option retire ces privilèges des énoncés GRANT vidés.
• skip_invalid_accounts : Vous ne pouvez pas exporter un utilisateur pour lequel aucun mot de passe n'est défini. Cette option ignore de tels utilisateurs.
• strip_tablespaces : Le service HeatWave comporte des restrictions sur les espaces-tables. Cette option retire l'option TABLESPACE des énoncés CREATE TABLE, de sorte que toutes les tables sont créées dans leur espace-table 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 avez l'intention d'exporter des données à utiliser dans un système de base de données hautement disponible, ajoutez des clés primaires si elles ne sont pas définies dans les tables. Cet indicateur de compatibilité ajoute des clés primaires invisibles à chaque table qui en a besoin. Voir Préalables.
  • 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 votre vidage.

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