よくあるMySQLエラーとその迅速な修正方法

MySQLエラーは通常、素早く最初に読む必要があります：エラーログを確認し、失敗したクエリやスレッドを特定し、アプリケーションの症状だけで推測しないこと。パフォーマンスのボトルネックから重大なサービス障害まで、一般的なエラーを迅速に診断して解決する方法を理解することは、高可用性を維持するために不可欠です。

このガイドでは、迅速にトリアージできる一般的なMySQL障害（スロークエリ、デッドロック、レプリケーション遅延、破損警告）をカバーします。

MySQLエラーの特定と診断

修正を適用する前に、正確な特定が鍵です。MySQL診断情報の主なソースは、MySQLエラーログとスロークエリログです。これらを最初に確認することが、問題の根本原因を特定する最も効果的な方法です。

MySQLエラーログの確認

エラーログは、サーバーの重要なイベント、起動/シャットダウン情報、重大なエラーを記録します。その場所はオペレーティングシステムと設定によって異なりますが、多くの場合データディレクトリにあります。

ヒント： 正確なパスがわからない場合は、SHOW VARIABLES LIKE 'log_error'; などのコマンドを使用して見つけてください。

スロークエリログの活用

明示的なエラーメッセージなしでパフォーマンスが低下した場合、スロークエリログが次の確認先です。これは、事前定義された実行時間を超えるクエリをキャプチャします。

有効にするには（まだアクティブでない場合）、設定ファイル（my.cnf または my.ini）でこれらの変数を設定し、サーバーを再起動する必要があります：

[mysqld]
slow_query_log = 1
long_query_time = 2  # 2秒以上かかるクエリをログに記録
slow_query_log_file = /var/log/mysql/mysql-slow.log

一般的なエラーシナリオと即時修正

MySQL環境で最も頻繁に発生する運用上の課題の4つと、それらを解決するための実用的な手順を以下に示します。

1. スロークエリのパフォーマンス

スロークエリは最も一般的なパフォーマンス低下の原因です。多くの場合、インデックスの欠如、非効率的なクエリ構造、またはデータベース設計の不備に起因します。

診断

スロークエリログを分析します。特定のスロークエリについては、EXPLAIN コマンドを使用してMySQLがどのように実行するかを確認します：

EXPLAIN SELECT * FROM large_table WHERE column_a = 'value';

type: ALL（フルテーブルスキャン）や過剰な行数が検査されていないか確認します。

迅速な修正

不足しているインデックスを追加： EXPLAIN が頻繁にフィルタリングされるカラムでフルスキャンを示す場合、そのカラムにインデックスを作成します：CREATE INDEX idx_column_a ON large_table (column_a);
クエリを書き換える： 本番コードでは SELECT * を避けてください。JOIN は慎重に使用し、WHERE 句がインデックス付きカラムを使用するようにしてください。
テーブル統計を分析： 時々、古い統計情報がオプティマイザを混乱させることがあります。ANALYZE TABLE table_name; を実行します。

2. トランザクションデッドロック

デッドロックは、2つ以上のトランザクションが互いに保持されているロックを待機しているときに発生し、停止状態になります。MySQL（InnoDBを使用）は通常、これを自動的に検出し、1つのトランザクションをロールバックして解決します。

診断

エラーログで LATEST DETECTED DEADLOCK を参照するメッセージを確認します。InnoDBステータスを確認することもできます：

SHOW ENGINE INNODB STATUS;

TRANSACTIONS セクションの下で、詳細なデッドロックグラフを探します。これにより、どのトランザクションが関与し、どのステートメントが待機を引き起こしたかが示されます。

迅速な修正

トランザクションを短くする： トランザクションは可能な限り短く保ちます。迅速にコミットまたはロールバックします。
一貫したアクセス順序： すべてのアプリケーションコードが、同じ定義された順序でテーブルと行にアクセスするようにします。トランザクションAがテーブルXをロックしてからテーブルYをロックする場合、トランザクションBもXをロックしてからYをロックする必要があります。
行レベルロックを使用： UPDATE および DELETE ステートメントで適切な WHERE 句を使用して、InnoDBがテーブル全体ではなく必要な行のみをロックできるようにします（ただし、InnoDBはトランザクションテーブルに対してデフォルトで行レベルロックを使用します）。

3. レプリケーションの遅延または障害

ソース-レプリカ構成では、レプリカがソースに遅れを取り、古い読み取りが発生するとレプリケーション遅延が発生します。古いMySQLコマンドとフィールドは依然として master および slave の用語を使用しているため、本番環境では両方の名前が表示される場合があります。

診断

IO および SQL スレッドを使用してレプリカのステータスを確認します：

SHOW REPLICA STATUS\G
-- 古いMySQLバージョンでは：SHOW SLAVE STATUS\G

確認すべき主要フィールド：

Replica_IO_Running または Slave_IO_Running：Yes である必要があります。
Replica_SQL_Running または Slave_SQL_Running：Yes である必要があります。
Seconds_Behind_Source または Seconds_Behind_Master：遅延を秒単位で示します。この値が増加している場合、レプリカは遅れています。

迅速な修正

SQLスレッドエラーの解決： SQLアプライヤーが停止している場合、最後のSQLエラーを確認します。sql_slave_skip_counter または新しいレプリケーションコマンドでイベントをスキップするとデータドリフトが発生する可能性があるため、失敗したトランザクションを理解し、データを調整する計画がある場合にのみ使用してください。
レプリカリソースの増加： 書き込み負荷が高い状態で遅延が一貫している場合、レプリカはバイナリログイベントを十分に迅速に処理するために、より多くのCPUまたはより高速なディスクI/Oを必要とする可能性があります。
再同期： 遅延が深刻であるか、レプリカが壊れている場合、レプリケーションを停止し、レプリカがソースの正しいバイナリログ位置を指していることを確認してから再起動します。

4. データ破損エラー

データ破損は、現代のInnoDBセットアップではまれですが、サーバーの起動不能、チェックサムエラー、または奇妙なクエリ結果として現れることがあります。破損は多くの場合、ハードウェア障害（ディスク/メモリ）または不適切なシャットダウンを示します。

診断

破損は通常、エラーログの起動失敗メッセージで即座に明らかになり、多くの場合、テーブルスペースまたは特定のページがチェックサムテストに失敗したことを参照します。

迅速な修正

テーブルチェック/修復の実行（MyISAM）： MyISAMテーブルの場合、CHECK TABLE table_name; の後に REPAIR TABLE table_name; を使用します。
InnoDBリカバリモード： InnoDBが起動に失敗した場合、一時的にリカバリモードで起動してデータをダンプできます：
```
[mysqld]
innodb_force_recovery = 1
```
サーバーを起動し、mysqldump を使用してすべての重要なデータをすぐにダンプし、シャットダウンし、破損したデータファイルを削除し、リカバリフラグなしで再起動します。

警告： innodb_force_recovery は決して永続的に使用しないでください。重要なチェックをバイパスし、書き込みが試行されるとさらなるデータ劣化を引き起こす可能性があります。
バックアップから復元： 深刻な破損に対する最も安全な解決策は、最後に確認された正常なバックアップからデータベース全体を復元することです。

まとめ

MySQLの問題は、推測ではなく証拠から修正してください。エラーログ、スロークエリログ、EXPLAIN、InnoDBステータス、レプリケーションステータスは、通常次のステップを示します。破損回復やレプリケーションスキップコマンドに触れる前に、バックアップがテストされていることを確認してください。

ベストプラクティス：プロアクティブな監視

最も迅速な修正は、多くの場合予防です。包括的な監視ツール（Prometheus/Grafana、Percona Monitoring and Management（PMM）、またはクラウドプロバイダーツールなど）を実装して、主要なメトリクスを監視します：

接続数とスレッドキャッシュヒット率。
InnoDBバッファプールの使用率とヒット率。
レプリケーション遅延（Seconds_Behind_Master）。
ディスクI/O使用率。

これらのメトリクスに基づくアラートにより、スロークエリやレプリケーションの問題が重大な障害に発展する前に対処できます。