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

5.4.6 サーバーログの保守

セクション5.4「MySQL Server ログ」で説明したように、MySQL Server は実行中のアクティビティーの内容を確認するのに役立ついくつかの異なるログファイルを作成することができます。 ただし、多くのディスクスペースを占有しすぎないようにするために、これらのファイルを定期的にクリーンアップする必要があります。

ロギングを有効にして MySQL を使用しているとき、古いログファイルをときどきバックアップおよび削除して、新しいファイルへのロギングを開始するよう MySQL に指示することが必要な場合があります。 セクション7.2「データベースバックアップ方法」を参照してください。

Linux (Red Hat) インストールでは、mysql-log-rotate スクリプトを使用してログのメンテナンスを行うことができます。 RPM 配布から MySQL をインストールした場合、このスクリプトは自動的にインストールされているはずです。 レプリケーション用にバイナリログを使用している場合、このスクリプトには注意が必要です。 バイナリログの内容がすべてのレプリカによって処理されていることが確実になるまで、バイナリログを削除しないでください。

ほかのシステムでは、ログファイルを処理するための、cron (またはその同等物) で開始する短いスクリプトを自分でインストールする必要があります。

バイナリログファイルは、サーバーのバイナリログの有効期限後に自動的に削除されます。 ファイルの削除は、起動時およびバイナリログのフラッシュ時に実行できます。 デフォルトのバイナリログの有効期限は 30 日です。 別の有効期限を指定するには、binlog_expire_logs_seconds システム変数を使用します。 レプリケーションを使用している場合は、レプリカがソースより遅れる可能性のある最大時間以下の有効期限を指定する必要があります。 バイナリログをオンデマンドで削除するには、PURGE BINARY LOGS ステートメントを使用します (セクション13.4.1.1「PURGE BINARY LOGS ステートメント」を参照してください)。

MySQL で新しいログファイルの使用を強制的に開始するには、ログをフラッシュします。 ログのフラッシュは、FLUSH LOGS ステートメント、mysqladmin flush-logs, mysqladmin refresh, mysqldump --flush-logs または mysqldump --master-data コマンドを実行すると発生します。 セクション13.7.8.3「FLUSH ステートメント」、セクション4.5.2「mysqladmin — A MySQL Server 管理プログラム」、およびセクション4.5.4「mysqldump — データベースバックアッププログラム」を参照してください。 また、現在のバイナリログファイルサイズが max_binlog_size システム変数の値に達すると、サーバーはバイナリログを自動的にフラッシュします。

FLUSH LOGS は、個々のログの選択的なフラッシュを可能にするためのオプションの修飾子をサポートします (FLUSH BINARY LOGS など)。 セクション13.7.8.3「FLUSH ステートメント」を参照してください。

ログフラッシュ操作には、次の効果があります:

• バイナリロギングが有効化されている場合、サーバーは現在のバイナリログファイルを閉じ、新しいログファイルを次のシーケンス番号で開きます。

• ログファイルへの一般クエリーロギングまたはスロークエリーロギングが有効になっている場合、サーバーはログファイルを閉じてから再度開きます。

• エラーログがファイルに書き込まれるようにするためにサーバーが --log-error オプションで開始されている場合、サーバーはログファイルを閉じて再オープンします。

ログフラッシュステートメントまたはコマンドを実行するには、RELOAD 権限を持つアカウントを使用してサーバーに接続する必要があります。 Unix および Unix に似たシステムでは、ログをフラッシュする別の方法は、サーバーにシグナルを送信することです。これは、root またはサーバープロセスを所有するアカウントによって実行できます。 (セクション4.10「MySQL での Unix シグナル処理」を参照してください。) シグナルを使用すると、サーバーに接続せずにログフラッシュを実行できます:

• SIGHUP シグナルはすべてのログをフラッシュします。 ただし、SIGHUP には、望ましくないログフラッシュ以外の効果があります。

• MySQL 8.0.19 の時点で、SIGUSR1 により、サーバーはエラーログ、一般クエリーログおよびスロークエリーログをフラッシュします。 これらのログのみをフラッシュする場合は、SIGUSR1 を、ログに関連しない SIGHUP 効果を持たないより多くの「「軽量」」シグナルとして使用できます。

前述のように、バイナリログをフラッシュすると新しいバイナリログファイルが作成されますが、一般クエリーログ、スロークエリーログ、またはエラーログをフラッシュすると、ログファイルが閉じて再度開きます。 後者のログの場合、Unix で新しいログファイルが作成されるようにするには、まず現在のログファイルの名前を変更してからフラッシュします。 フラッシュ時に、サーバーは元の名前で新しいログファイルを開きます。 たとえば、一般クエリーログ、スロークエリーログ、およびエラーログファイルの名前が mysql.log、mysql-slow.log、および err.log である場合は、コマンド行から次のような一連のコマンドを使用できます:

cd mysql-data-directory
mv mysql.log mysql.log.old
mv mysql-slow.log mysql-slow.log.old
mv err.log err.log.old
mysqladmin flush-logs

Windows では、mv の代わりに rename を使用してください。

この時点で、mysql.log.old、mysql-slow.log.old および err.log.old のバックアップを作成し、ディスクから削除できます。

実行時に一般クエリーログまたはスロークエリーログの名前を変更するには、まずサーバーに接続し、ログを無効にします:

SET GLOBAL general_log = 'OFF';
SET GLOBAL slow_query_log = 'OFF';

ログを無効にして、ログファイルの名前を外部 (たとえば、コマンドラインから) に変更します。 次に、ログをふたたび有効にします。

SET GLOBAL general_log = 'ON';
SET GLOBAL slow_query_log = 'ON';

この方法はすべてのプラットフォームで動作し、サーバー再起動を必要としません。

注記

外部でファイルの名前を変更した後にサーバーが特定のログファイルを再作成するには、ファイルの場所がサーバーによって書込み可能である必要があります。 これは常に当てはまるわけではありません。 たとえば、Linux では、サーバーはエラーログを/var/log/mysqld.log として書き込むことができます。ここで、/var/log は root によって所有され、mysqld によって書込み可能ではありません。 この場合、ログフラッシュ操作は新しいログファイルの作成に失敗します。

この状況に対処するには、元のログファイルの名前を変更した後、適切な所有権を持つ新しいログファイルを手動で作成する必要があります。 たとえば、次のコマンドを root として実行します:

mv /var/log/mysqld.log /var/log/mysqld.log.old
install -omysql -gmysql -m0644 /dev/null /var/log/mysqld.log