MySQLのFLUSH構文は、内部キャッシュのクリア、リロード、ロックの取得、テーブルのフラッシュなど、構文によってさまざまなことを実行します。今回はFLUSH構文について説明していきます。なお、今回の例で使用しているMySQLのバージョンは8.0.11、各テーブルはInnoDBを想定しています。
FLUSH LOGS構文
FLUSH LOGS構文を利用して各ログファイルをスイッチさせるには、FLUSH <log_type> LOGS
を実行します。log_type
に入るのは、BINARY, ENGINE, ERROR, GENERAL, RELAY,SLOWです。BINARY、RELAYの場合は、FLUSH <log_type> LOGS
を実行すると番号を繰り上げたバイナリログまたはリレーログファイルを生成し、ログスイッチをします。
また、FLUSH RELAY LOGS FOR CHANNEL [channel名]
とするとこで、マルチソースレプリケーションによって出力される各チャンネルのリレーログをそれぞれログスイッチすることが可能です。
ERROR, GENERAL, SLOWログは、それぞれエラーログ、ジェネラルログ、スローログを一度クローズして再度開き直します。もしログファイルをローテートしたい場合は事前に各ログファイル名を変更し、FLUSH <log_type> LOG
を実行します。
log_typeがENGINEの場合は、インストールされているストレージエンジンのフラッシュ可能なログをクローズして、再度開き直します。InnoDBストレージエンジンを利用している場合はログに書き込まれたデータ変更をディスクに書き込みます。
FLUSH LOGS
を実行した場合は、これらすべての操作を実行します。
FLUSH構文のPRIVILEGES、USER_RESOURCES、STATUS、OPTIMIZER_COSTS
FLUSH PRIVILEGES
FLUSH PRIVILEGES
はデータベース内のGRANTテーブルから再読込を実行します。通常、各ユーザ権限とINSTALL PLUGINの情報を、MySQLサーバーはキャッシュに保持しており、この情報を最新化する場合はFLUSH PRIVILEGES
を実行する必要があります。CREATE USERやGRANT構文を実行した場合は自動で再読込が実行されるため必要ありませんが、テーブルを直接変更した場合はFLUSH PRIVILEGES
を実行する必要があります。
詳細については第17回 MySQLのユーザ管理について[その1]の「アカウント情報と mysql.user テーブルの同期」をご覧ください。
FLUSH USER_RESOURCES
もし、CREATE USERやALTER USER構文でユーザの1時間あたりのリソースを制限している場合は、FLUSH USER_RESOURCES
を利用してリソースの制限をリセットすることができます。
リソース制限があった場合、下記のようなエラーが出力されます。
FLUSH STATUS
実行中のセッションステータス変数をリセットします。FLUSH STATUS
によくある誤解もご覧ください。
FLUSH OPTIMIZER_COSTS
mysqlデータベース内のコストモデルテーブル(engine_cost、server_cost)を再読込します。実行後は新規に始まるセッションから影響を受けるため、既存のセッションには影響を受けません。
FLUSH TABLE構文
FLUSH TABLES
オープンしているテーブルをすべて閉じて、使用しているすべてのテーブルを強制的に閉じます。また、プリペアドステートメントのキャッシュをすべて削除します。FLUSH TABLES table_name1, table_name2...
とすることで、特定のテーブルだけに使用することも可能です。
FLUSH TABLES WITH READ LOCK
オープンしているすべてのテーブルを閉じて、読み取りロック(データの更新ができない)を全体に実施します。ロックを解除する場合はUNLOCK TABLESを実施します。FLUSH TABLES tbl_name1, table_name2... WITH READ LOCK
とテーブル名を指定することもできます。
テーブル名を指定した場合は排他的なメタデータロックを取得するため、既存のトランザクションで利用している場合はトランザクションが終了するのを待ちます。テーブル名を指定しない場合は既存のトランザクションに対して暗黙的なコミットが発生します。
FLUSH TABLES ... FOR EXPORT
MySQLが起動したまま、他のサーバーにコピーできるようにします。
この操作が実行されると、対象のテーブルは共有メタデータロックを取得し、トランザクションがある場合はトランザクションが終了するのを待ちます。テーブルのコピーの方法については第55回 innodb_file_per_tableオプションについての「Transportable Tablespaceを利用して他のDBにテーブルをコピーする」をご覧ください。
FLUSH構文とレプリケーション
基本的に、FLUSH LOGS, FLUSH TABLES WITH READ LOCK, FLUSH TABLES tbl_name ... FOR EXPORT
を除くFLUSH構文はバイナリログに書かれるため、レプリケーションを通してスレーブにも影響してしまいます。もし、バイナリログに出さないようにしたい場合は、FLUSH NO_WRITE_TO_BINLOG PRIVILEGES
のようにNO_WRITE_TO_BINLOGまたはLOCALをつけて実行するか、SQL_LOG_BINをOFFにして実行する必要があります。