MySQL Shell 8.0  /  MySQL Shell ユーティリティ  /  ダンプロードユーティリティ

このページは機械翻訳したものです。

8.6 ダンプロードユーティリティ

MySQL Shell ダンプロードユーティリティ util.loadDump() は、MySQL Shell 8.0.21 で導入され、MySQL Database Service DB システム (MySQL DB システム、短縮形) または MySQL Shell セクション8.5「インスタンスダンプユーティリティ、スキーマダンプユーティリティおよびテーブルダンプユーティリティ」 を使用してダンプされたスキーマまたはテーブルの MySQL Server インスタンスへのインポートをサポートしています。 ダンプロードユーティリティでは、リモート記憶域からのデータストリーミング、テーブルまたはテーブルチャンクのパラレルロード、進行状況トラッキング、再開およびリセット機能、およびダンプの実行中の同時ロードのオプションが提供されます。

MySQL DB システムにインポートするには、ダンプロードユーティリティを実行する MySQL Shell インスタンスが、MySQL DB システムにアクセスできる Oracle Cloud Infrastructure Compute インスタンスにインストールされている必要があります。 ダンプファイルが Oracle Cloud Infrastructure Object Storage バケットにある場合は、コンピュートインスタンスからオブジェクトストレージバケットにアクセスできます。 ダンプファイルがローカルシステムにある場合は、コンピュートインスタンスに選択したオペレーティングシステムに応じて、選択したコピーユーティリティを使用して Oracle Cloud Infrastructure Compute インスタンスに転送する必要があります。 MySQL Database Service との互換性のために、MySQL Shell インスタンスダンプユーティリティまたはスキーマダンプユーティリティで ocimds オプションを true に設定してダンプが作成されていることを確認します。MySQL Shell テーブルダンプユーティリティでは、このオプションは使用しません。

注記
  1. ダンプロードユーティリティでは LOAD DATA LOCAL INFILE ステートメントが使用されるため、インポート中は、ターゲット MySQL インスタンスの local_infile システム変数のグローバル設定を ON にする必要があります。 デフォルトでは、このシステム変数は標準の MySQL DB システム構成で ON に設定されています。

  2. ターゲットの MySQL インスタンスでは、ダンプロードユーティリティは、sql_require_primary_key システム変数が ON に設定されているかどうかをチェックし、設定されている場合は、ダンプファイルに主キーのないテーブルがあるとエラーを返します。 デフォルトでは、このシステム変数は標準の MySQL DB システム構成で OFF に設定されています。

  3. ダンプロードユーティリティは、ソース MySQL インスタンスの gtid_executed GTID セットをターゲット MySQL インスタンスに自動的に適用しません。 GTID セットは、@.json ダンプファイルの gtidExecuted フィールドとして、MySQL Shell インスタンスダンプユーティリティ、スキーマダンプユーティリティまたはテーブルダンプユーティリティのダンプメタデータに含まれます。 レプリケーションで使用するためにこれらの GTID をターゲット MySQL インスタンスに適用するには、MySQL Shell 8.0.22 から、updateGtidSet オプションを使用して、ターゲット MySQL インスタンスのリリースに応じて gtid_purged GTID セットに追加するか、gtid_purged GTID セットを置換します。 権限の制限のため、これは現在 MySQL DB システムではサポートされていません。 MySQL Shell 8.0.21 では GTID セットを手動でインポートできますが、これは MySQL DB システムではサポートされていません。

インスタンスダンプユーティリティまたはスキーマダンプユーティリティによって生成される出力の場合、MySQL Shell ダンプロードユーティリティは DDL ファイルおよびタブ区切りの .tsv データファイルを使用して、ターゲットの MySQL インスタンスにサーバーインスタンスまたはスキーマを設定し、データをロードします。 DDL ファイルのみを含むダンプまたはデータファイルのみを使用して、これらのタスクを個別に実行できます。 ダンプロードユーティリティでは、DDL ファイルおよびデータファイルを、両方の種類のファイルを含む通常のダンプから個別に適用することもできます。

MySQL Shell テーブルダンプユーティリティによって生成される出力の場合、MySQL Shell 8.0.23 からのダンプには、最初にテーブルを含むスキーマの設定に必要な情報が含まれます。 デフォルトでは、そのリリースから、ターゲットの MySQL インスタンスにスキーマがまだ存在しない場合は再作成されます。 または、ダンプロードユーティリティで schema オプションを指定して、ターゲット MySQL インスタンスの代替スキーマにテーブルをロードできます。 MySQL Shell 8.0.22 では、テーブルダンプユーティリティファイルにスキーマ情報が含まれていないため、ターゲットスキーマがターゲットの MySQL インスタンスに存在する必要があります。 このリリースでは、デフォルトでグローバルシェルセッションの現在のスキーマがターゲットスキーマとして使用されるか、schema オプションを使用してスキーマに名前を付けることができます。

ダンプロードユーティリティのその他のオプションを使用して、インポートをカスタマイズできます:

  • インポートまたはインポートから除外する個々のテーブルまたはスキーマを選択できます。

  • ユーザーとそのロールおよび権限はデフォルトで除外されますが、インポートを選択できます。

  • ターゲット MySQL インスタンスのデータには、ダンプファイルで使用されているものとは異なる文字セットを指定できます。

  • データがすでにロードされている場合でも、ANALYZE TABLE ヒストグラムを更新できます。

  • SET sql_log_bin=0 ステートメントを使用したインポート中に、ターゲット MySQL インスタンスでバイナリロギングをスキップすることを選択できます。

選択したダンプロードオプションのセットを使用してドライランを実行し、これらのオプションを使用してユーティリティを実際に実行したときに実行されるアクションを表示できます。

waitDumpTimeout オプションを使用すると、まだ作成中のダンプを適用できます。 テーブルは使用可能になるとロードされ、新しいデータがダンプの場所に到着しなくなった後、ユーティリティは指定された秒数待機します。 タイムアウトが経過すると、ユーティリティはダンプが完了したとみなし、インポートを停止します。

インポートの進行状態は永続的な進行状態ファイルに格納され、正常に完了したステップと中断または失敗したステップが記録されます。 デフォルトでは、進捗状態ファイルは load-progress.server_uuid.json という名前でダンプディレクトリに作成されますが、別の名前と場所を選択することもできます。 ダンプロードユーティリティは、ダンプのインポートを再開または再試行するときに進行状態ファイルを参照し、完了したステップをスキップします。 部分的にロードされたテーブルの重複除外は自動的に管理されます。 Ctrl + C を使用して進行中のダンプを中断した場合、そのキーの組合せを最初に使用しても、ユーティリティによって新しいタスクは開始されませんが、既存のタスクは続行されます。 Ctrl + C を再度押すと、既存のタスクが停止し、エラーメッセージが表示されます。 いずれの場合も、ユーティリティは停止した場所からインポートを再開できます。

進行状態をリセットしてダンプのインポートを最初から再開することを選択できますが、この場合、ユーティリティはすでに作成されて重複除外を管理していないオブジェクトをスキップしません。 これを行う場合、正しいインポートを保証するには、以前にロードされたすべてのオブジェクト (スキーマ、テーブル、ユーザー、ビュー、トリガー、ルーチン、イベントなど) をターゲット MySQL インスタンスから手動で削除する必要があります。 それ以外の場合、ダンプファイル内のオブジェクトがターゲット MySQL インスタンスにすでに存在すると、インポートはエラーで停止します。 適切な注意が必要な場合は、ignoreExistingObjects オプションを使用してユーティリティレポートでオブジェクトを複製しますが、スキップしてインポートを続行できます。 ユーティリティでは、ターゲット MySQL インスタンスとダンプファイルのオブジェクトの内容が異なるかどうかはチェックされないため、インポート結果に不正または無効なデータが含まれる可能性があります。

重要

ダンプの停止とダンプの再開の間にダンプファイル内のデータを変更しないでください。 データの変更後にダンプを再開すると動作が未定義になり、データの不整合やデータの損失が発生する可能性があります。 ダンプを部分的にロードした後にデータを変更する必要がある場合は、部分的なインポート中に作成されたすべてのオブジェクトを手動で削除し (進捗状態ファイルにリストされています)、resetProgress オプションを指定してダンプロードユーティリティを実行し、最初から再開します。

ダンプのデータファイル内のデータをターゲットの MySQL インスタンスにインポートする前に変更する必要がある場合は、MySQL シェルのパラレルテーブルインポートユーティリティ util.importTable() とダンプロードユーティリティを組み合せて変更できます。 これを行うには、まずダンプロードユーティリティを使用して、選択したテーブルの DDL のみをロードし、ターゲットサーバーにテーブルを作成します。 次に、パラレルテーブルインポートユーティリティを使用して、テーブルの出力ファイルからデータを取得および変換し、ターゲットテーブルにインポートします。 必要に応じて、データを変更する他のテーブルに対してこのプロセスを繰り返します。 最後に、ダンプロードユーティリティを使用して、変更しない残りのテーブル (変更したテーブルを除く) の DDL およびデータをロードします。 手順の詳細は、ダンプしたデータの変更 を参照してください。

オブジェクトストレージバケットからの事前認証済リクエストを含むダンプファイルを MySQL DB システムにロードするには、マニフェストファイルオブジェクト (@.manifest.json) 用に作成された事前認証済読取りリクエスト URL が必要です。 また、オブジェクトストレージバケット内のダンプファイルと同じ接頭辞付きの場所に、テキストファイルに対する事前認証済の読取り/書込みリクエストを作成します。 これはダンプロードユーティリティの進捗状態ファイルで、事前認証済リクエストを含むダンプファイルをロードする場合に必要です。 リクエストの作成に必要な権限を持つ任意のユーザーアカウントを使用できます。 テキストファイルには任意の名前を付けることができ、ファイルを作成するか、ユーティリティで作成できます。 ファイルのコンテンツは JSON 形式になるため、.json ファイル拡張子は使用する場合に適しています (progress.json など)。

ダンプファイル (デフォルト) とともに進捗状態ファイルを格納するかわりに、ダンプロードユーティリティを実行する場所にあるローカルファイルを使用できます。 進捗状態ファイルの事前認証済読取り/書込みリクエストを作成する権限がない場合、このメソッドを使用して進捗を格納できます。 ローカルファイルを使用する場合、ダンプロードユーティリティを別の場所から実行してもダンプを再開できないことに注意してください。

事前認証済リクエストでは、ダンプロードユーティリティを実行するときに、@.manifest.json ファイルの事前認証済リクエスト URL としてダンプ URL を指定します。 また、進行状態ファイル (progressFile オプション) をオブジェクトストレージバケット内のファイルの事前認証済リクエスト URL として、またはローカルシステム上のファイル (このオプションを選択した場合) として指定します。 ダンプロードユーティリティを実行するユーザーアカウントは、追加のアクセス権限なしでマニフェストファイル内の URL を使用してダンプファイルをロードできます。 ダンプがまだ進行中の場合、ダンプロードユーティリティは、オブジェクトストレージバケットではなくマニフェストファイルへの新しい追加を監視して待機します。

ダンプの DDL ファイルは単一のスレッドによってロードされますが、データは選択したスレッド数 (デフォルトは 4) によってパラレルにロードされます。 ダンプの作成時にテーブルデータがチャンク化された場合は、テーブルに複数のスレッドを使用できます。それ以外の場合は、各スレッドが一度に 1 つのテーブルをロードします。 ダンプロードユーティリティは、並列性を最大化するためにスレッド間のデータインポートをスケジュールします。 ダンプファイルが MySQL Shell ダンプユーティリティによって圧縮されている場合、ダンプロードユーティリティはそれらの解凍を処理します。

デフォルトでは、テーブルの全文インデックスは、テーブルが完全にロードされた後にのみ作成され、インポートが高速化されます。 各テーブルが完全にロードされるまで、すべてのインデックス作成 (プライマリインデックスを除く) を遅延するように選択できます。 テーブルのインポート中にすべてのインデックスを作成することもできます。 また、インポート中にインデックスの作成を無効にし、ロード後にテーブル構造を変更する場合などは、後でインデックスを作成することもできます。

データロードのパフォーマンスをさらに向上させるために、インポート中にターゲット MySQL インスタンスの InnoDB redo ログを無効にできます。 これは (本番システムではなく) 新しい MySQL Server インスタンスでのみ行う必要があり、この機能は MySQL DB システムでは使用できないことに注意してください。 詳細は、redo ロギングの無効化を参照してください。

ダンプロードユーティリティは、MySQL Shell グローバルセッションを使用して、ダンプのインポート先のターゲット MySQL インスタンスの接続詳細を取得します。 ユーティリティを実行する前に、( X プロトコル 接続または クラシック MySQL プロトコル 接続を持つことができる) グローバルセッションをオープンする必要があります。 ユーティリティはスレッドごとに独自のセッションを開き、接続圧縮や SSL オプションなどのオプションをグローバルセッションからコピーし、グローバルセッションをこれ以上使用しません。

MySQL Shell API では、ダンプロードユーティリティは util グローバルオブジェクトの関数であり、次のシグネチャを持ちます:

util.loadDump(url[, options])

ユーティリティを実行している Oracle Cloud Infrastructure Compute インスタンスのファイルシステムにあるダンプをインポートする場合、url はダンプファイルを含むローカルディレクトリへのパスを指定する文字列です。 ローカルディレクトリパスの前に file://スキーマを付けることができます。 MySQL ShellJavaScript モードのこの例では、ダンプファイルがローカルディレクトリから接続された MySQL インスタンスにロードされるときに問題がないことを確認するための予行演習が実行されます:

shell-js> util.loadDump("/mnt/data/worlddump", {dryRun: true})

Oracle Cloud Infrastructure Object Storage バケットからダンプをインポートする場合、url は、ダンプの作成時に outputUrl パラメータを使用して割り当てられたバケット内のダンプファイルのパス接頭辞です。 osBucketName オプションを使用してオブジェクトストレージバケットの名前を指定し、osNamespace オプションを使用してバケットのネームスペースを識別します。 MySQL ShellJavaScript モードのこの例では、8 つのスレッドを使用して、接頭辞が worlddump のダンプがオブジェクトストレージバケットから接続された MySQL DB システムにロードされます:

shell-js> util.loadDump("worlddump", {
        > threads: 8, osBucketName: "hanna-bucket", osNamespace: "idx28w1ckztq"})

オブジェクトストレージバケットのネームスペースは、Oracle Cloud Infrastructure コンソールのバケット詳細ページの「バケット情報」タブに表示されるか、Oracle Cloud Infrastructure コマンドラインインタフェースを使用して取得できます。 オブジェクトストレージバケットへの接続は、デフォルトの Oracle Cloud Infrastructure CLI 構成ファイルのデフォルトプロファイル、または ociConfigFile および ociProfile オプションを使用して指定する代替詳細を使用して確立されます。 CLI 構成ファイルを設定する手順については、「SDK および CLI 構成ファイル」を参照してください

options はオプションのディクショナリで、空の場合は省略できます。 次のオプションを使用できます。

dryRun: [ true | false ]

ダンプの内容に基づいて返されるが、インポートを続行しないエラーを含む、指定されたオプションおよびダンプファイルで実行されるアクションに関する情報を表示します。 デフォルトは false です。

osBucketName: "string"

ダンプファイルがある Oracle Cloud Infrastructure Object Storage バケットの名前。 デフォルトでは、~/.oci/config にある Oracle Cloud Infrastructure CLI 構成ファイルの[DEFAULT]プロファイルを使用して、バケットへの接続が確立されます。 ociConfigFile および ociProfile オプションを使用して、接続に使用される代替プロファイルを置換できます。 CLI 構成ファイルの設定手順については、「SDK および CLI 構成ファイル」を参照してください。

osNamespace: "string"

osBucketName によって指定されたオブジェクトストレージバケットが配置される Oracle Cloud Infrastructure ネームスペース。 オブジェクトストレージバケットのネームスペースは、Oracle Cloud Infrastructure コンソールのバケット詳細ページの「バケット情報」タブに表示されるか、Oracle Cloud Infrastructure コマンドラインインタフェースを使用して取得できます。

ociConfigFile: "string"

デフォルトの場所の ~/.oci/config ではなく、接続に使用するプロファイルを含む Oracle Cloud Infrastructure CLI 構成ファイル。

ociProfile: "string"

接続に使用される Oracle Cloud Infrastructure CLI 構成ファイル内の[DEFAULT]プロファイルではなく、接続に使用する Oracle Cloud Infrastructure プロファイルのプロファイル名。

threads: int

データのチャンクをターゲット MySQL インスタンスにアップロードするために使用するパラレルスレッドの数。 各スレッドは、MySQL インスタンスへの独自の接続を持ちます。 ダンプがチャンク化を有効にして作成された場合 (デフォルト)、ユーティリティは複数のスレッドを使用してテーブルのデータをロードできます。それ以外の場合、スレッドは 1 つのテーブルにのみ使用されます。

progressFile: "string"

ダンプロードユーティリティの進捗状態ファイルのローカルファイルの場所。インポートの進捗状態を保持します。 デフォルトでは、進捗状態ファイルは load-progress.server_uuid.json という名前でダンプディレクトリに作成されますが、このオプションを使用して変更できます。 progressFile を空の文字列に設定すると、進行状況の追跡が無効になります。つまり、ダンプロードユーティリティは部分的に完了したインポートを再開できません。

showProgress: [ true | false ]

インポートの進行状況情報を表示 (true) または非表示 (false) します。 MySQL Shell が対話型モードの場合など、stdout が端末 (tty) の場合、デフォルトは true です。それ以外の場合は false です。 進捗情報には、アクティブスレッドの数とそのアクション、これまでにロードされたデータの量、完了率およびスループット率が含まれます。 進捗情報が表示されない場合でも、進捗状態はダンプロードユーティリティの進捗状態ファイルに記録されます。

resetProgress: [ true | false ]

このオプションを true に設定すると、進行状態がリセットされ、インポートが最初から再開されます。 デフォルトは false です。 このオプションでは、ダンプロードユーティリティはすでに作成されているオブジェクトをスキップせず、重複除外を管理しないことに注意してください。 このオプションを使用する場合は、正しいインポートを確実にするために、まず、以前にロードされたすべてのオブジェクト (スキーマ、テーブル、ユーザー、ビュー、トリガー、ルーチン、イベントなど) をターゲット MySQL インスタンスから手動で削除する必要があります。 それ以外の場合、ダンプファイル内のオブジェクトがターゲット MySQL インスタンスにすでに存在すると、インポートはエラーで停止します。 適切な注意が必要な場合は、ignoreExistingObjects オプションを使用してユーティリティレポートでオブジェクトを複製しますが、スキップしてインポートを続行できます。

waitDumpTimeout: int

このオプションを設定すると、ダンプの場所にアップロードされたすべてのデータチャンクが処理された後、ユーティリティがそれ以降のデータを待機するタイムアウト (秒) を指定することで、同時ロードがアクティブ化されます。 これにより、作成中のダンプをユーティリティでインポートできます。 データは使用可能になると処理され、ダンプの場所にデータが表示されずにタイムアウトを超えるとインポートは停止します。 デフォルト設定の 0 は、アップロードされたすべてのデータチャンクが処理され、それ以上のデータを待機しない場合に、ユーティリティがダンプを完了としてマークすることを意味します。

ignoreExistingObjects: [ true | false ]

MySQL インスタンスのターゲットスキーマにすでに存在するオブジェクトが含まれている場合でも、ダンプをインポートします。 デフォルトは false です。つまり、インポートが進行状態ファイルを使用した前回の試行から再開されないかぎり、エラーが発行され、重複オブジェクトが検出されるとインポートが停止します。この場合、チェックはスキップされます。 このオプションを true に設定すると、重複オブジェクトがレポートされますが、エラーは生成されず、インポートは続行されます。 ユーティリティでは、ターゲット MySQL インスタンスとダンプファイルのオブジェクトの内容が異なるかどうかはチェックされないため、このオプションは注意して使用する必要があります。そのため、インポート結果に不正または無効なデータが含まれる可能性があります。 別の方法として、excludeTables オプションを使用して、ダンプファイル内のオブジェクトがターゲット MySQL インスタンス内のインポート済オブジェクトと同じであることを確認したときにすでにロードしたテーブルを除外する方法もあります。 ダンプを再起動する前に、重複するオブジェクトをターゲット MySQL インスタンスから削除することをお薦めします。

ignoreVersion: [ true | false ]

データのダンプ元の MySQL インスタンスのメジャーバージョン番号が、データのアップロード先の MySQL インスタンスのメジャーバージョン番号と異なる場合でも、ダンプをインポートします。 デフォルトは false で、メジャーバージョン番号が異なる場合、エラーが発行され、インポートは続行されません。 このオプションを true に設定すると、警告が発行され、インポートが続行されます。 インポートは、ダンプファイル内のスキーマに新しいメジャーバージョンとの互換性の問題がない場合にのみ成功することに注意してください。

MySQL Shell 8.0.23 からは、このオプションを使用して、ocimds オプションを使用せずに作成されたダンプを MySQL Database Service インスタンスにインポートすることもできます。

ignoreVersion オプションを使用してインポートを試行する前に、MySQL Shell アップグレードチェッカユーティリティ checkForServerUpgrade() を使用して、ソース MySQL インスタンスのスキーマを確認します。 スキーマをダンプしてターゲット MySQL インスタンスにインポートする前に、ユーティリティで特定された互換性の問題を修正します。

updateGtidSet: [ off | append | replace ]

ダンプメタデータに記録されているソース MySQL インスタンスの gtid_executed GTID セットを、ターゲット MySQL インスタンスの gtid_purged GTID セットに適用します。 gtid_purged GTID セットは、サーバーに適用されたが、サーバー上のバイナリログファイルには存在しないすべてのトランザクションの GTID を保持します。 このオプションは MySQL Shell 8.0.22 から使用できますが、そのリリースでは、権限の制限のため、MySQL DB システムではサポートされていません。 MySQL 8.0.23 から、このオプションを MySQL DB システムインスタンスにも使用できます。 デフォルトは off で、GTID セットが適用されないことを意味します。

このオプションは、MySQL Shell インスタンスダンプユーティリティまたはスキーマダンプユーティリティによって生成されたダンプに対してのみ、MySQL Shell テーブルダンプユーティリティによって生成されたダンプには使用しないでください。 また、グループレプリケーションがターゲットの MySQL インスタンスで実行されている場合は、このオプションを使用しないでください。

MySQL DB システムインスタンスではない MySQL インスタンスの場合、GTID セットを更新するために append または replace を設定するときに、skipBinlog オプションも true に設定します。 これにより、ソースサーバー上の GTID がターゲットサーバー上の GTID と一致することが保証されます。 MySQL DB システムインスタンスの場合、このオプションは使用されません。

MySQL 8.0 のターゲット MySQL インスタンスの場合、オプションを append に設定できます。これにより、ソース MySQL インスタンスの gtid_executed GTID セットがターゲット MySQL インスタンスの gtid_purged GTID セットに追加されます。 適用する gtid_executed GTID セットは、@.json ダンプファイルの gtidExecuted フィールドに表示され、ターゲット MySQL インスタンスにすでに存在する gtid_executed セットと交差しないようにする必要があります。 たとえば、別のソース MySQL インスタンスから、他のソースサーバーのスキーマをすでに持つターゲット MySQL インスタンスにスキーマをインポートする場合に、このオプションを使用できます。

MySQL 8.0 のターゲット MySQL インスタンスに replace を使用して、ターゲット MySQL インスタンスの gtid_purged GTID セットをソース MySQL インスタンスの gtid_executed GTID セットに置き換えることもできます。 これを行うには、ソース MySQL インスタンスの gtid_executed GTID セットがターゲット MySQL インスタンスの gtid_purged GTID セットのスーパーセットであり、gtid_purged GTID セットにないターゲット gtid_executed GTID セットのトランザクションのセットと交差していない必要があります。

MySQL 5.7 のターゲット MySQL インスタンスの場合、オプションを replace に設定します。これにより、ターゲット MySQL インスタンスに設定されている gtid_purged GTID が、ソース MySQL インスタンスの gtid_executed GTID セットに置き換えられます。 MySQL 5.7 でこれを行うには、ターゲット MySQL インスタンス上の gtid_executed および gtid_purged GTID セットが空である必要があるため、以前に GTID セットをインポートしていない状態でインスタンスを使用しないでください。

MySQL Shell 8.0.21 では、このオプションを使用できない場合、GTID セットを MySQL Server インスタンスに手動で適用できます (グループレプリケーションが使用されている場合を除く)。 MySQL DB システムの場合、この方法はサポートされていません。 GTID セットを適用するには、インポート後に、MySQL Shell\sql コマンドを使用して (または SQL モードを開始して)、接続された MySQL インスタンスで次のステートメントを発行し、ダンプメタデータの@.json ダンプファイルの gtidExecuted フィールドから gtid_executed GTID セットをコピーします:

shell-js> \sql SET @@GLOBAL.gtid_purged= "+gtidExecuted_set";

このステートメントは、MySQL 8.0 から機能し、ソース MySQL Server インスタンス gtid_executed GTID セットをターゲット MySQL インスタンス gtid_purged GTID セットに追加します。 MySQL 5.7 の場合、プラス記号 (+) は省略する必要があり、ターゲット MySQL インスタンスの gtid_executed および gtid_purged GTID セットは空である必要があります。 詳細は、ターゲット MySQL インスタンスのリリースにおける gtid_purged システム変数の説明を参照してください。

skipBinlog: [ true | false ]

SET sql_log_bin=0 ステートメントを発行して、インポート中にユーティリティで使用されるセッションのターゲット MySQL インスタンスでバイナリロギングをスキップします。 デフォルトは false であるため、バイナリロギングはデフォルトでアクティブです。 MySQL DB システムの場合、このオプションは使用されず、true に設定しようとするとインポートはエラーで停止します。 他の MySQL インスタンスの場合、updateGtidSet オプションを使用するか手動で、ソース MySQL インスタンスから gtid_executed GTID セットをターゲット MySQL インスタンスに適用する場合は、常に skipBinlogtrue に設定します。 GTID がターゲット MySQL インスタンス (gtid_mode=ON) で使用されている場合、このオプションを true に設定すると、インポートの実行中に新しい GTID が生成および割り当てられないため、ソースサーバーから設定された元の GTID を使用できます。 ユーザーアカウントには、sql_log_bin システム変数の設定に必要な権限が必要です。

loadIndexes: [ true | false ]

テーブルのセカンダリインデックスを作成 (true) するか、作成 (false) しないでください。 デフォルトは true です。 このオプションが false に設定されている場合、セカンダリインデックスはインポート中に作成されないため、後で作成する必要があります。 これは、DDL ファイルとデータファイルを個別にロードする場合、および DDL ファイルのロード後にテーブル構造を変更する場合に便利です。 その後、loadIndexestrue に設定し、deferTableIndexesall に設定してダンプロードユーティリティを再度実行することで、セカンダリインデックスを作成できます。

deferTableIndexes: [ off | fulltext | all ]

テーブルデータがロードされるまでセカンダリインデックスの作成を延期します。 これにより、ロード時間を短縮できます。off は、テーブルのロード中にすべてのインデックスが作成されることを意味します。 デフォルト設定の fulltext では、全文インデックスのみが遅延されます。all は、すべてのセカンダリインデックスを遅延し、テーブルのロード中にのみプライマリインデックスを作成します。また、自動インクリメント値を含むカラムに ( MySQL Shell 8.0.22 から) 定義されたインデックスも作成します。 MySQL Shell 8.0.21 では、自動増分値を含む一意のキーカラムがある場合、all を設定しないでください。

analyzeTables: [ off | on | histogram ]

ロードされたテーブルに対して ANALYZE TABLE を実行します。on はすべてのテーブルを分析し、histogram はダンプにヒストグラム情報が格納されているテーブルのみを分析します。 デフォルトは off です。 このオプションを指定してダンプロードユーティリティを実行すると、データがすでにロードされている場合でもテーブルを分析できます。

characterSet: "string"

LOAD DATA ステートメントの CHARACTER SET オプションなどで、ターゲット MySQL インスタンスへのインポートに使用される文字セット。 デフォルトは、ダンプが MySQL Shell インスタンスダンプユーティリティ、スキーマダンプユーティリティまたはテーブルダンプユーティリティによって作成されたときに使用されたダンプメタデータで指定された文字セットで、デフォルトでは utf8mb4 が使用されます。 文字セットは、character_set_client システム変数で許可され、MySQL インスタンスでサポートされている必要があります。

schema: "string"

MySQL Shell テーブルダンプユーティリティによって生成されたダンプをロードする必要がある既存のターゲットスキーマ。

MySQL Shell 8.0.23 からは、テーブルダンプユーティリティのダンプファイルには、最初にテーブルが含まれていたスキーマの設定に必要な情報が含まれているため、このオプションは必要ありません。 デフォルトでは、そのリリースから、ターゲットの MySQL インスタンスにスキーマがまだ存在しない場合は再作成されます。 または、schema オプションを指定して、ターゲット MySQL インスタンスの代替スキーマにテーブルをロードできます。

MySQL Shell 8.0.22 では、テーブルダンプユーティリティのダンプファイルにスキーマ情報が含まれていないため、ターゲットスキーマがターゲットの MySQL インスタンスに存在する必要があります。 このリリースでは、デフォルトでグローバルシェルセッションの現在のスキーマがターゲットスキーマとして使用されるか、schema オプションを使用してターゲットスキーマを指定できます。

excludeSchemas: array of strings

指定したスキーマをインポートから除外します。 information_schema, mysql, ndbinfo, performance_schema および sys スキーマは、常に MySQL Shell インスタンスダンプユーティリティによって作成されたダンプから除外されることに注意してください。 ダンプファイルに名前付きスキーマが存在しない場合、ユーティリティはその項目を無視します。

includeSchemas: array of strings

ダンプファイルから名前付きスキーマのみをロードします。 両方のオプションを指定できます。この場合、includeSchemas 文字列と excludeSchemas 文字列の両方で一致するスキーマ名は除外されます。

excludeTables: array of strings

指定したテーブルをインポートから除外します。 テーブル名は、有効なスキーマ名で修飾し、必要に応じてバックティック文字で引用符で囲む必要があります。 mysql.apply_status, mysql.general_log, mysql.schema および mysql.slow_log tables のデータは、DDL ステートメントは含まれていますが、常に MySQL Shell スキーマダンプユーティリティによって作成されたダンプから除外されることに注意してください。 excludeTables オプションで指定されたテーブルは、ターゲットの MySQL インスタンスにアップロードされません。 指定したテーブルがスキーマに存在しない場合、またはスキーマがダンプファイルに存在しない場合、ダンプロードユーティリティは項目を無視します。

includeTables: array of strings

ダンプファイルから指定されたテーブルのみをロードします。 テーブル名は、有効なスキーマ名で修飾し、必要に応じてバックティック文字で引用符で囲む必要があります。 両方のオプションを指定できます。この場合、includeTables 文字列と excludeTables 文字列の両方で一致するテーブル名は除外されます。

loadDdl: [ true | false ]

このオプションを true に設定すると、ダンプから DDL ファイルのみがインポートされ、データはインポートされません。 デフォルトは false です。

loadData: [ true | false ]

このオプションを true に設定すると、ダンプからデータファイルのみがインポートされ、DDL ファイルはインポートされません。 デフォルトは false です。

loadUsers: [ true | false ]

(true) をインポートするか、(false) ユーザーとそのロールおよび権限をターゲットの MySQL インスタンスにインポートしないでください。 デフォルトは false であるため、ユーザーはデフォルトでインポートされません。 現在のユーザーのステートメントはスキップされます。 MySQL Shell 8.0.22 からは、ターゲットの MySQL インスタンスにユーザーがすでに存在する場合、エラーが返され、ダンプファイルからのユーザー権限は適用されません。 MySQL Shell 8.0.22 から、ダンプロードユーティリティの excludeUsers または includeUsers オプションを使用して、インポートに除外または含めるユーザーアカウントを指定できます。

注記

MySQL Shell 8.0.21 では、root ユーザーアカウントまたは別の制限付きユーザーアカウント名がダンプファイルに存在する場合、ユーザーを MySQL DB システムにインポートしようとするとインポートが失敗するため、そのリリースではユーザーの MySQL DB システムへのインポートはサポートされていません。

MySQL Shell スキーマダンプユーティリティおよびテーブルダンプユーティリティでは、ダンプにユーザー、ロールおよび付与は含まれませんが、インスタンスダンプユーティリティではデフォルトで可能であり、実行できます。 MySQL Shell 8.0.22 から、excludeUsers および includeUsers オプションをインスタンスダンプユーティリティで使用して、ダンプファイルから名前付きユーザーアカウントを除外または含めることもできます。

true を指定したが、指定したダンプファイルにユーザーアカウントが含まれていない場合、MySQL Shell 8.0.23 の前に、ユーティリティはエラーを返してインポートを停止します。 MySQL Shell 8.0.23 からは、かわりにユーティリティは警告を返して続行します。

excludeUsers: array of strings

指定されたユーザーアカウントをインポートから除外します。 このオプションは MySQL Shell 8.0.22 から使用でき、これを使用して、MySQL DB システムへのインポートが許可されていないユーザーアカウント、またはターゲットの MySQL インスタンスにすでに存在するか不要なユーザーアカウントを除外できます。 各ユーザーアカウント文字列は、ユーザー名とホスト名で定義されたアカウントの場合は"'user_name'@'host_name'"の形式で、ユーザー名のみで定義されたアカウントの場合は"'user_name'" ("'user_name'@'%'"と同等) で指定します。 指定されたユーザーアカウントがダンプファイルに存在しない場合、ユーティリティは項目を無視します。

includeUsers: array of strings

指定されたユーザーアカウントのみをインポートに含めます。 excludeUsers オプションの場合と同様に、各ユーザーアカウント文字列を指定します。 このオプションは MySQL Shell 8.0.22 から使用でき、ターゲット MySQL インスタンスで必要なユーザーアカウントが少ない場合は、excludeUsers のかわりに使用できます。 両方のオプションを指定することもできます。この場合、includeUsers 文字列と excludeUsers 文字列の両方で一致するユーザーアカウントは除外されます。

ダンプしたデータの変更

MySQL シェルのパラレルテーブルインポートユーティリティ util.importTable() をダンプロードユーティリティ util.loadDump() と組み合せて使用すると、チャンク出力ファイルのデータをターゲットの MySQL インスタンスにアップロードする前に変更できます。 この方法では、一度に 1 つのテーブルのデータを変更できます。 MySQL Shell 8.0.23 から動作する次の手順に従います:

  1. loadDdl オプションを指定してダンプロードユーティリティを使用して DDL ファイルをロードし、選択したテーブルをデータなしでターゲット MySQL インスタンスに作成します。

    shell-js> util.loadDump("/mnt/data/proddump", { 
            > includeTables: ["product.pricing"], 
            > loadDdl: true, 
            > loadData: false});
  2. パラレルテーブルインポートユーティリティを使用して、テーブルのデータを取得および変換し、ターゲット MySQL インスタンスの空のテーブルにインポートします。 この例では、pricing テーブルのデータは、ワイルドカードパターンマッチングを使用して指定された複数の圧縮ファイルにあります。 ダンプファイルの id および prodname カラムの値は、ターゲットテーブルの同じカラムにそのまま割り当てられます。 ダンプファイルの price カラムの値が取得され、変数@1 に割り当てられます。 その後、decodeColumns オプションを使用して価格を標準金額で減額し、減額された価格をターゲットテーブルの price カラムに配置します。

    shell-js> util.importTable ("/mnt/data/proddump/product@pricing@*.zst", {   
            > schema: "product",  
            > table: "pricing",  
            > columns: ["id",  "prodname",  1],
            > decodeColumns: { "price": "0.8 * @1"}});
  3. データを変更する必要があるダンプファイル内の他のテーブルについて、必要に応じてステップ 1 と 2 を繰り返します。

  4. 変更する必要があるすべてのテーブルおよびデータのアップロードが終了したら、ダンプロードユーティリティを使用して、変更する必要がない残りのテーブルの DDL とデータの両方をロードします。 前のステップで変更したテーブルは除外してください。

    shell-js> util.loadDump("/mnt/data/proddump", {excludeTables: ["product.pricing"]});