ApsaraDB RDS:ApsaraDB RDS for MySQL の一般クエリログ機能に関するよくある質問

ApsaraDB RDS で一般クエリログをテーブルに保存する理由

ApsaraDB RDS for MySQL では、デフォルトで一般クエリログをファイルではなくデータベーステーブルに保存します。その理由は次の 2 つです。

• ユーザーは ApsaraDB RDS インスタンス上のファイルに直接アクセスできないため、ファイルベースのログはクエリやダウンロードができません。

• log_output パラメータは、一般クエリログとスロークエリログの両方の出力形式を制御します。ApsaraDB RDS ではスロークエリログをローテーションし、テーブルに保存する必要があるため、一般クエリログもテーブルに保存する必要があります。

一般クエリログがストレージを枯渇させる理由

インスタンスで実行される各 SQL ステートメントがログエントリを生成します。一般クエリログを長期間有効にした場合、またはインスタンスが大量のクエリを処理する場合、mysql.general_log テーブルは継続的に増大します。テーブルを定期的にクリアしないと、インスタンスのストレージが一杯になります。

一般クエリログがストレージの問題を引き起こしていることを確認するには、次の手順を実行してください。

1. インスタンス監視ページでストレージ使用量を確認してください。sys_data_size が異常に大きい場合は、テーブルデータがストレージを消費しています。詳細については、「監視情報を表示する」をご参照ください。

2. インスタンスパラメーターを表示し、general_log が ON に設定されている場合、機能は有効です。

一般クエリログがパフォーマンスの問題を引き起こす理由

一般クエリログが有効になっている場合、SQL ステートメントを実行するすべてのスレッドは mysql.general_log テーブルに行を書き込む必要があります。この書き込み操作にはメタデータロック (MDL) とテーブルロックの両方が必要なため、スレッドは並列ではなくテーブルに順次書き込みます。

接続数が多い状況では、多数のスレッドが同時にこれらのロックを競合し、接続が Waiting for table level lock 状態になります。接続数が増加すると、CPU 使用率も増加します。

確認するには、SHOW PROCESSLIST を実行するか、innodb_trx テーブルにクエリを実行します。多数の接続が Waiting for table level lock を示している場合、一般クエリログがロック競合の原因となっています。

一般クエリログによって復旧時間が長くなる理由

ApsaraDB RDS インスタンスが予期せずシャットダウンした場合、一般クエリログのクラッシュマーカーが true に設定されます。再起動時に、インスタンスは自動復旧プロセスを開始します。ApsaraDB RDS インスタンス上のテーブルのサイズが大きい場合、それらの復元には長時間かかり、その間インスタンスは使用できません。これにより、復旧時間が直接延長されます。

ソリューション

1. general_log を OFF に設定して、新しいログエントリの書き込みを停止します。「インスタンスパラメーターの変更」をご参照ください。

2. 特権アカウントを使用してインスタンスに接続します。詳細については、「ApsaraDB RDS for MySQL インスタンスに接続する」をご参照ください。

3. ログテーブルをクリアします。

   MySQL 5.6 を実行しているインスタンスでは、TRUNCATE ステートメントはサポートされていません。これらのインスタンスでは、ログをクリアするために テクニカルサポート にお問い合わせください。バージョン固有の機能サポートの完全なリストについては、「機能」をご参照ください。TRUNCATE ステートメントを特権アカウントで実行するには、インスタンスがサポート対象のマイナーエンジンバージョン (ApsaraDB RDS for MySQL 5.7 の場合は 20210630 以降、ApsaraDB RDS for MySQL 8.0 の場合は 20210930 以降) を実行している必要があります。これより前のマイナーエンジンバージョンを実行するインスタンスでは、TRUNCATE ステートメントは特権アカウントであっても失敗します。その場合は、チケットを起票してテクニカルサポートにログのクリアを依頼してください。

   TRUNCATE TABLE mysql.general_log;

ログをクリアした後、インスタンスの監視ページを確認して、ストレージ使用量が減少していることを確認してください。

SQL 分析の代替手段

通常の運用中は一般クエリログを無効にしておいてください。短時間のデバッグセッションのためにのみ有効にし、その後すぐに無効にしてテーブルをクリアしてください。

継続的な SQL 分析には、代わりに次のいずれかのアプローチを使用してください。

• SQL エクスプローラーと監査 (推奨): この機能を有効にすると、SQL ステートメントが自動的に記録および分析されます。 データは Database Autonomy Service (DAS) に保存され、RDS インスタンスのストレージを消費しないため、インスタンスのパフォーマンスに影響はありません。 詳細については、「SQL エクスプローラーと監査機能を使用する」をご参照ください。

• 一時的な一般クエリログ: 特定の問題をデバッグする必要がある場合は、一般クエリログを有効にしてから、ログテーブルにクエリを実行して SQL アクティビティを確認します。

  SELECT * FROM mysql.general_log;

  デバッグが完了したらすぐに機能を無効にし、テーブルをクリアしてください。

ストレージがすでに枯渇している場合の対処方法

ログをクリアする前にインスタンスのストレージが不足した場合は、ストレージ容量を拡張してください。

• 手動拡張: インスタンス仕様を変更してストレージを拡張します。「インスタンス仕様の変更」をご参照ください。

• 自動拡張： ストレージの自動拡張を設定して、使用量が指定されたしきい値に達したときにシステムがストレージを拡張するようにします。 詳細については、「ストレージの自動拡張を設定する」をご参照ください。