MySQL 8.0 リファレンスマニュアル


17.5.1.13 レプリケーションと FLUSH

レプリカにレプリケートすると問題が発生する可能性があるため、一部の形式の FLUSH ステートメントはログに記録されません: FLUSH LOGS および FLUSH TABLES WITH READ LOCK。 構文例は、セクション13.7.8.3「FLUSH ステートメント」を参照してください。 FLUSH TABLES, ANALYZE TABLE, OPTIMIZE TABLE および REPAIR TABLE ステートメントはバイナリログに書き込まれるため、複製に複製されます。 これらのステートメントはテーブルデータを変更しないため、通常は問題ではありません。

ただし、ある状況では、この動作が問題になる場合があります。 mysql データベースで権限テーブルをレプリケートし、GRANT を使用せずにそれらのテーブルを直接更新する場合は、レプリカで FLUSH PRIVILEGES を発行して新しい権限を有効にする必要があります。 また、MERGE テーブルの一部である MyISAM テーブルの名前を変更するときに FLUSH TABLES を使用する場合は、レプリカに対して FLUSH TABLES を手動で発行する必要があります。 NO_WRITE_TO_BINLOG またはそのエイリアスの LOCAL を指定しない場合、これらのステートメントはバイナリログに書き込まれます。


関連キーワード:  ステートメント, ソース, バイナリ, テーブル, FLUSH, ベース, GTID, トランザクション, 構成, ログ