FLUSH [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テーブルを切り捨てます:TRUNCATE TABLE performance_schema.host_cache;TRUNCATE TABLE操作には、RELOAD権限ではなく、テーブルに対するDROP権限が必要です。 -
サーバーが書き込んでいるログファイルを閉じて再度開きます。
この操作には、
RELOAD権限が必要です。この操作の効果は、次の操作を組み合せた効果と同等です:
FLUSH 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 CHANNELchannel]サーバーが書き込んでいるリレーログファイルを閉じてから再度開きます。 リレーロギングが有効になっている場合、リレーログファイルのシーケンス番号は、前のファイルを基準にして 1 ずつ増分されます。
この操作には、
RELOAD権限が必要です。FOR CHANNEL句を使用すると、操作を適用するレプリケーションチャネルの名前を指定できます。channelFLUSH 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 TABLEStbl_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 TABLEStbl_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 TABLEStbl_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は、独自の.ibdfile ファイル (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を使用しようとするとエラーが生成されます。FLUSH TABLES ... WITH READ LOCK FLUSH TABLES ... FOR EXPORT LOCK TABLES ... READ LOCK TABLES ... WRITEセッション内で
FLUSH TABLES ... FOR EXPORTが有効になっている間は、次のいずれかのステートメントを使用しようとするとエラーが生成されます。FLUSH TABLES WITH READ LOCK FLUSH TABLES ... WITH READ LOCK FLUSH TABLES ... FOR EXPORT