MySQLステータス変数Aborted_connectsおよびAborted_clientsについて



Mysql Status Variables Aborted_connects



上記をクリックしてください ' プログラマーの大きなコーヒー '、'トップパブリック番号 'を選択します

決定的な瞬間、初めて提供されます! 640?




MySQLステータス変数Aborted_clientsおよびAborted_connectsの重要性は、これらの状態変数を引き起こす条件または要因が変化することを表していますか?実験的テストに従って検証することにより、まず、状態変数が説明するものを見てみましょう。




中止された接続




Aborted Connectは、MySQLサーバーへの接続に失敗した回数を表します。状態変数を一緒に分析して、バインディングhost_cacheテーブルとエラーログを発行できます。これにより、次のように状態変数が急増します。


  1. ただし、クライアントにはMySQLデータベースへのアクセスを試行する権限がありません。

  2. 入力したクライアントパスワードが正しくありません。

  3. 接続パケットに正しい情報が含まれていません。

  4. 接続時間制限を超えると、システムは主に制御変数connect_timeout(mysqlのデフォルトは基本的に10秒です。ただし、ネットワーク環境が極端に悪い場合を除き、通常はタイムアウトになりません)。


公式の説明は次のとおりです。


クライアントが接続すらできない場合、サーバーはAborted_connectsステータス変数をインクリメントします。接続試行の失敗は、次の理由で発生する可能性があります。


  1. クライアントはデータベースにアクセスしようとしますが、データベースに対する特権がありません。

  2. クライアントが間違ったパスワードを使用しています。

  3. 接続パケットに正しい情報が含まれていません。

  4. 接続パケットを取得するには、connect_timeout秒以上かかります。 5.1.7項「サーバーシステム変数」を参照してください。


中止されたクライアント:


中断されたクライアントは、一時停止中にクライアントが接続を適切に閉じないため、接続の数を示します。公式の説明は次のとおりです。


クライアントが接続を適切に閉じずに停止したために中止された接続の数。セクションB.5.2.10「通信エラーと接続の中止」を参照してください。


中止されたクライアントが増加した時間は、クライアントが接続を正常に確立したが、何らかの理由で切断または終了したことを意味します。これは通常、不安定なネットワーク環境で発生します。主な可能性は次のとおりです。


  1. mysql_close()を終了する前にクライアントプログラムが呼び出されず、MySQL接続が適切に閉じられました。

  2. クライアントのスリープ時間がシステム変数とwait_timeoutinteractive_timeoutの値を超えているため、接続が終了しますMySQLプロセス

  3. クライアントプログラムがデータ転送プロセスを突然終了します


公式文書B.5.2.10通信エラーと接続の中止について以下に説明します。


クライアントが正常に接続したが、後で不適切に切断したり終了したりした場合、サーバーはAborted_clientsステータス変数をインクリメントし、Aborted接続メッセージをエラーログに記録します。原因は次のいずれかです。


  • クライアントプログラムは、終了する前にmysql_close()を呼び出しませんでした。

  • クライアントは、サーバーに要求を発行せずに、wait_timeoutまたはinteractive_timeout秒を超えてスリープしていました。 5.1.7項「サーバーシステム変数」を参照してください。

  • クライアントプログラムは、データ転送の途中で突然終了しました。


中止された接続または中止されたクライアントに関する問題のその他の理由:


  • max_allowed_pa​​cket変数値が小さすぎるか、クエリがmysqldに割り当てたよりも多くのメモリを必要とします。セクションB.5.2.9「パケットが大きすぎる」を参照してください。

  • Linuxでのイーサネットプロトコルの使用、半二重と全二重の両方。一部のLinuxイーサネットドライバにはこのバグがあります。クライアントマシンとサーバーマシン間でFTPを使用して巨大なファイルを転送することにより、このバグをテストする必要があります。転送がburst-pause-burst-pauseモードになる場合は、Linuxデュプレックスシンドロームが発生しています。ネットワークカードとハブ/スイッチの両方のデュプレックスモードを全二重または半二重に切り替え、結果をテストして最適な設定を決定します。

  • 読み取り時に割り込みを引き起こすスレッドライブラリの問題。

  • 正しく構成されていないTCP / IP。

  • 障害のあるイーサネット、ハブ、スイッチ、ケーブルなど。これは、ハードウェアを交換することによってのみ適切に診断できます。


上で紹介したように、状態変数の値の変化を引き起こす多くの要因があります。次に、それについて1つずつ分析して提示します。まず、状態変数の増加につながる可能性のある要因をテストする必要がありますAborted Connect


1ですが、クライアントにはMySQLデータベースへのアクセスを試行する権限がありません。


実際、ここで話すことには許可がありません。個人的な理解は次のとおりです。クライアントはアカウントを使用してデータベースにアクセスすることを許可されていません。比喩的に言えば、アカウントkkkを使用してMySQLデータベースにアクセスしようとします。実際、このデータベースユーザーの存在がわからない場合、そのユーザーは実際には存在しません。


実験比較テストの前に、最初の状態変数がクリアされます。


mysql>フラッシュステータス

クエリOK、影響を受ける行は0(0.01秒)

mysql> 'Abort%'のようなステータスを表示します

+ ------------------ + ------- +

| Variable_name |値|

+ ------------------ + ------- +

| Aborted_clients | 0 |

| Aborted_connects | 0 |

+ ------------------ + ------- +

セットで2行(0.01秒)

mysql>

mysql> mysql.userからhost、userを選択します

+ ------------------------------- + ----------- +

|ホスト|ユーザー|

+ ------------------------------- + ----------- +

| %| mydba |

| %|ルート|

| %|テスト|

| 127.0.0.1 |ルート|

| 192,168。%| mydbadmin |

| 192.168.103.18,192.168.103,22 | LimitIP |

| :: 1 |ルート|

| db-server.localdomain |ルート|

|ローカルホスト|バックユーザー|

|ローカルホスト|ルート|

+ ------------------------------- + ----------- +


マシンの別のSecureCRTウィンドウで、アカウントが存在しないkkkアクセスMySQLを使用した後、状態変数Aborted_connects to1が見つかります。


[root @ xxxxx〜] #mysql -u kkk -p

パスワードを入力する:

エラー1045(28000):ユーザー 'kkk' @ 'localhost'のアクセスが拒否されました(パスワードを使用:YES)


640?wx_fmt = png


このアカウントがそれ自体に存在する可能性もありますが、特定のIPアドレスのみが実際の環境にアクセスすることを許可している可能性があります。可能性は非常に。 IPアクセス制限のケースをテストする必要があります


mysql> MyDB。*のすべてを「123456」で識別されるroot @ xxxxx「10.20。%」に付与します

クエリOK、影響を受ける行は0(0.01秒)

mysql>フラッシュ権限

クエリOK、影響を受ける行は0(0.00秒)

mysql> 'Abort%'のようなステータスを表示します

+ ------------------ + ------- +

| Variable_name |値|

+ ------------------ + ------- +

| Aborted_clients | 0 |

| Aborted_connects | 0 |

+ ------------------ + ------- +

セットで2行(0.00秒)


上に示したように、行番号mydbadminを作成し、IPアクセス10.20のみを許可してから、IP192.168段落からMySQLデータベースにアクセスします。


#mysql -h 10.20.57.24 -u mydbadmin -p

パスワードを入力する:

エラー1045(28000):ユーザー 'mydbadmin' @ '192.168.7.208'のアクセスが拒否されました(パスワードを使用:YES)


このとき、状態は変数Aborted_connectsの1つになります。


640?wx_fmt = png


2、入力されたクライアントパスワードが正しくないか、単に各パスワードを試してください。 (クライアントが間違ったパスワードを使用しています)


以下に示すように、テストアカウントを使用してMySQLデータにアクセスしましたが、間違ったパスワードを入力しました


[root @ xxxxx〜] #mysql -u test -p

パスワードを入力する:

エラー1045(28000):ユーザー 'test' @ 'localhost'のアクセスが拒否されました(パスワードを使用:YES)

[root @ xxxxx〜]#


ステータス変数Aborted_connectsをチェックすると、状態変数Aborted_connectsが2になります。


mysql> 'Abort%'のようなステータスを表示します

+ ------------------ + ------- +

| Variable_name |値|

+ ------------------ + ------- +

| Aborted_clients | 0 |

| Aborted_connects | 2 |

+ ------------------ + ------- +

セットで2行(0.00秒)


3:接続パケットに正しい情報が含まれていません。


パッケージのpspingには正しい情報(正しい情報)が含まれていないため、この比較的簡単に構築できるテストポートはMySQLポートの(pingポート)になります。テスト前は、最初の状態変数は空です。


mysql>フラッシュステータス

クエリOK、影響を受ける行は0(0.00秒)

mysql> 'abort%'のようなステータスを表示

+ ------------------ + ------- +

| Variable_name |値|

+ ------------------ + ------- +

| Aborted_clients | 0 |

| Aborted_connects | 0 |

+ ------------------ + ------- +

セットで2行(0.00秒)


クライアントのMySQLサービスが存在するホストでのポート接続の検証(psping)


640?wx_fmt = png


上に示したように、pspingテストの後、Aborted_connectsは5に接続し、pspingテストを続行すると、状態変数は増加し続けます。


640?wx_fmt = png


さらに、制限max_connect_error、MySQLへの1つのクライアントの継続的なアクセスを超える場合、これが状態変数Aborted_connectsの変更につながるかどうか、答えは実験的なテストではありません。利害関係者は、非常に奇妙なことに、接続の数がいっぱいになるとAborted_connects状態変数が増加するという多くのオンライン記事があります。実際、これによって状態変数Aborted_connectsが変更されることはありません。


4、接続時間制限を超えて、このパラメーターは主にconnect_timeoutコントロールです(基本的に、極端に貧弱なネットワーク環境でない限り、mysqlのデフォルトは10秒です。通常はタイムアウトではありません)。


まず、MySQLデータベースサーバーで次のコマンドを実行します。複雑な環境でLinuxエミュレーションで構築されたネットワーク送信遅延の場合にtcコマンドを使用してnetemし、11秒遅延します。


#tc qdisc add dev eth0 root netem delay 11000ms


さらに、以下に示すように、MySQLサーバーがこのMySLQサーバーにpingを実行すると、11秒のネットワーク遅延が発生します。


#ping 10.20.57.24

PING 10.20.57.24(10.20.57.24)56(84)バイトのデータ。

10.20.57.24から64バイト:icmp_seq = 1 ttl = 61 time = 11001 ms

10.20.57.24から64バイト:icmp_seq = 2 ttl = 61 time = 11001 ms

10.20.57.24から64バイト:icmp_seq = 3 ttl = 61 time = 11001 ms

10.20.57.24から64バイト:icmp_seq = 4 ttl = 61 time = 11001 ms

10.20.57.24から64バイト:icmp_seq = 5 ttl = 61 time = 11001 ms


この時点で、MySQLデータベースアクセスは11秒のネットワーク遅延のため、10秒を超えるシステム変数connect_timeoutは次のエラーを表示し、状態変数Aborted_connectsの値を変更します。


#mysql -h 10.20.57.24 -u test -p

パスワードを入力する:

エラー2013(HY000):「認証パケットの読み取り」でMySQLサーバーへの接続が失われました。システムエラー:0


では、状態変数を区別する方法Aborted Connectがその原因ですか?単一の状態変数からは本質的に区別できませんが、performance_schema.host_cacheの決定、スクリーニングのバインドにはほとんど何もできません。


  • COUNT_NAMEINFO_PERMANENT_ERRORSホスト名DNS解決中の永続的なエラーの数へのIP。

  • COUNT_AUTHENTICATION_ERRORSは、障害によって引き起こされたエラーの数を確認します

  • SUM_CONNECT_ERRORS:接続の数が間違っていると見なされます '閉じられました'(max_connect_errorsシステム変数に従って評価されます)。ハンドシェイクプロトコルエラーのみがカウントされ、カウントは検証されるだけです(HOST_VALIDATED = YES)ホスト


1ですが、クライアントにはMySQLデータベースへのアクセスを試行する権限がありません。


COUNT_AUTHENTICATION_ERRORSを1ずつ発生させるたびに、初めて1COUNT_NAMEINFO_PERMANENT_ERRORSも増加します。


2、入力されたクライアントパスワードが正しくありません


COUNT_AUTHENTICATION_ERRORSを1ずつ発生させるたびに、初めて1COUNT_NAMEINFO_PERMANENT_ERRORSも増加します。


実際、どちらも判別できない1と2については、最も単純で効果的なシステム変数log_warningsを2に設定してから、エラーログ情報を分析して表示します。


mysql> set global log_warnings = 2

クエリOK、影響を受ける行は0(0.00秒)

mysql>


次に、この時点で1と2がエラーログに内部に記録され、エラーログ、分析するAborted Connectをバインドするステータス変数、以下に示すテストケースを分析できます。


2018-06-20 22:44:16 18026 [警告] IPアドレス「192.168.xxx.xxx」を解決できませんでした:名前またはサービスが不明です

2018-06-20 22:44:16 18026 [警告]ユーザー 'kkkk' @ '192.168.xxx.xxx'のアクセスが拒否されました(パスワードを使用:YES)

2018-06-20 22:45:18 18026 [警告]ユーザー 'test' @ '192.168.xxx.xxx'のアクセスが拒否されました(パスワードを使用:YES)


3、接続パケットに正しい情報が含まれていません


すべての原因COUNT_HANDSHAKE_ERRORSが1


SUM_CONNECT_ERRORS1によって引き起こされるたび


PsPing v2.10-PsPing-ping、遅延、帯域幅測定ユーティリティ

Copyright(C)2012-2016マーク・ルシノビッチ

Sysinternals-www.sysinternals.com

10.20.57.24:3306へのTCP接続:


5回の反復(ウォームアップ1)pingテスト:

10.20.57.24:3306(ウォームアップ)への接続:192.168.103.34:55327から:1.93ms

10.20.57.24:3306への接続:192.168.103.34:55328から:10.08ms

10.20.57.24:3306への接続:192.168.103.34:55329から:3.35ms

10.20.57.24:3306への接続:192.168.103.34:55330から:3.71ms

10.20.57.24:3306への接続:192.168.103.34:55331から:2.32ms


10.20.57.24:3306のTCP接続統計:

送信= 4、受信= 4、紛失= 0(0%の損失)、

最小= 2.32ミリ秒、最大= 10.08ミリ秒、平均= 4.87ミリ秒


640?wx_fmt = png


4、接続時間制限を超えました


タイムアウトが原因の場合は、次の条件が表示されます。


  • すべての原因SUM_CONNECT_ERRORSが1

  • COUNT_HANDSHAKE_ERRORS1によって引き起こされるたび

  • 最初の増加により、COUNT_NAMEINFO_PERMANENT_ERRORS1が発生します


注:3と4はエラーログに書き込まれません。3と4の違いは、COUNT_NAMEINFO_PERMANENT_ERRORSの値で区別できます。


640?wx_fmt = png


状態変数AbortedClientsの変数をテストするために実験してみましょう。


1、mysql_closeを終了する前のクライアントプログラムは呼び出されず()MySQL接続を適切に閉じました。


実験の前に、フラッシュステータスを使用して状態変数をクリーンアップします


mysql>フラッシュステータス

クエリOK、影響を受ける行は0(0.00秒)

mysql> 'Abort%'のようなステータスを表示します

+ ------------------ + ------- +

| Variable_name |値|

+ ------------------ + ------- +

| Aborted_clients | 0 |

| Aborted_connects | 0 |

+ ------------------ + ------- +

セットで2行(0.00秒)

mysql>


以下に示すように、簡単なPythonテストスクリプトpython_mysql.pyを記述して、ローカルデータベース接続を閉じます。dbcon.closeコメント、


mysql.connectorをインポートします

試してください:

dbcon = mysql.connector.connect(

host = '127.0.0.1'、

user = 'root'、

passwd = 'xxxxxxx'、

database = 'information_schema'

)。

カーソル= dbcon.cursor()

sql_tex = 'MyDB.testからcount(*)を選択'

cursor.execute(sql_tex)

dtlist = cursor.fetchall()

dtlistを印刷する

eとしてのmysql.connector.Errorを除く:

print( 'SQLの操作に失敗しました!{0}'。format(e))

最後に:

cursor.close

#dbcon.close


次に、スクリプトの実行を確認し、変数Aborted_clientsのステータスを確認してから、状態変数Aborted_clientsの値が1増加することを確認します。


640?wx_fmt = png


2、クライアントは値のシステム変数wait_timeoutおよびinteractive_timeoutよりも長くスリープし、接続が終了するMySQLプロセスをリードします


mysql> 'interactive_timeout'のようなグローバル変数を表示します

+ --------------------- + ------- +

| Variable_name |値|

+ --------------------- + ------- +

| Interactive_timeout | 28800 |

+ --------------------- + ------- +

セットの1行(0.00秒)

mysql> 'wait_timeout'のようなグローバル変数を表示します

+ --------------- + ------- +

| Variable_name |値|

+ --------------- + ------- +

| wait_timeout | 28800 |

+ --------------- + ------- +

セットの1行(0.00秒)

mysql>


グローバルシステム変数interactive_timeoutを4秒に設定し、wait_timeout


mysql> set global Interactive_timeout = 4

クエリOK、影響を受ける行は0(0.00秒)

mysql> set global wait_timeout = 4

クエリOK、影響を受ける行は0(0.00秒)

mysql> 'Abort%'のようなステータスを表示します

+ ------------------ + ------- +

| Variable_name |値|

+ ------------------ + ------- +

| Aborted_clients | 0 |

| Aborted_connects | 0 |

+ ------------------ + ------- +

セットで2行(0.00秒)


次に、クライアントはMySQLデータベースに接続し、何もしません。4秒以上経過すると、操作エラーが発生します。「エラー2013(HY000):クエリ中にMySQLサーバーへの接続が失われました」


#mysql -h 10.20.57.24 -u test -p

パスワードを入力する:

MySQLモニターへようこそ。コマンドはまたはgで終わります。

MySQL接続IDは43です

サーバーバージョン:5.6.20-enterprise-commercial-advanced-log MySQL Enterprise Server-Advanced Edition(商用)

Copyright(c)2000、2018、Oracleおよび/またはその関連会社。全著作権所有。

Oracleは、OracleCorporationおよび/またはその登録商標です。

アフィリエイト。その他の名称は、それぞれの商標である可能性があります

所有者。

ヘルプを表示するには、「help」または「h」と入力します。 'c'と入力して、現在の入力ステートメントをクリアします。

mysql> select current_user()

エラー2013(HY000):クエリ中にMySQLサーバーへの接続が失われました

mysql>


MySQLサーバーでは、状態変数Aborted_clientsが1になっています。


mysql> 'Abort%'のようなステータスを表示します

+ ------------------ + ------- +

| Variable_name |値|

+ ------------------ + ------- +

| Aborted_clients | 1 |

| Aborted_connects | 0 |

+ ------------------ + ------- +

セットの2行(0.00秒


便利な構成のため、他の理由(クライアントの中止またはクエリがmax_allowed_pa​​cket値を超える)があります。このスキップ。さらに、tcpdumpで追跡するパケットキャプチャツールを分析できるという事実。以下は例です(ここに


簡単なtcpdump、分析するためのフォローアップ記事を実行します)


MySQLサーバーでtcpdumpパケットキャプチャを使用する


[root @ xxxxx〜] #tcpdump -ieth0ポート3306-s 1500 -w tcpdump.log


次に、アカウントを使用している別のMySQLサーバーが存在しないか、MySQLデータベースにアクセスするためのパスワードが間違っています


# mysql -h 10.20.57.24 -u kkk -p

パスワードを入力する:

エラー1045(28000):ユーザー 'kkk' @ '192.168.7.208'のアクセスが拒否されました(パスワードを使用:YES)

#mysql -h 10.20.57.24 -u test -p

パスワードを入力する:

エラー1045(28000):ユーザー 'test' @ '192.168.7.208'のアクセスが拒否されました(パスワードを使用:YES)

[root @ xxxxx〜]#


コマンドを実行した後、CTRL + Cを使用してパケットキャプチャ分析を終了し、分析を表示できます。以下のスクリーンショットに示すように:


[root @ xxxxx〜] #tcpdump -ieth0ポート3306-s 1500 -w tcpdump.log

tcpdump:eth0でリッスン、リンクタイプEN10MB(イーサネット)、キャプチャサイズ1500バイト

キャプチャされた28パケット

フィルタによって受信された28パケット

カーネルによってドロップされた0パケット

[root @ xxxxx〜] #strings tcpdump.log


参照:


  • https://dev.mysql.com/doc/refman/8.0/en/communication-errors.html

  • http://www.olivierdoucet.info/blog/2012/05/08/customer-case-finding-cause-of-max_user_connections/


640.jpeg

  • 出典:Xiaoxiang隠者

  • https://www.jianshu.com/p/4a5a0a92e7d5

  • プログラマーの大規模なコーヒー仕上げのリリース、再版は許可された著者に連絡してください

640?wx_fmt = gif 640?[クリックして神の大きな源になる]