次のエラーが表示されます
ERROR 2013 (HY000): Lost connection to MySQL server at
'reading authorization packet', system error: 0
mySQLサーバーに接続しようとしたとき。
私がやっていること:
しかし、F5が設定されたIPを使用してMySQLサーバーに接続しようとすると、
ERROR 2013 (HY000): Lost connection to MySQL server at
'reading authorization packet', system error: 0
何か案は?
進捗状況の更新:[〜#〜] zero [〜#〜]
-同じエラーが表示されます。/var/log/secureにエントリがありません。負荷分散サーバーを作成したIPから誰かが認証しようとする場合と同じです。
mysqlエラーログにエントリはありません。
コマンド-何も返しません
mysql> SHOW GLOBAL STATUS LIKE 'Aborted_connections';
Empty set (0.00 sec)
私はすでにmy.cnf
ファイルを変更し、追加しました
[mysqld]
skip-name-resolve
connect_timeout
を10に変更しました。
だから、F5で作成したサーバーに対して応答がないようです。
ようやくF5管理者にF5サーバーのログを渡すように説得しました。
出力は次のとおりです:
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_ACCEPTED>: BIG-IP MySQL Proxy -- clientside initial connection
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_ACCEPTED>: BIG-IP MySQL Proxy -- clientside responding with server WELCOME packet
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_DATA>: BIG-IP MySQL Proxy -- clientside authenticated flag not set
Jan 28 15:46:39 tmm err tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_DATA>: BIG-IP MySQL Proxy -- mysql client: attempting to do something before authentication
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <LB_SELECTED>: BIG-IP MySQL Proxy -- serverside selected pool /Common/foss-mysql-slave_pool node SLAVE-IP
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_CLOSED>: BIG-IP MySQL Proxy -- clientside connection closed from MASTER-IP(XXXXXXX)
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <SERVER_CLOSED>: BIG-IP MySQL Proxy -- serverside connection closed from node SLAVE-IP(XXXXXXXX)
セキュリティのためにIPを交換しました!
ちょうど追加-そして、私はここに問題があると思う-mysqlのバージョンは5.1.69-log Thx All
これは通常、接続の中断が原因です。これを確認するには、ステータスを確認します。
mysql> SHOW GLOBAL STATUS LIKE 'Aborted_connects';
接続が失われたときにこのカウンタが増加し続ける場合は、接続中に問題が発生している兆候です。
多くの場合に機能すると思われる解決策の1つは、タイムアウトを増やすことです。推奨値は10秒です。
mysql> SET GLOBAL connect_timeout = 10;
接続タイムアウトのもう1つの一般的な原因は、クライアントの認証時に必要な逆DNSルックアップです。 my.cnfのconfig変数を使用してMySQLを実行することをお勧めします。
[mysqld]
skip-name-resolve
つまり、GRANTステートメントはホスト名ではなくIPアドレスに基づいている必要があります。
また、f5.comサイトで2012年のこのレポートを見つけました(現在はログインによって保護されていますが、私はそれを入手しました Googleキャッシュ経由 )
私がテストしたバージョンであるBIG-IP 11.1およびMySQL 5.1を実行していない限り、プロキシは動作しない可能性があります。 MySQLプロトコルには変更の習慣があります。
F5 Support に連絡し、サポートされているバージョンの組み合わせを使用していることを確認することをお勧めします。
私はこのエラーに苦労しました。インターネットで見つけたすべての回答を試しました。
最終的に、コンピューターを携帯電話のホットスポットに接続し、すべてが機能しました。会社のインターネットがMySQLとの接続をブロックしていることがわかりました。
これは完全な解決策ではありませんが、誰かが同じ問題に直面している可能性があります。接続を確認する価値があります。
私の場合、サーバーはこのIPからの接続を受け入れなかった。サーバーはGoogle Apps EngineのSQLサーバーであり、サーバーに接続できる許可されたリモートホストを構成する必要があります。
(新しい)ホストをGAE管理ページに追加すると、問題が解決しました。
Mysqlを数回停止することでこれを解決しました。
$ mysql.server stop
Shutting down MySQL
.. ERROR! The server quit without updating PID file (/usr/local/var/mysql/xxx.local.pid).
$ mysql.server stop
Shutting down MySQL
.. SUCCESS!
$ mysql.server stop
ERROR! MySQL server PID file could not be found! (note: this is good)
$ mysql.server start
ここからすべて良い。 mysqlが複数回起動されたと思われます。
Localhostで複数のmysql接続(異なるデータベースセットに接続)を使用します。
これは、コンピューターをシャットダウンし、mysqlが適切にシャットダウンされなかった後に起こりました。マシンを起動した後、1つを除く複数のdb接続に正常に接続することができました(マシンをシャットダウンする前にこれを多く使用しました)。この投稿の手順に従って、connect_timeoutを2倍にしましたが、その1つのデータベース接続に接続できませんでした。
マシンを再起動しましたが、すぐに接続できます。これにより、自分でブロックを解除できますが、マシンを再起動せずに修正できると便利です。
もう1つの懸念は、connection_timeoutは関連する問題を遅らせるように思えたが、方程式にネットワークがない場合、localhostですぐにエラーが発生することでした。
もう1つの可能性は、TCPラッパー(/etc/hosts.denyおよび/etc/hosts.allow)からの接続リセットです。telnetからポート3306への着信を確認するだけです。何もありません、それから何かが中間にあり、コミュニケーションが起こらないようにします。
私はMacを持っていますが、この部分ではすべてのLinuxが同じであると仮定します...
私の場合、私はこれを得ました:
2018-12-03 11:13:27 - Start server:
2018-12-03 11:13:27 - Server start done.
2018-12-03 11:13:27 - Checking server status...
2018-12-03 11:13:27 - Trying to connect to MySQL...
2018-12-03 11:13:27 - Lost connection to MySQL server at 'reading authorization packet', system error: 0 (2013)
2018-12-03 11:13:27 - Assuming server is not running
私はこれを実行しました:
Sudo killall mysqld
そして、mysqlworkbenchからmysqlを再び開始しましたが、あなたの場合は次のようになります:
mysql.server start
*補足:mysql.server stop
を実行してみましたが、このShutting down MySQL .... SUCCESS!
を取得しましたが、ps aux | grep mysql
を実行した後、実際にシャットダウンしていないことがわかりました...
私の場合、MySQLサーバーへの接続が多く(15,000接続)、空きメモリが約120Mだったときに発生しました。サーバーにメモリを追加すると、エラーはなくなりました。