MySQL データベースのクラッシュの一般的な原因と解決策は何ですか?

MySQL データベースの起動時間を確認する

Linux システムの systemd と mysqld_safe は、mysqld プロセスがクラッシュした後、自動的に MySQL サービスを再起動します。 kill -9 を使用して mysqld プロセスを強制終了すると、システムは自動的に再起動しますが、kill コマンドを使用するだけでは再起動されません。kill コマンドを実行すると、システムが mysqld に SIGTERM シグナルを送信するためです。 、mysql データベースが正常にシャットダウンされ、ログに次のようなレコードが表示されます:

2020-10-26T09:06:48.435181Z 0 [System] [MY- 010910] [サーバー] /usr/sbin/mysqld: シャットダウンが完了しました (mysqld 8.0.19 ) MySQL Community Server - GPL.

MySQL データベースはクラッシュ後に再起動されるため、状況がわからない場合がありますthat MySQL データベースがクラッシュしましたが、次のように mysql データベースの起動時間から手がかりを見つけることができます MySQL データベースの起動時間を確認する 4 つの方法を紹介します。

MySQL サービスのステータスを確認すると、

scutech@scutech:~$ service mysql status
● mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-10-21 05:54:18 NDT; 4 days ago
  Process: 774 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid (code=exited, status=0/SUCCESS)
  Process: 708 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
 Main PID: 791 (mysqld)
    Tasks: 27 (limit: 2328)
   CGroup: /system.slice/mysql.service
           └─791 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid

は、MySQL データベースが 4 日以上稼働していることを示します。

MySQL で稼働時間ステータスを確認してください

mysql> show global status like 'uptime';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Uptime        | 428334 |
+---------------+--------+
1 row in set (0.32 sec)

この値は秒単位です。次の日数に換算すると 4 日を超えます。

mysql> select 428334/60/60/24;
+-----------------+
| 428334/60/60/24 |
+-----------------+
|  4.957569444444 |
+-----------------+
1 row in set (0.01 sec)

稼働時間ステータスをクエリする別の方法は、mysqladmin バージョンを使用するか、「\s」を使用して mysql クライアントでクエリを実行することです。

ps を使用してプロセスの起動時間を確認します

ps コマンドを使用してクエリを実行すると、mysqld が 4 日、23 時間、3 分 54 秒間開始されていることがわかります

scutech@scutech:~$ ps -eo pid,user,args,etime|grep mysqld
  791 mysql    /usr/sbin/mysqld --daemoniz  4-23:03:54

MySQL ログを確認します

スタートアップ情報を見つけるには、キーワード「接続準備完了」を探してください。

2020-10-21T08:24:18.986765Z 0 [メモ] /usr/sbin/mysqld: 接続の準備ができました。
バージョン: '5.7.28-log' ソケット: '/ var/run/mysqld/mysqld.sock' ポート: 3306 MySQL Community Server (GPL)

MySQL データベース クラッシュの一般的な理由

MySQL データベース クラッシュの最も一般的な理由は 2 つあります。 1 つは mysql のバグで、もう 1 つは mysql のシステム リソース適用の失敗またはメモリ リークです。

MySQL のバグ

MySQL データベースがクラッシュする最も一般的な理由の 1 つは、もちろん MySQL のバグです。バグの 95% は特定の SQL に関連しています。通常、MySQL がクラッシュする前に実行された最後の SQL に問題があります。したがって、バグを見つけるときは、一般的なクエリ ログを開いて、最後の SQL に基づいて手がかりを探す必要があります。
クラッシュの原因を特定したら、通常は詳細検索を使用して MySQL バグ ライブラリ (https://bugs.mysql.com) をチェックし、同様の問題がないかどうかを確認する必要があります。自分に関係がある可能性のあるバグを見つけた場合は、それが修正されたことを確認してください。修正されている場合は、MySQL をバグが修正されたバージョンにアップグレードします。

各バージョンのリリース ノートには「修正されたバグ」セクションがあり、修正されたバグを確認できます。

MySQL がシステム リソースの適用に失敗するか、メモリ リークが発生します。

メモリが不足していたり​​、MySQL がシステム リソースの適用に失敗したりすると、ディスク領域がいっぱいになったり、ディスクが壊れているなど。現時点では、クラッシュの根本原因を特定する方法がいくつかあります:

• MySQL エラー ログを注意深く読んでください。このログ内のプログラム デバッグ情報の一部は混乱を招くように見えるかもしれませんが、注意深く見ると、多くの場合、手がかりが見つかります;

• 一般クエリ ログを開き、SQL によってアクセスされた最後のテーブルまたはインデックスを見つけ、テーブルまたはインデックスを確認し、問題がある場合は再構築します。これにより通常は問題が解決します。

• strace、pstack、pmap、および gdb を使用して mysqld コードを分析します。コア ダンプを開く必要がある場合があります。

• CMake を使用します。オプション -DWITH_DEBUG= 1 mysqld を再コンパイルし、再コンパイルされた mysqld を実行して、トラブルシューティングのためにトレース ファイルとエラー ログを確認します。

MySQL メモリ使用量の計算

グローバル メモリ
innodb_buffer_pool_size innodb_log_buffer_size thread_cache_size table_open_cache table_defining_cache key_buffer_size
スレッド メモリ
binlog_cache_size thread_stack
シングル オペレーション メモリ
join_buffer_size read_buffer_size read_rnd_buffer_size tmp_table_size sort_buffer_size

計算式
MySQL 8 の最大メモリ使用量基準値の計算式:

SELECT ( @@innodb_buffer_pool_size + @@innodb_log_buffer_size + @@key_buffer_size 
+ @@max_connections * (@@binlog_cache_size + @@thread_stack + @@read_buffer_size 
+ @@read_rnd_buffer_size + @@sort_buffer_size + @@join_buffer_size + @@tmp_table_size ) 
) / 1024 /1024 AS MAX_MEM_MB;

innodb_buffer_pool_size

• # # key_buffer_size

• max_connections*(sort_buffer_size read_buffer_size binlog_cache_size)

• max_connections*2MB

一時的な解決策 あなた次のコマンドを使用してキャッシュを解放できます:

echo 1 > /proc/sys/vm/drop_caches

0: 0 はシステムのデフォルト値です。これは、メモリがデフォルトでは解放されず、オペレーティング システムによって自動的に管理されることを意味します

1: 解放ページ キャッシュ
2: dentries と inode を解放する
3: すべてのキャッシュを解放する
長期的には、問題を解決するには対応するパラメーターを変更する必要があります。

MySQL クライアントのメモリ リーク

MySQL クライアントのメモリ リークでは、通常、次のプロンプトが表示されます

mysql: 行 42、'malloc.c' でメモリ不足です
mysql: 必要な 8136 バイト (8k)、使用中のメモリ: 12481367 バイト (12189k)
エラー 2008: MySQL クライアントが実行されましたメモリ不足です。

これは通常、クライアントが受け取った返された結果セットが大きすぎることが原因です。解決策は 2 つあります:

実行中の SQL を確認して、本当に実行しているかどうかを確認してください。それほど大きな返される結果セットが必要ですか?
mysql を許可するときに --quick オプションを追加します。これにより、クライアントが一度に受け取る戻りセットが減りますが、mysqld の負荷が増加します。

以上がMySQL データベースのクラッシュの一般的な原因と解決策は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。