|
最近、いくつかの特別な要因によりMySQLサーバーに遭遇しました“エラー1129(00000):ホスト「xxx」は多くの接続エラーのためブロックされています。 「mysqladmin flush-hosts」でブロック解除する”問題が解決された後、パラメータmax_connect_errorsについて学ぶ過程で、異なるネットワークデータの矛盾した記述が少し混乱しました(このエラーについては、本質的な理由は同じIPが短時間で最大max_connect_errorsの割り込みデータベース接続を多数発生させたことであり、以下は問題を探り、問題を分析し、疑問を解消する過程です)。 まずインターネットで情報を検索したところ、多くの情報がパスワード入力の試行回数がmax_connect_errors変数を超えるとMySQLがこのクライアントのログインをブロックすると主張していました。そして、以下の通りmax_connect_errorsの導入に関する公式情報を見つけました。MySQL 5.6/5.7は同じです これ以上の連続接続要求がホストから中断され、成功した接続がなければ、サーバーはそのホストからのさらなる接続をブロックします。 ホストキャッシュをフラッシュすることでブロックされたホストのブロックを解除できます。 そのためには、FLUSH HOSTS文を発行するか、mysqladmin flush-hostsコマンドを実行します。 前の接続が中断されてからmax_connect_errors回未満の試行で接続が成功裏に確立された場合、ホストのエラー数はゼロにクリアされます。 しかし、一度ホストがブロックされると、ホストキャッシュをフラッシュするしかブロックを解除できません。 デフォルトは100です。 上記の通り、変換はおおよそ次の通りです:MySQLサーバーが同じホストから連続してリクエストを受け、これらのリクエストすべてが接続を確立せずに中断された場合、これらの連続リクエストの累積値がmax_connect_errorsセット値より大きい場合、MySQLサーバーはこのホストからの以降のすべてのリクエストをブロックします。 最初にこの情報を見ると、あなたも攻撃されると思います“ホストからの多くの連続した接続要求が中断され、成功した接続がありません”混乱しているのは、ネットワークの異常によりデータベース接続が中断されたためです。 インターネットでそのような情報を探しました: この変数に関して混乱があるようです。 繰り返し無効なパスワードをブロックするのではなく、ネットワークエラーによる接続中断に対してホストをブロックします。 そうすれば自分たちで実験して検証し、どちらが正しいかを見つけられます。 MySQLデータベースにテストアカウントを作成し、max_connect_errors変数を3. 次に、別のテストマシンを使って間違ったパスワードでMySQLデータベースに接続します。以下の通りです。前の3つの誤ったパスワードを入力しても、4番目の入力では上記のエラーが発生しません。そうすれば、この変数が誤ったパスワード入力に関係している可能性を排除できます。 [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p パスワードを入力してください: エラー1045(28000):ユーザー「test'@mytestlnx02」へのアクセス拒否(パスワード:YES使用) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p パスワードを入力してください: エラー1045(28000):ユーザー「test'@mytestlnx02」へのアクセス拒否(パスワード:YES使用) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p パスワードを入力してください: エラー1045(28000):ユーザー「test'@mytestlnx02」へのアクセス拒否(パスワード:YES使用) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p パスワードを入力してください: エラー1045(28000):ユーザー「test'@mytestlnx02」へのアクセス拒否(パスワード:YES使用) [root@mytestlnx02 TMP]# 実際、IPが誤ったパスワードを入力した場合、MySQLはperformance_schemaデータベースのhost_cacheテーブルに記録します。 累積してCOUNT_AUTHENTICATION_ERRORSフィールドに記録されています。
公式情報によると、host_cache場は統計的に次のように見なされています。“詰まり”接続誤差(max_connect_errorsシステム変数に基づいて評価)。 プロトコルのハンドシェイクエラーのみがカウントされ、認証済みホストにのみ使用されます(HOST_VALIDATED = YES)。 SUM_CONNECT_ERRORS 「ブロッキング」とみなされる接続エラーの数(以下を比較して評価した場合)max_connect_errorsシステム変数)。 カウントされるのはプロトコルのハンドシェイクエラーのみで、検証に合格したホストのみ(HOST_VALIDATED = YES)のみです。 MySQLクライアントはデータベースとの接続を確立するために3回のハンドシェイクプロトコルを開始する必要があります。通常はこの時間は非常に短いですが、ネットワーク異常やタイムアウトなどの要因が発生するとハンドシェイクプロトコルが完了しなくなります。MySQLにはパラメータconnect_timeoutがあり、これはMySQLサーバープロセスが接続確立を待つ時間で数秒かかります。 connect_timeout時間枠を過ぎてもプロトコルのハンドシェイクが完了しない場合、MySQLクライアントは以下のような例外メッセージを含む例外メッセージを受け取ります。 「XXX」でMySQLサーバーへの接続が途絶え、システムエラー: エールノ、この変数はデフォルトで10秒となります:
ネットワークのタイムアウトによってデータベース接続が中断された場合を構築します。Linuxのnetemコマンドとtcコマンドを使って複雑な環境でのネットワーク伝送遅延をシミュレートします。テストサーバーからMySQLサーバーへのアクセス時に以下の設定を行った後、11秒の遅延が生じます。 [root@gettestlnx02 ~]# 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=62 time=0.251ms 10.20.57.24からの64バイト:icmp_seq=2 ttl=62 time=0.330ms 10.20.57.24からの64バイト:icmp_seq=3 ttl=62 time=0.362ms 10.20.57.24からの64バイト:icmp_seq=4 ttl=62 time=0.316ms 10.20.57.24からの64バイト:icmp_seq=5 ttl=62 time=0.281ms 10.20.57.24からの64バイト:icmp_seq=6 ttl=62 time=0.377ms ^C --- 10.20.57.24 ピング統計--- 6パケット送信、6パケット受信、パケットロス0%、時間5716ms RTT min/avg/max/mdev = 0.251/0.319/0.377/0.047 ms [root@gettestlnx02 ~]# TC QDc Add Dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# 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=62 time=11000ms 10.20.57.24からの64バイト:icmp_seq=2 ttl=62 time=11000ms 10.20.57.24からの64バイト:icmp_seq=3 ttl=62 time=11000ms 10.20.57.24からの64バイト:icmp_seq=4 ttl=62 time=11000ms 10.20.57.24からの64バイト:icmp_seq=5 ttl=62 time=11000ms 10.20.57.24からの64バイト:icmp_seq=6 ttl=62 time=11000ms 10.20.57.24からの64バイト:icmp_seq=7 ttl=62 time=11000ms
以下のようにテストサーバーgettestlnx02上のMySQLデータベースに接続しています(ただし、SSH経由で接続している場合、gettestlnx02での動作はかなり遅くなります)。 もちろん、MySQLサーバー上でネットワークレイテンシをシミュレートすることも可能ですし、connect_timeoutレイテンシとネットワークレイテンシの両方を低くすることも可能です) [root@gettestlnx02 ~]# mySQL -h10.20.57.24 -utest -p パスワードを入力してください: エラー 2013(HY000):「認証パケットを読み取る」時にMySQLサーバーへの接続が失われ、システムエラー:0 [root@gettestlnx02 ~]# 上記の通り、ネットワーク遅延が10秒以上続いたため、MySQLへの接続が失敗しました。この時点で、MySQLサーバーのhost_cacheテーブルを照会すると、SUM_CONNECT_ERRORSが1になり、COUNT_HANDSHAKE_ERRORSも変更されているのがわかります1.
そしてこのように3回繰り返し投げると、SUM_CONNECT_ERRORSが3になり、COUNT_HANDSHAKE_ERRORSが3になります. 次にnetemとtcコマンドを使ってテストサーバーのネットワークレイテンシシミュレーションをキャンセルし、MySQLデータベースへのテスト接続に移行します。以下のテストに示されています。 [root@gettestlnx02 ~]# TC QDc del Dev ETH0 root netem delay 11000ms [root@gettestlnx02 ~]# mySQL -h10.20.57.24 -utest -p パスワードを入力してください: エラー1129(HY000):ホスト「192.168.27.180」は多くの接続エラーのためブロックされています。 「mysqladmin flush-hosts」でブロック解除してください [root@gettestlnx02 ~]#
現在、建設可能です“エラー1129(HY000):ホスト「192.168.27.180」は多くの接続エラーのためブロックされています。 「mysqladmin flush-hosts」でブロック解除してください”違う。 解決 解決済み ERROR 1129 (00000):ホスト「xxx」が多くの接続エラーのためブロックされています。 「Mysqladmin flush-hosts」でブロック解除するエラーを出す方法はたくさんありますが、一時的なものもあります。 一時的な計画としては、指標が根本原因に対処しないことです。 重要なのはネットワークエラーを修正することです(多くの場合、ネットワーク管理者やシステム管理者の相談が必要です) 回避策: 1変数の値をmax_connection_errors の値を大きく設定します
この一時的な解決策はIPを禁止するための遅延トリガー条件に過ぎず、複雑な場合や高い同時実行では大きな値を設定する必要があります。そうでなければ簡単に再発してしまいます。 さらに、変数は現在の環境にのみ影響し、再起動すると失効します。 2: 使用フラッシュホスト mySQL>ホストのフラッシュ; クエリOK、影響を受けた行数は0行(0.00秒) mySQL> performance_schema.host_cache から*を選択してください; 空集合(0.00秒) mySQL> もちろん、mysqladmin flush-hostsコマンドを使ってホストのキャッシュ情報を整理することもできます [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host パスワードを入力してください: では、ホストキャッシュとは何でしょうか? 公式なイントロダクションは以下の通りです: MySQLサーバーは、クライアントに関する情報(IPアドレス、ホスト名、エラー情報)を含むホストキャッシュをメモリ内に管理しています。 サーバーはこのキャッシュを非ローカルのTCP接続に使用します。 ループバックインターフェースアドレス(127.0.0.1または::1)を用いて確立されたTCP接続や、Unixソケットファイル、名前付きパイプ、または共有接続で確立された接続にはキャッシュを使用しません 記憶。 簡単に言えば、MySQLサーバーはクライアント情報(IPアドレス、ホスト名、エラーメッセージなど)を含むキャッシュをメモリ内に保持します。 サーバーは非ローカルのTCP接続情報をキャッシュします。 ループバックインターフェースアドレス(127.0.0.1または::1)を用いて作成されたTCP接続や、Unixソケットファイル、名前付きパイプライン、共有メモリを用いた接続はキャッシュされません。 ホストキャッシュ情報はperformance_schemaデータベースのhost_cacheテーブルを通じて照会できます。 3: 変数 host_cache_size を に設定します。0 実際、MySQLサーバーがホストキャッシュ情報をログに記録しないようにするというのは、最も信頼性の低い解決策だと言えます。 この方法は完全に無視できます。
| 
掲載地 2019/04/08 11:01:48
|
|
|
|
