Mit dem Utility MySQL der Shell dumpInstance können Sie eine MySQL-Instanz in einen Objektspeicher-Bucket exportieren.

1. Führen Sie die Shell MySQL auf dem Clientrechner aus, der die CLI-Konfigurationsdatei enthält.
2. Wechseln Sie zum JavaScript-Eingabetyp, indem Sie \js eingeben und die Eingabetaste drücken.
3. Führen Sie den folgenden Befehl aus, um eine globale Session zu starten, indem Sie eine Verbindung zur Instanz MySQL herstellen:

   \c <UserName>@<MySQLIPAddress>

   • \c: Gibt den Shell-Befehl zum Herstellen einer neuen Verbindung an.
   • <UserName>: Gibt den Benutzernamen der MySQL-Instanz an.
   • <MySQLIPAddress>: Gibt die IP-Adresse oder den Hostnamen der MySQL-Instanz an.
4. (Empfohlener optionaler Schritt) Führen Sie den folgenden Befehl aus, um die Ausführung des Exports der gesamten MySQL-Instanz zu testen. Es prüft die Kompatibilitätsprobleme des DB-Systems und listet diese Probleme zusammen mit den vorgeschlagenen Lösungen in der Ausgabe auf.

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

   Identifizieren Sie alle Kompatibilitätsoptionen, mit denen die gefundenen Probleme behoben werden. Sie müssen diese Kompatibilitätsoptionen einschließen, um die Instanz MySQL erfolgreich zu exportieren, wenn die Option ocimds aktiviert ist.
5. Führen Sie den folgenden Befehl aus, um die gesamte MySQL-Instanz in einen Objektspeicher-Bucket zu exportieren:

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

   • util.dumpInstance: Gibt den Befehl zum Exportieren einer gesamten MySQL-Instanz an.
   • <BucketPrefix>: (Optional) Fügt den in den Bucket hochgeladenen Dateien ein Präfix hinzu. Wenn dies angegeben wird, werden die Dateien mit dem Präfix im folgenden Format in den definierten Bucket hochgeladen: <BucketPrefix>/filename, ähnlich wie ein Dateipfad. Beispiel: Wenn <BucketPrefix> auf test gesetzt ist, wird jede Datei, die in den definierten Bucket <MDSBucket> hochgeladen wird, als test/filename hochgeladen. Wenn Sie die Datei herunterladen, wird das Präfix im Download als Ordner behandelt. Bei lokalen Exporten ist dieser Parameter der Pfad zu dem lokalen Verzeichnis, in das Sie exportieren möchten.

     Der Inhalt dieses Parameters ist optional, nicht jedoch die Anführungszeichen. Auch wenn Sie kein Präfix verwenden möchten, müssen Sie die Anführungszeichen in die Befehlssyntax aufnehmen.

   • osBucketName: Gibt den Namen des zu exportierenden Objektspeicher-Buckets an, wobei die Groß-/Kleinschreibung beachtet wird. MySQL Shell verwendet die Mandanten- und Benutzerinformationen, die in der Datei config definiert sind.
   • threads: (Optional) Gibt die Anzahl der Verarbeitungsthreads an, die für diese Aufgabe verwendet werden. Der Standardwert ist 4. Für eine optimale Performance wird empfohlen, diesen Parameter auf die Anzahl der auf dem Datenbankserver verfügbaren CPU-Cores zu setzen.
   • ocimds: Prüfen Sie die Daten auf Kompatibilität mit dem HeatWave-Service. Wenn dieser Wert auf true gesetzt ist, können Sie eine Instanz nicht exportieren, wenn sie mit dem HeatWave-Service inkompatibel ist.
     Hinweis
     
     Wenn Sie die Daten mit dem Utility util.loadDump in ein HeatWave-DB-System importieren, muss der Dump mit der Option ocimds erstellt werden.
   • compatibility: Listen Sie die Parameter auf, die angeben, welche Änderungen an den exportierten Daten vorgenommen werden. Geben Sie die Liste der Kompatibilitätsoptionen an, die im Dryrun-Modus vorgeschlagen werden. Siehe Kompatibilitätsprüfungen.
   • bytesPerChunk: (Optional) Bei großen Datasets wird empfohlen, mit diesem Parameter größere Chunks zu definieren. Die standardmäßige Chunk-Größe beträgt 64 MB. Beispiel: bytesPerChunk: 128M, gibt eine Chunk-Größe von 128 MB an.

Der HeatWave-Service verfügt über verschiedene sicherheitsbezogene Einschränkungen, die in einer MySQL-Instanz nicht vorhanden sind. Verwenden Sie die Option ocimds des Dumputilitys, um Kompatibilitätsprüfungen für die ausgegebenen Daten durchzuführen. Bei Problemen bricht das Utility den Dump ab, erstellt eine detaillierte Liste der Probleme und schlägt Schritte zur Behebung vor.

Der folgende Befehl zeigt, wie Sie Kompatibilitätsprüfungen mit der Option ocimds im Modus dryrun durchführen. Bei einigen Problemen, die mit der Option ocimds gefunden werden, müssen Sie möglicherweise das Schema manuell bearbeiten, damit es in den HeatWave-Service geladen werden kann.

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

Nachdem Sie die Kompatibilitätsprobleme und Kompatibilitätsoptionen identifiziert haben, können Sie die Optionen im Befehl angeben, der die Daten exportiert.

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

Mit den folgenden kommagetrennten Kompatibilitätsoptionen können Sie die exportierten Daten automatisch ändern. Dadurch werden einige dieser Kompatibilitätsprobleme behoben:

• force_innodb: Der HeatWave-Service unterstützt nur die Speicher-Engine InnoDB. Diese Option ändert die ENGINE-Klausel von CREATE TABLE-Anweisungen, die inkompatible Speicher-Engines verwenden, und ersetzt sie durch InnoDB.
• strip_definers: Entfernt die Klausel "DEFINER=account" aus Ansichten, Routinen, Ereignissen und Triggern. Der HeatWave-Service erfordert spezielle Berechtigungen, um diese Objekte mit einem anderen Definer als dem Benutzer zu erstellen, der das Schema lädt. Durch Entfernen der DEFINER-Klausel werden diese Objekte mit diesem Standard-Definer erstellt. Für Ansichten und Routinen wurde die SQL SECURITY-Klausel von DEFINER in INVOKER geändert. Dadurch wird sichergestellt, dass die Zugriffsberechtigungen des Accounts verwendet werden, der diese abfragt oder aufruft, und nicht die des Benutzers, der sie erstellt hat. Wenn für Ihr Datenbanksicherheitsmodell Ansichten und Routinen mit mehr Berechtigungen als für den jeweiligen Invoker erforderlich sind, müssen Sie das Schema manuell ändern, bevor Sie es laden. Siehe DEFINER und SQL-Sicherheit.
• strip_restricted_grants: Einige Berechtigungen sind im HeatWave-Service eingeschränkt. Berechtigungen wie RELOAD, FILE, SUPER, BINLOG_ADMIN und SET_USER_ID. Sie können keine Benutzer erstellen, denen diese Berechtigungen erteilt werden. Mit dieser Option werden diese Berechtigungen aus Dumps von GRANT-Anweisungen entfernt.
• skip_invalid_accounts: Sie können keinen Benutzer exportieren, für den kein Kennwort definiert ist. Mit dieser Option werden solche Benutzer übersprungen.
• strip_tablespaces: Der HeatWave-Service weist einige Einschränkungen für Tablespaces auf. Mit dieser Option wird die Option TABLESPACE aus CREATE TABLE-Anweisungen geleert, sodass alle Tabellen in ihren Default Tablespaces erstellt werden.
• Primärschlüssel-Flags:
  • create_invisible_pks: Primärschlüssel sind für High Availability-DB-Systeme erforderlich. Wenn Sie Daten zur Verwendung in einem hochverfügbaren DB-System exportieren möchten, fügen Sie Primärschlüssel hinzu, wenn sie nicht für die Tabellen definiert sind. Mit diesem Kompatibilitäts-Flag werden unsichtbare Primärschlüssel zu jeder Tabelle hinzugefügt, für die sie erforderlich sind. Siehe Voraussetzungen.
  • ignore_missing_pks: Wenn Sie nicht in ein High-Availability-DB-System importieren möchten, ignoriert dieses Kompatibilitäts-Flag fehlende Primärschlüssel in Ihrem Dump.

Außerdem werden die Optionen DATA DIRECTORY, INDEX DIRECTORY und ENCRYPTION in CREATE TABLE-Anweisungen in DDL-Skripten immer auskommentiert, wenn die Option ocimds aktiviert ist.