MySQL アーティファクトの完全なプロセスリストの表示

今日テストデータを同期しているときにネットワークが突然切断され、再接続したところテーブルを開けないことが分かりました。

テーブルのデータ長は112192kbであることがわかりますが、残念ながら開くことができません。

開けない場合は、削除する準備をして、もう一度試してください。

物事はそれほど単純ではないことがよくあります。案の定、削除できず、切り詰めることもできませんでした。その後、navicat がスタックしたため、データベースにログインして dorp 操作を実行しましたが、それでも削除されませんでした。仕事。

ネットワーク エラーにより、奇妙な現象が発生した可能性があります。

それでは、何が起こったのかを見てみましょう。

アーティファクトが表示されます。

show full processlist;

show full processlist 結果はリアルタイムで変更を返し、mysql リンク実行のライブ スナップショットであるため、処理に非常に役立ちます。緊急事態、それは機能します。

この SQL は通常、突然の問題を解決する消防士の役割を果たします。

mysql の現在の実行状態、圧力の有無、実行中の SQL、ステートメントにかかる時間、実行速度の遅い SQL の有無などをチェックできます。

実行に時間がかかる SQL を見つけた場合は、より注意を払う必要があり、必要に応じてそれを強制終了し、まず問題を解決してください。

コマンドには 3 つの実行方法があります:

1. これは、コマンド ラインで直接クエリを実行します。最後の \G は、クエリ結果が列に出力されることを意味します。各フィールドは別々の行に印刷できます。

mysql> show full processlist;
+--------+------+----------------------+-------+---------+------+----------+-----------------------+
| Id     | User | Host                 | db    | Command | Time | State    | Info                  |
+--------+------+----------------------+-------+---------+------+----------+-----------------------+
| 449000 | root | 127.123.213.11:59828 | stark | Sleep   | 1270 |          | NULL                  |
| 449001 | root | 127.123.213.11:59900 | stark | Sleep   | 1241 |          | NULL                  |
| 449002 | root | 127.123.213.11:59958 | stark | Sleep   | 1216 |          | NULL                  |
| 449003 | root | 127.123.213.11:60088 | stark | Sleep   | 1159 |          | NULL                  |
| 449004 | root | 127.123.213.11:60108 | stark | Sleep   | 1151 |          | NULL                  |
| 449005 | root | 127.123.213.11:60280 | stark | Sleep   | 1076 |          | NULL                  |
| 449006 | root | 127.123.213.11:60286 | stark | Sleep   | 1074 |          | NULL                  |
| 449007 | root | 127.123.213.11:60344 | stark | Sleep   | 1052 |          | NULL                  |
| 449008 | root | 127.123.213.11:60450 | stark | Sleep   | 1005 |          | NULL                  |
| 449009 | root | 127.123.213.11:60498 | stark | Sleep   |  986 |          | NULL                  |
| 449013 | root | localhost            | NULL  | Query   |    0 | starting | show full processlist |
+--------+------+----------------------+-------+---------+------+----------+-----------------------+
11 rows in set (0.01 sec)
mysql> show full processlist\G;
*************************** 1. row ***************************
     Id: 449000
   User: root
   Host: 127.123.213.11:59828
     db: stark
Command: Sleep
   Time: 1283
  State: 
   Info: NULL
*************************** 2. row ***************************
     Id: 449001
   User: root
   Host: 127.123.213.11:59900
     db: stark
Command: Sleep
   Time: 1254
  State: 
   Info: NULL

2.リンク スレッドに関連するテーブルをクエリしてスナップショットを表示します

SELECT id、db、USER、HOST、command、time、state、info FROM information_schema.PROCESSLIST WHERE command ! = ' Sleep' ORDER BY time DESC;

3. navicat の [ツール] => [サーバー監視] から表示します。

この方法はより便利で、並べ替えも可能です。

各列の意味の簡単な説明:

Id: リンク mysql サーバー スレッドの一意の識別子このスレッドのリンクは、kill によって終了できます。

ユーザー: データベースに接続している現在のスレッドのユーザー

ホスト: このステートメントが発行された IP とポートを表示します。問題のあるステートメントを発行したユーザーを追跡するために使用できます。

db: スレッドに接続されているデータベース、存在しない場合は null

Command: 現在の接続で実行されたコマンドを表示します。通常、スリープまたはアイドル (スリープ)、クエリ (クエリ)、接続 (接続)

Time: スレッドが現在の状態にある時間、単位は秒です。

State: ステータスを表示します。現在の接続を使用した SQL ステートメントの非常に重要な列です。後ですべての状態について説明します。状態は、ステートメント実行における特定の状態にすぎないことに注意してください。たとえば、SQL ステートメントはクエリされています。必要な場合があります。 tmp テーブルへのコピー、結果のソート、データの送信、その他の状態を経ます Completion

Info: スレッドによって実行された SQL ステートメント、またはステートメントが実行されていない場合は null。このステートメントは、クライアントによって送信された実行ステートメントまたは内部実行ステートメントのいずれかになります。

問題を発見した後、どのように解決しますか?

1. 上記の問題のある行を個別に強制終了できます

kill 449000

2. 3 分以上かかるスレッドをバッチ終了することもできます

- - 実行時間が 3 分を超えたスレッドをクエリし、それらを kill ステートメントに結合します

select concat('kill ', id, ';')

from information_schema.processlist

where command != 'Sleep'

and time > 3*60

order by time desc;

もちろん、問題は通常解決できます。この時点では、この show processlist プロセス中に、前の切り捨て操作とドロップ操作のみが表示され、これら 2 つのスレッドが強制終了されましたが、役に立ちませんでした。 。 。 。

もちろん上記はナンセンスではなく、これは【中国人機長】のように、航空事故に遭遇したら、まずマニュアルに従って確認し、原因を究明し、問題を解決するという方法論に近いものです。問題。

Continue

その直後、navicat を使用してテーブル修復操作を実行しました。結果は「テーブル メタデータ ロックを待機しています」となりました。

MySQL が次のような DDL 操作を実行していたとき、 alter table 、テーブルにコミットされていないトランザクションがある場合、テーブルのメタデータ ロックの待機が発生します。メタデータ ロックが発生すると、テーブルに対する後続の操作はブロックされます。

解決策:

1. information_schema.innodb_trx テーブルから現在コミットされていないトランザクションを表示します

information_schema.innodb_trx\G## から trx_state、trx_started、trx_mysql_thread_id、trx_query を選択します

#フィールドの意味:

trx_state: トランザクションのステータス、通常は RUNNING

trx_started: トランザクションの実行の開始時刻、時間が長い場合は、トランザクションが妥当かどうかを分析します

trx_mysql_thread_id: MySQL スレッド ID、kill に使用されます

trx_query: トランザクション内の SQL

一般に、これらのスレッドが強制終了される限り、DDL 操作はテーブル メタデータ ロックを待機しません。

2. ロック タイムアウトのしきい値を調整する

lock_wait_timeout は、メタデータ ロックを取得するためのタイムアウト (秒) を表し、許容値の範囲は 1 ～ 31536000 (1 年) です。デフォルト値は 31536000 です。

https://dev.mysql.com/doc/refman/5.6/en/se...

を参照してください。デフォルト値は 1 年です。 。 。 。

これを 30 分に調整します。

set session lock_wait_timeout = 1800;

set global lock_wait_timeout = 1800;

この問題が発生したときにすぐに失敗するようにします。が発生します (フェイルファスト)。

推奨チュートリアル: 「MySQL チュートリアル」「Navicat」

以上がMySQL アーティファクトの完全なプロセスリストの表示の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。