MySQL管理標準ルール

バイナリ・ログのデバッグ情報が無効化されている

説明: バイナリ・ログでは、発生したDML、DDLおよびセキュリティ変更が取得され、これらの変更がバイナリ形式で格納されます。バイナリ・ログによって、Point-in-Timeリカバリが可能になり、障害回復の状況でのデータ損失を防止できます。また、これにより、データベースに対する変更すべてをレビューできるようになります。binlog_rows_query_log_eventsシステム変数は、行ベースのロギングのみに影響します。有効になっている場合は、MySQLサーバーによって情報ログ・イベント(行問合せログ・イベントなど)がそのバイナリ・ログに書き込まれるようになります。この情報は、デバッグおよび関連する目的に使用できます(ソース・サーバーで発行された元の問合せを、その行更新から再構築できないときに取得するなど)。これらのイベントは、通常は、MySQLで、また、そのバイナリ・ログを読み取るそれ以降のプログラムで無視されます。そのため、レプリケーションや、バックアップからリストアのときに問題は発生しません。

重大度: マイナー警告

アドバイス: 使用している環境にとって情報ログ・イベント(行問合せログ・イベントなど)をバイナリ・ログに書き込むことが適切であるかどうかを調査します。ログに追加情報を取得するには、この機能をオンにします。binlog_rows_query_log_eventsシステム変数の値を動的にONに設定し、その新しい値をMySQL構成ファイル(my.cnf)の[mysqld]セクションに配置できます。それにより、このサーバーの再起動時にそれが有効のままになります。

バイナリ・ロギングが制限されている

説明: バイナリ・ログでは、発生したDML、DDLおよびセキュリティ変更が取得され、これらの変更がバイナリ形式で格納されます。バイナリ・ログによって、Point-in-Timeリカバリが可能になり、障害回復の状況でのデータ損失を防止できます。また、これにより、データベースに対する変更すべてをレビューできるようになります。バイナリ・ロギングは、--binlog-do-dbオプションと--binlog-ignore-dbオプションを使用することで特定のデータベースに限定できます。ただし、これらのオプションを使用すると、それに応じてPoint-in-Timeリカバリ・オプションが制限され、システムに加えられた変更を確認する機能も制限されます。

重大度: マイナー警告

アドバイス: MySQL構成ファイル(my.cnf)内の--binlog-do-db設定と--binlog-ignore-db設定を調べて、重要なデータベースすべてに対する更新を取得していることを確認します。それらは現在、サーバーで--binlog-do-db : %binlog_do_db%と--binlog-ignore- db : %binlog_ignore_db%のように設定されています。

バイナリ・ロギングが有効化されていない

説明: バイナリ・ログでは、発生したDML、DDLおよびセキュリティ変更が取得され、これらの変更がバイナリ形式で格納されます。バイナリ・ログによって、Point-in-Timeリカバリが可能になり、障害回復の状況でのデータ損失を防止できます。また、これにより、データベースに対する変更すべてをレビューできるようになります。

重大度: マイナー警告

アドバイス: MySQL構成ファイル(my.cnf)の[mysqld]セクションにlog-bin構成変数を設定することで、Point-in-Timeリカバリのバイナリ・ロギングを有効にします。

バイナリ・ロギングで書込みごとにディスクに同期されない

説明: デフォルトでは、バイナリ・ログの内容はディスクに同期されません。サーバー・ホスト・マシンやオペレーティング・システムがクラッシュした場合は、バイナリ・ログでの最新のイベントがディスクに残らない可能性があります。この動作は、sync_binlogサーバー変数を使用して変更できます。この変数の値が0より大きい場合は、sync_binlogのコミット・グループがそのバイナリ・ログに書き込まれた後に、MySQLサーバーによってそのバイナリ・ログがディスクに同期されます(fdatasync()を使用)。sync_binlogのデフォルト値は0 (ディスクへの同期なし)です。この場合、このサーバーでは、そのバイナリ・ログの内容は、他のファイルの場合と同様に、オペレーティング・システムへの依存によって時々フラッシュされます。値1が最も安全な選択肢です(クラッシュ発生時にバイナリ・ログから失われるコミット・グループが最大でも1つであるため)。ただし、それは最も遅い選択肢でもあります(ディスクにバッテリ付きキャッシュがある場合を除きます。これがあると同期が非常に速くなります)。

重大度: マイナー警告

アドバイス: MySQL構成ファイル(my.cnf)の[mysqld]セクション内でsync_binlog = 1を設定して、ハードウェア、OSおよびMySQLサーバーのクラッシュからのリカバリについて、最大限の安全性を確保します。

バイナリ・ログの自動削除が早すぎる

説明: バイナリ・ログでは、発生したDML、DDLおよびセキュリティ変更が取得され、これらの変更がバイナリ形式で格納されます。バイナリ・ログによって、Point-in-Timeリカバリが可能になり、障害回復の状況でのデータ損失を防止できます。これは、ソース・レプリケーション・サーバーで、レプリカ・サーバーに送信される文の記録として使用されます。また、これにより、データベースに対する変更すべてをレビューできるようになります。ただし、それらで使用されるログ・ファイル数と領域は急速に増加する可能性があるため(特に、ビジー状態のサーバー上)、適切なバックアップが実行されている場合は、これらのファイルを、不要になった時点で定期的に削除することが重要です。binlog_expire_logs_secondsパラメータを使用すると、バイナリ・ログの自動削除が可能になります。

重大度: マイナー警告

アドバイス: バイナリ・ログが%expire_logs_days%日ごとに自動的に削除される理由を調査します。これは、使用している環境に適した設定である場合がありますが、異常に低いため、障害回復シナリオをサポートするのに十分なバックアップ計画と実行であることを確認してください。必要に応じて、expire_logs_daysの設定を、ディスク使用量を最小限に抑えながら、使用している環境内の安全かつセキュアな操作が保証される値に増やし、バイナリ・ログが、少なくとも最後の全体バックアップの時点まで戻るようにしてください。また、このサーバーの再起動時に正しく設定されるように、必ずMySQL構成ファイル(my.cnf)内のexpire_logs_daysの値を更新してください。

識別子の大/小文字の区別が原因でデータベースを移植できない場合がある

説明: 基にあるオペレーティング・システムで大/小文字が区別されているかどうかで、データベース名と表名での大/小文字の区別が決まります。MySQLを1つのプラットフォームのみで使用している場合は、このことを気にする必要はありません。しかしながら、サーバーの構成内容によっては、ファイルシステムの大/小文字の区別が異なる複数のプラットフォームの間で表を転送する必要がある場合に問題が発生することがあります。

重大度: マイナー警告

アドバイス: MySQL構成ファイル(my.cnf)内でlower_case_table_names=1を設定し、MySQLサーバーを再起動します。なお、Unixでlower_case_table_namesシステム変数を1に設定する予定の場合は、まず古いデータベース名と表名を小文字に変換してから、その新しい変数設定でmysqldを再起動する必要があります。

イベント・スケジューラが無効化されている

説明: イベント・スケジューラは、有効にすると非常に役立つ機能です。これは、特定の時点や定期的な間隔でSQLコマンドを実行するためのフレームワークです。概念上は、UNIXのcrontab ("cronジョブ"とも呼ばれる)やWindowsタスク・スケジューラに似ています。そのアーキテクチャの基本は単純です。イベントとは、開始日時と反復タグが指定されたストアド・ルーチンです。それは、定義されアクティブ化された後、リクエストされると実行されます。トリガーとは異なり、イベントは、特定の表操作ではなく日時にリンクされています。イベント・スケジューラの使用により、データベース管理者は、最小限の労力で反復的なイベントを実行できます。一般的な使用方法としては、古くなったデータのクリーン・アップ、統計のためのサマリー表の作成、サーバーのパフォーマンスと使用状況のモニタリングがあります。

重大度: マイナー警告

アドバイス: イベント・スケジューラを有効にし、それを使用して反復的なイベントを自動化します。MySQL構成ファイル(my.cnf)の[mysqld]セクションにevent_scheduler=1という行を追加して、サーバーの再起動時にその変数が正しく設定されるようにします。

一般問合せログが有効化されている

説明: 一般問合せログとは、mysqldの実行内容の一般的な記録です。このサーバーでは、クライアントが接続または切断されたときこのログに情報が書き込まれ、クライアントから受け取った各SQL文がログ記録されます。一般問合せログは、クライアントにエラーの疑いがありクライアントからmysqldに送信された内容を正確に知る必要があるときに役立つ可能性あります。ただし、本番環境では一般問合せログを有効にしないでください。理由: それによってこのサーバーに対するオーバーヘッドが増大します。文が実行順ではなく受信順にログ記録されるため、バックアップ/リカバリの際にはそれを信頼できません。それは増大が速く、多くのディスク領域を使用する可能性があります。かわりにバイナリ・ログを使用してください。

重大度: マイナー警告

アドバイス: 一般問合せログを無効にします。MySQL構成ファイル(my.cnf)からこのログ・オプションを削除するか、MySQLサーバーを起動するスクリプトから--logオプションを削除します。

インメモリー一時表のサイズはHEAP表の最大サイズによって制限される

説明: 一時表の作成に必要な領域がtmp_table_sizeまたはmax_heap_table_sizeを超えた場合は、MySQLによって、このサーバーのtmpdirディレクトリにディスクベースの表が作成されます。パフォーマンス上の理由から、ほとんどの一時表をメモリー内に作成し、非常に大きい一時表のみをディスク上に作成するのが理想的です。多くのDBAは、tmp_table_sizeは適切に構成しますが、max_heap_table_sizeも関係していることを忘れてしまいます。

重大度: マイナー警告

アドバイス: max_heap_table_sizeをtmp_table_size以上に設定することを検討してください。変数tmp_table_sizeは、現在、%tmp_table_size%に設定されており、max_heap_table_sizeは%max_heap_table_size%に設定されています。

InnoDB厳密モードがオフになっている

説明: SQLでタイポと構文エラーが無視されることや、操作モードとSQLコマンドの様々な組合せによってもたらされるその他の意図しない結果を防ぐため、InnoDBでは、動作の"厳密モード"が用意されています。このモードのInnoDBでは、警告が発行され指定コマンド(おそらく、意図していないデフォルトを使用)が処理されるのではなく、明白な場合にはエラー状態が発生します。これは、MySQLのsql_mode (MySQLでの受入れ対象のSQL構文を制御する)に似ており、エラーを警告なしで無視するか入力構文とデータ値を検証するかを決定します。厳密モードで実行していないときに、CREATE TABLEコマンド、ALTER TABLEコマンドおよびCREATE INDEXコマンドでのROW_FORMATとKEY_BLOCK_SIZEに新しい句と設定を使用すると、混乱を招く可能性があります。厳密モードで実行していない場合、InnoDBでは、特定の構文エラーは無視され、表や索引が作成され、メッセージ・ログに警告のみが含まれます。しかしながら、InnoDB厳密モードがオンの場合は、このようなエラーがあるとすぐにエラーが生成され、表や索引は作成されません。そのため、コマンドが発行された時点でエラーを捕捉できることで時間の節約になります。

重大度: マイナー警告

アドバイス: innodb_strict_mode変数がOFFに設定されている理由を調査します。innodb_strict_mode=1をMySQL構成ファイル(my.cnf)に追加して、サーバーの再起動時にそれが正しく設定されるようにします。

InnoDBシステム表領域を自動的に拡張できない

説明: 受信データによる需要に応じてInnoDBシステム表領域を自動拡張できない場合は、アプリケーションによって空き領域より多くのデータが生成されると、容量不足エラーが発生し、アプリケーションに問題が発生することがあります。

重大度: マイナー警告

アドバイス: MySQL構成ファイル(my.cnf)内のinnodb_data_file_path変数にautoextendキーワードを含めることで、InnoDBシステム表領域を自動拡張されるように構成します。フラグメンテーションのレベルを低く保つために役立つよう、自動拡張の増分(InnoDB表領域を拡大する領域量)の量を大きいサイズに設定します。

InnoDBトランザクション・ログのサイズ設定が不適切である

説明: 頻繁なチェックポイント・アクティビティを防ぎ、全体的な物理I/O (これにより、書込みの多いシステムが低速になる可能性がある)を減らすには、InnoDBトランザクション・ログを、InnoDBバッファ・プールのサイズに応じて、そのバッファ・プールのサイズの約50-100%にする必要があります。

重大度: マイナー警告

アドバイス: InnoDBトランザクション・ログのサイズを大きくします。ただし、トランザクション・ログが大きいほど、クラッシュのリカバリ時間が長くなり、チェックポインティング期間が集中的になる可能性があります。これは、バッファ・プールとログから表領域のデータファイルにフラッシュする必要があるデータがより多くなるためです。これを念頭に置くと、お薦めの最大サイズは、ログ・ファイルごとに1 GBとなります。ログ・ファイルのサイズを変更するには、MySQLを正常に停止し、MySQL構成ファイル(my.cnf)内でそれに応じてinnodb_log_file_sizeの値を変更し、現在のib_logfile*ファイルをデータ・ディレクトリから別の場所に移動し、新しいログ・ファイルを自動的に作成できるようにMySQLを再起動します。

警告がログ記録されない

説明: MySQLサーバーによって発生したエラー条件は必ずエラー・ログに記録されますが、警告条件は、log_warningsが0より大きい値に設定されている場合のみ記録されます。警告がログ記録されない場合は、接続の中断やその他の様々な通信エラーについて、重要な情報が取得されません。これは特に、レプリケーションを使用しており、発生している事柄について詳細情報(ネットワーク障害や再接続に関するメッセージなど)を取得する場合に重要となります。なお、MySQL 5.7.2以降では、log_error_verbosityシステム変数はlog_warningsよりも優先されており、それのかわりに使用する必要があります。

重大度: マイナー警告

アドバイス: log_warningsが0に設定されている理由を調査します。警告をログに記録しない明確かつ説得力のある理由がないかぎりは、log_warningsを0より大きい値に設定します。ただし、log_warningsの値を選択するときは、バグ#42851とバグ#46265に留意してください。特定の文でバイナリ・ロギングを使用する場合に、log_warnings = 2を設定すると、それらの文に関する警告でエラー・ログがあふれる可能性があります。そのような場合は、行ベースのロギングを使用できるかどうかを確認します(この形式は常に安全であるため)。重要なノート: MySQL 5.7.2以降では、log_error_verbosityシステム変数はlog_warningsよりも優先されており、それのかわりに使用する必要があります。この変数がlog_error_verbosityにどのように関連するかについては、http://dev.mysql.com/doc/mysql/en/server-system-variables.html#sysvar_log_warningsの説明を参照してください。具体的には、log_warningsに値を割り当てるとlog_error_verbosityに値が割り当てられ、その逆も同様です。また、MySQL Server 5.7.11で追加されたlog_statements_unsafe_for_binlogオプションにも留意してください。これは、エラー1592が発生した場合に、生成された警告をエラー・ログに追加するかどうかを制御します。