このページは機械翻訳したものです。
Press CTRL+C to copyFLUSH [NO_WRITE_TO_BINLOG | LOCAL] { flush_option [, flush_option] ... | tables_option } flush_option: { BINARY LOGS | ENGINE LOGS | ERROR LOGS | GENERAL LOGS | HOSTS | LOGS | PRIVILEGES | OPTIMIZER_COSTS | RELAY LOGS [FOR CHANNEL channel] | SLOW LOGS | STATUS | USER_RESOURCES } tables_option: { TABLES | TABLES tbl_name [, tbl_name] ... | TABLES WITH READ LOCK | TABLES tbl_name [, tbl_name] ... WITH READ LOCK | TABLES tbl_name [, tbl_name] ... FOR EXPORT }
FLUSH
ステートメントには、さまざまな内部キャッシュをクリアまたはリロードしたり、テーブルをフラッシュしたり、ロックを取得したりするいくつかのバリアント形式があります。 各 FLUSH
操作には、その説明に示されている権限が必要です。
ストアドファンクションまたはトリガー内で FLUSH
ステートメントを発行することはできません。 ただし、ストアドプロシージャーでは、それがストアドファンクションまたはトリガーから呼び出されないかぎり、FLUSH
を使用できます。 セクション25.8「ストアドプログラムの制約」を参照してください。
デフォルトでは、FLUSH
ステートメントはレプリカにレプリケートされるようにバイナリログに書き込まれます。 ロギングを抑制するには、オプションの NO_WRITE_TO_BINLOG
キーワード、またはそのエイリアス LOCAL
を指定します。
レプリカにレプリケートすると問題が発生するため、FLUSH LOGS
, FLUSH BINARY LOGS
, FLUSH TABLES WITH READ LOCK
(テーブルリストの有無にかかわらず)、および FLUSH TABLES
はバイナリログに書き込まれません。
tbl_name
... FOR EXPORT
FLUSH
ステートメントは暗黙的なコミットを発生させます。 セクション13.3.3「暗黙的なコミットを発生させるステートメント」を参照してください。
mysqladmin ユーティリティーは、flush-hosts
、flush-logs
、flush-privileges
、flush-status
、flush-tables
などのコマンドを使用して、いくつかのフラッシュ操作へのコマンド行インタフェースを提供します。 セクション4.5.2「mysqladmin — A MySQL Server 管理プログラム」を参照してください。
SIGHUP
または SIGUSR1
シグナルをサーバーに送信すると、FLUSH
ステートメントのさまざまな形式に似たフラッシュ操作がいくつか発生します。 シグナルは、root
システムアカウントまたはサーバープロセスを所有するシステムアカウントによって送信できます。 これにより、サーバーに接続せずにフラッシュ操作を実行できるようになり、その操作に十分な権限を持つ MySQL アカウントが必要になります。 セクション4.10「MySQL での Unix シグナル処理」を参照してください。
RESET
ステートメントは、FLUSH
に似ています。 レプリケーションでの RESET
の使用の詳細は、セクション13.7.8.6「RESET ステートメント」 を参照してください。
次のリストに、許可される FLUSH
ステートメントの flush_option
値を示します。 許可される tables_option
値の説明は、FLUSH TABLES 構文 を参照してください。
-
サーバーが書き込んでいるバイナリログファイルを閉じてから再度開きます。 バイナリロギングが有効になっている場合は、バイナリログファイルのシーケンス番号が、前のファイルを基準にして 1 増分されます。
この操作には、
RELOAD
権限が必要です。 -
インストールされているストレージエンジンのフラッシュ可能なログを閉じて再度開きます。 これにより、
InnoDB
はログをディスクにフラッシュします。この操作には、
RELOAD
権限が必要です。 -
サーバーが書き込んでいるエラーログファイルを閉じて再度開きます。
この操作には、
RELOAD
権限が必要です。 -
サーバーが書き込んでいる一般クエリーログファイルを閉じて再度開きます。
この操作には、
RELOAD
権限が必要です。この操作は、一般クエリーログに使用されるテーブルには影響しません (セクション5.4.1「一般クエリーログおよびスロークエリーログの出力先の選択」 を参照)。
-
キャッシュの内容を公開するホストキャッシュとパフォーマンススキーマ
host_cache
テーブルを空にし、ブロックされたホストをブロック解除します。この操作には、
RELOAD
権限が必要です。ホストキャッシュのフラッシュが推奨または望ましい理由については、セクション5.1.12.3「DNS ルックアップとホストキャッシュ」 を参照してください。
注記FLUSH HOSTS
は、MySQL 8.0.23 では非推奨です。将来の MySQL リリースでは削除される予定です。 代わりに、パフォーマンススキーマhost_cache
テーブルを切り捨てます:Press CTRL+C to copyTRUNCATE TABLE performance_schema.host_cache;
TRUNCATE TABLE
操作には、RELOAD
権限ではなく、テーブルに対するDROP
権限が必要です。 -
サーバーが書き込んでいるログファイルを閉じて再度開きます。
この操作には、
RELOAD
権限が必要です。この操作の効果は、次の操作を組み合せた効果と同等です:
Press CTRL+C to copyFLUSH BINARY LOGS FLUSH ENGINE LOGS FLUSH ERROR LOGS FLUSH GENERAL LOGS FLUSH RELAY LOGS FLUSH SLOW LOGS
-
コストモデルテーブルに格納されている現在のコスト見積りの使用をオプティマイザが開始するように、コストモデルテーブルを再読取りします。
この操作には、
FLUSH_OPTIMIZER_COSTS
またはRELOAD
権限が必要です。サーバーは、認識できないコストモデルテーブルエントリについて、エラーログに警告を書き込みます。 これらのテーブルの詳細は、セクション8.9.5「オプティマイザコストモデル」 を参照してください。 この操作は、フラッシュ後に開始されるセッションにのみ影響します。 既存のセッションでは、開始時の現行のコスト見積りが引き続き使用されます。
-
mysql
システムスキーマの付与テーブルから権限を再度読み取ります。 この操作の一環として、サーバーは動的権限割当てを含むglobal_grants
テーブルを読み取り、そこで見つかった未登録の権限を登録します。この操作には、
RELOAD
権限が必要です。MySQL 権限システムを無効にするためにサーバーの起動時に
--skip-grant-tables
オプションが指定された場合、FLUSH PRIVILEGES
は実行時に権限システムを有効にする方法を提供します。失敗したログイントラッキングをリセットし (またはサーバーが
--skip-grant-tables
で起動された場合は有効にします)、一時的にロックされたアカウントのロックを解除します。 セクション6.2.15「パスワード管理」を参照してください。GRANT
,CREATE USER
,CREATE SERVER
およびINSTALL PLUGIN
ステートメントの結果としてサーバーによってキャッシュされたメモリーを解放します。 このメモリーは、対応するREVOKE
,DROP USER
,DROP SERVER
ステートメントおよびUNINSTALL PLUGIN
ステートメントによって解放されないため、キャッシュを引き起こすステートメントの多くのインスタンスを実行するサーバーでは、FLUSH PRIVILEGES
で解放されないかぎり、キャッシュされたメモリーの使用量が増加します。caching_sha2_password
認証プラグインで使用されるインメモリーキャッシュをクリアします。 SHA-2 プラガブル認証のキャッシュ操作を参照してください。 -
FLUSH RELAY LOGS [FOR CHANNEL
channel
]サーバーが書き込んでいるリレーログファイルを閉じてから再度開きます。 リレーロギングが有効になっている場合、リレーログファイルのシーケンス番号は、前のファイルを基準にして 1 ずつ増分されます。
この操作には、
RELOAD
権限が必要です。FOR CHANNEL
句を使用すると、操作を適用するレプリケーションチャネルの名前を指定できます。channel
FLUSH RELAY LOGS FOR CHANNEL
を実行して、特定のレプリケーションチャネルのリレーログをフラッシュします。 チャネルが指定されておらず、追加のレプリケーションチャネルが存在しない場合、操作はデフォルトチャネルに適用されます。 チャネルが指定されておらず、複数のレプリケーションチャネルが存在する場合、操作はすべてのレプリケーションチャネルに適用されます。 詳細は、セクション17.2.2「レプリケーションチャネル」を参照してください。channel
-
サーバーが書き込んでいるスロークエリーログファイルを閉じてから再度開きます。
この操作には、
RELOAD
権限が必要です。この操作は、スロークエリーログに使用されるテーブルには影響しません (セクション5.4.1「一般クエリーログおよびスロークエリーログの出力先の選択」 を参照)。
-
ステータスインジケータをフラッシュします。
この操作には、
FLUSH_STATUS
またはRELOAD
権限が必要です。この操作により、すべてのアクティブセッションのセッションステータスがグローバルステータス変数に追加され、すべてのアクティブセッションのステータスがリセットされ、切断されたセッションから集計されたアカウント、ホストおよびユーザーステータス値がリセットされます。 セクション27.12.15「パフォーマンススキーマのステータス変数のテーブル」を参照してください。 この情報は、クエリーのデバッグ時に使用できます。 セクション1.6「質問またはバグをレポートする方法」を参照してください。
-
時間当たりのすべてのユーザーリソースインジケータをゼロにリセットします。
この操作には、
FLUSH_USER_RESOURCES
またはRELOAD
権限が必要です。リソースインジケータをリセットすると、毎時の接続、クエリーまたは更新の制限に達したクライアントは、アクティビティをすぐに再開できます。
FLUSH USER_RESOURCES
は、max_user_connections
システム変数によって制御される同時接続の最大数の制限には適用されません。 セクション6.2.20「アカウントリソース制限の設定」を参照してください。
FLUSH TABLES 構文
FLUSH TABLES
はテーブルをフラッシュし、使用されているバリアントに応じてロックを取得します。 FLUSH
ステートメントで使用される TABLES
バリアントは、使用される唯一のオプションである必要があります。 FLUSH TABLE
は、FLUSH TABLES
のシノニムです。
ここでは、テーブルを閉じることによってフラッシュされることを示す説明は、テーブルの内容をディスクにフラッシュし、開いたままにする InnoDB
には異なる方法で適用されます。 これにより、他のアクティビティによって変更されないかぎり、テーブルが開いている間もテーブルファイルをコピーできます。
-
オープンしているすべてのテーブルをクローズし、使用中のすべてのテーブルを強制的にクローズし、プリペアドステートメントキャッシュをフラッシュします。
この操作には、
FLUSH_TABLES
またはRELOAD
権限が必要です。プリペアドステートメントキャッシュの詳細は、セクション8.10.3「プリペアドステートメントおよびストアドプログラムのキャッシュ」 を参照してください。
アクティブな
LOCK TABLES ... READ
がある場合、FLUSH TABLES
は許可されません。 テーブルをフラッシュしてロックするには、代わりにFLUSH TABLES
を使用します。tbl_name
... WITH READ LOCK -
FLUSH TABLES
tbl_name
[,tbl_name
] ...カンマ区切りのテーブル名のリストでは、サーバーが名前付きのテーブルのみをフラッシュする点を除き、この操作は名前のない
FLUSH TABLES
に似ています。 指定したテーブルが存在しない場合、エラーは発生しません。この操作には、
FLUSH_TABLES
またはRELOAD
権限が必要です。 -
開かれているすべてのテーブルを閉じ、グローバルな読み取りロックを保持しているすべてのデータベースのすべてのテーブルをロックします。
この操作には、
FLUSH_TABLES
またはRELOAD
権限が必要です。この操作は、時間内にスナップショットを取得できる Veritas や ZFS などのファイルシステムがある場合に、バックアップを取得するための非常に便利な方法です。 このロックを解放するには、
UNLOCK TABLES
を使用します。FLUSH TABLES WITH READ LOCK
は、テーブルロックではなくグローバル読取りロックを取得するため、テーブルロックおよび暗黙的コミットに関してLOCK TABLES
およびUNLOCK TABLES
と同じ動作を受けません:UNLOCK TABLES
は、現在LOCK TABLES
でロックされているテーブルがある場合にのみ、アクティブなトランザクションをすべて暗黙的にコミットします。FLUSH TABLES WITH READ LOCK
はテーブルロックを取得しないため、このステートメントに続くUNLOCK TABLES
に対してコミットは発生しません。トランザクションを開始すると、ユーザーが
UNLOCK TABLES
を実行したかのように、LOCK TABLES
によって取得されたテーブルロックが解放されます。 トランザクションを開始しても、FLUSH TABLES WITH READ LOCK
によって取得されたグローバルな読み取りロックは解放されません。
FLUSH TABLES WITH READ LOCK
では、サーバーがログテーブルに行を挿入することは妨げられません (セクション5.4.1「一般クエリーログおよびスロークエリーログの出力先の選択」を参照してください)。 -
FLUSH TABLES
tbl_name
[,tbl_name
] ... WITH READ LOCK指定されたテーブルの読取りロックをフラッシュおよび取得します。
この操作には、
FLUSH_TABLES
またはRELOAD
権限が必要です。 テーブルロックを取得するため、各テーブルに対するLOCK TABLES
権限も必要です。この操作では、最初にテーブルの排他的メタデータロックが取得されるため、これらのテーブルが開いているトランザクションが完了するまで待機します。 次に、操作によってテーブルキャッシュからテーブルがフラッシュされ、テーブルが再オープンされ、テーブルロック (
LOCK TABLES ... READ
など) が取得され、メタデータロックが排他から共有にダウングレードされます。 操作によってロックが取得され、メタデータロックがダウングレードされた後、他のセッションはテーブルの読取りはできますが、変更はできません。この操作は、既存の実テーブル (
TEMPORARY)
以外のテーブル) にのみ適用されます。 名前がベーステーブルを参照している場合は、そのテーブルが使用されます。TEMPORARY
テーブルを参照している場合、その名前は無視されます。 名前がビューに適用される場合は、ER_WRONG_OBJECT
エラーが発生します。 それ以外の場合は、ER_NO_SUCH_TABLE
エラーが発生します。ロックを解放するには
UNLOCK TABLES
を、ロックを解放し、ほかのロックを取得するにはLOCK TABLES
を、またはロックを解放し、新しいトランザクションを開始するにはSTART TRANSACTION
を使用します。この
FLUSH TABLES
バリアントを使用すると、単一の操作でテーブルをフラッシュおよびロックできます。 これにより、アクティブなLOCK TABLES ... READ
がある場合にFLUSH TABLES
が許可されないという制限の回避策が提供されます。この操作では暗黙的な
UNLOCK TABLES
は実行されないため、アクティブなLOCK TABLES
がある間に操作を実行するか、最初に取得したロックを解放せずに再度使用すると、エラーが発生します。フラッシュされたテーブルが
HANDLER
で開かれた場合、そのハンドラは暗黙的にフラッシュされ、その位置を失います。 -
FLUSH TABLES
tbl_name
[,tbl_name
] ... FOR EXPORTこの
FLUSH TABLES
バリアントは、InnoDB
テーブルに適用されます。 これにより、指定されたテーブルへの変更がディスクにフラッシュされ、サーバーの実行中にバイナリテーブルのコピーを作成できるようになります。この操作には、
FLUSH_TABLES
またはRELOAD
権限が必要です。 エクスポートの準備としてテーブルのロックを取得するため、テーブルごとにLOCK TABLES
およびSELECT
権限も必要です。この操作は次のように機能します:
指定されたテーブルに対する共有メタデータロックを取得します。 他のセッションに、それらのテーブルを変更したアクティブなトランザクションがあるか、それらのテーブルのロックを保持しているかぎり、操作はブロックされます。 ロックが取得されると、読取り専用操作の続行を許可しながら、テーブルの更新を試行するトランザクションがブロックされます。
これらのテーブルのすべてのストレージエンジンが
FOR EXPORT
をサポートしているかどうかをチェックします。 存在しない場合は、ER_ILLEGAL_HA
エラーが発生し、操作は失敗します。この操作は、各テーブルのストレージエンジンに、テーブルをエクスポートできるように通知します。 そのストレージエンジンは、保留中の変更がすべてディスクに書き込まれるようにする必要があります。
この操作によってセッションがロックテーブルモードになり、以前に取得したメタデータロックが
FOR EXPORT
操作の完了時に解放されなくなります。
この操作は、既存の (
TEMPORARY
以外の) 実テーブルにのみ適用されます。 名前がベーステーブルを参照している場合は、そのテーブルが使用されます。TEMPORARY
テーブルを参照している場合、その名前は無視されます。 名前がビューに適用される場合は、ER_WRONG_OBJECT
エラーが発生します。 それ以外の場合は、ER_NO_SUCH_TABLE
エラーが発生します。InnoDB
は、独自の.ibd
file ファイル (innodb_file_per_table
設定を有効にして作成されたテーブル) を持つテーブルに対してFOR EXPORT
をサポートしています。InnoDB
では、FOR EXPORT
操作によって変更がディスクにフラッシュされたことが通知されます。 これにより、.ibd
ファイルはトランザクションの一貫性があり、サーバーの実行中にコピーできるため、FOR EXPORT
操作が有効な間にテーブルの内容のバイナリコピーを作成できます。FOR EXPORT
は、InnoDB
システムテーブルスペースファイル、またはFULLTEXT
インデックスを持つInnoDB
テーブルには適用されません。FLUSH TABLES ...FOR EXPORT
は、パーティション化されたInnoDB
テーブルでサポートされています。FOR EXPORT
から通知されると、InnoDB
は、通常はメモリー内か、またはテーブルスペースファイルの外部にある個別のディスクバッファーに保持される特定の種類のデータをディスクに書き込みます。InnoDB
はまた、テーブルごとに、そのテーブルと同じデータベースディレクトリ内に
という名前のファイルも生成します。table_name
.cfg.cfg
ファイルには、あとでテーブルスペースファイルを同じサーバーまたは別のサーバーに再インポートするために必要なメタデータが含まれています。FOR EXPORT
操作が完了すると、InnoDB
はすべての dirty pages をテーブルデータファイルにフラッシュしました。 変更バッファーのエントリはすべて、フラッシュの前にマージされます。 この時点で、テーブルはロックされ、静止します。これらのテーブルはディスク上でトランザクション的に一貫性のある状態にあるため、.ibd
テーブルスペースファイルを対応する.cfg
ファイルとともにコピーすることによって、これらのテーブルの整合性のあるスナップショットを取得できます。コピーされたテーブルデータを MySQL インスタンスに再インポートする手順については、セクション15.6.1.3「InnoDB テーブルのインポート」を参照してください。
テーブルの処理を完了したあと、ロックを解放するには
UNLOCK TABLES
を、ロックを解放し、ほかのロックを取得するにはLOCK TABLES
を、またはロックを解放し、新しいトランザクションを開始するにはSTART TRANSACTION
を使用します。セッション内で次のいずれかのステートメントが有効になっている間は、
FLUSH TABLES ... FOR EXPORT
を使用しようとするとエラーが生成されます。Press CTRL+C to copyFLUSH TABLES ... WITH READ LOCK FLUSH TABLES ... FOR EXPORT LOCK TABLES ... READ LOCK TABLES ... WRITE
セッション内で
FLUSH TABLES ... FOR EXPORT
が有効になっている間は、次のいずれかのステートメントを使用しようとするとエラーが生成されます。Press CTRL+C to copyFLUSH TABLES WITH READ LOCK FLUSH TABLES ... WITH READ LOCK FLUSH TABLES ... FOR EXPORT