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

17.5.1.19 レプリケーションと LOAD DATA

LOAD DATA はステートメントベースのロギングで安全でないとみなされます (を参照してください セクション17.2.1.3「バイナリロギングでの安全および安全でないステートメントの判断」). binlog_format=MIXED が設定されている場合、ステートメントは行ベースの形式で記録されます。 binlog_format=STATEMENT が設定されている場合、他の安全でないステートメントとは異なり、LOAD DATA では警告が生成されないことに注意してください。

binlog_format=STATEMENT が設定されているときに LOAD DATA を使用すると、変更が適用されるレプリカにデータを含む一時ファイルが作成されます。 次に、レプリカは LOAD DATA INFILE ステートメントを使用して変更を適用します。 バイナリログの暗号化がサーバー上でアクティブな場合、この一時ファイルは暗号化されないことに注意してください。 暗号化が必要な場合は、一時ファイルを作成しない行ベースまたは混合バイナリロギング形式を使用してください。

レプリケーションチャネルの保護に PRIVILEGE_CHECKS_USER アカウントが使用されている場合 (セクション17.3.3「レプリケーション権限チェック」 を参照)、行ベースのバイナリロギング (binlog_format=ROW) を使用して LOAD DATA 操作をログに記録することを強くお薦めします。 チャネルに REQUIRE_ROW_FORMAT が設定されている場合は、行ベースのバイナリロギングが必要です。 このロギング形式では、イベントの実行に FILE 権限は必要ないため、PRIVILEGE_CHECKS_USER アカウントにこの権限を付与しないでください。 ステートメント形式で記録された LOAD DATA INFILE 操作に関連するレプリケーションエラーからリカバリする必要があり、レプリケートされたイベントが信頼できる場合は、FILE 権限を PRIVILEGE_CHECKS_USER アカウントに一時的に付与し、レプリケートされたイベントの適用後に削除できます。

mysqlbinlog がステートメントベースの形式で記録された LOAD DATA ステートメントのログイベントを読み取ると、生成されたローカルファイルが一時ディレクトリに作成されます。 これらの一時ファイルは、mysqlbinlog およびその他のどの MySQL プログラムによっても自動的に削除されません。 ステートメントベースのバイナリロギングで LOAD DATA ステートメントを使用する場合は、ステートメントログが不要になったあとに一時ファイルを自分で削除するようにしてください。 詳細は、セクション4.6.8「mysqlbinlog — バイナリログファイルを処理するためのユーティリティー」を参照してください。