このページは機械翻訳したものです。
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 テーブルダンプユーティリティでは、このオプションは使用しません。
ダンプロードユーティリティでは
LOAD DATA LOCAL INFILE
ステートメントが使用されるため、インポート中は、ターゲット MySQL インスタンスのlocal_infile
システム変数のグローバル設定をON
にする必要があります。 デフォルトでは、このシステム変数は標準の MySQL DB システム構成でON
に設定されています。ターゲットの MySQL インスタンスでは、ダンプロードユーティリティは、
sql_require_primary_key
システム変数がON
に設定されているかどうかをチェックし、設定されている場合は、ダンプファイルに主キーのないテーブルがあるとエラーを返します。 デフォルトでは、このシステム変数は標準の MySQL DB システム構成でOFF
に設定されています。ダンプロードユーティリティは、ソース 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.
という名前でダンプディレクトリに作成されますが、別の名前と場所を選択することもできます。 ダンプロードユーティリティは、ダンプのインポートを再開または再試行するときに進行状態ファイルを参照し、完了したステップをスキップします。 部分的にロードされたテーブルの重複除外は自動的に管理されます。 Ctrl + C を使用して進行中のダンプを中断した場合、そのキーの組合せを最初に使用しても、ユーティリティによって新しいタスクは開始されませんが、既存のタスクは続行されます。 Ctrl + C を再度押すと、既存のタスクが停止し、エラーメッセージが表示されます。 いずれの場合も、ユーティリティは停止した場所からインポートを再開できます。
server_uuid
.json
進行状態をリセットしてダンプのインポートを最初から再開することを選択できますが、この場合、ユーティリティはすでに作成されて重複除外を管理していないオブジェクトをスキップしません。 これを行う場合、正しいインポートを保証するには、以前にロードされたすべてのオブジェクト (スキーマ、テーブル、ユーザー、ビュー、トリガー、ルーチン、イベントなど) をターゲット 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
.jsonprogressFile
を空の文字列に設定すると、進行状況の追跡が無効になります。つまり、ダンプロードユーティリティは部分的に完了したインポートを再開できません。-
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 インスタンスに適用する場合は、常にskipBinlog
をtrue
に設定します。 GTID がターゲット MySQL インスタンス (gtid_mode=ON
) で使用されている場合、このオプションをtrue
に設定すると、インポートの実行中に新しい GTID が生成および割り当てられないため、ソースサーバーから設定された元の GTID を使用できます。 ユーザーアカウントには、sql_log_bin
システム変数の設定に必要な権限が必要です。-
loadIndexes: [ true | false ]
テーブルのセカンダリインデックスを作成 (
true
) するか、作成 (false
) しないでください。 デフォルトはtrue
です。 このオプションがfalse
に設定されている場合、セカンダリインデックスはインポート中に作成されないため、後で作成する必要があります。 これは、DDL ファイルとデータファイルを個別にロードする場合、および DDL ファイルのロード後にテーブル構造を変更する場合に便利です。 その後、loadIndexes
をtrue
に設定し、deferTableIndexes
をall
に設定してダンプロードユーティリティを再度実行することで、セカンダリインデックスを作成できます。-
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 から動作する次の手順に従います:
-
loadDdl
オプションを指定してダンプロードユーティリティを使用して DDL ファイルをロードし、選択したテーブルをデータなしでターゲット MySQL インスタンスに作成します。shell-js> util.loadDump("/mnt/data/proddump", { > includeTables: ["product.pricing"], > loadDdl: true, > loadData: false});
-
パラレルテーブルインポートユーティリティを使用して、テーブルのデータを取得および変換し、ターゲット 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"}});
データを変更する必要があるダンプファイル内の他のテーブルについて、必要に応じてステップ 1 と 2 を繰り返します。
-
変更する必要があるすべてのテーブルおよびデータのアップロードが終了したら、ダンプロードユーティリティを使用して、変更する必要がない残りのテーブルの DDL とデータの両方をロードします。 前のステップで変更したテーブルは除外してください。
shell-js> util.loadDump("/mnt/data/proddump", {excludeTables: ["product.pricing"]});