La connexion à distance au serveur MySQL prend très longtemps


10

J'ai un serveur MySQL 5.0.75 en cours d'exécution sur mon ordinateur portable Linux auquel je veux me connecter à partir d'une autre machine du réseau local.

Cette connexion prend 5-6 secondes:

mysql -h 172.22.65.101 -u myuser -p123

Un ping vers l'hôte MySQL:

PING 172.22.65.101 (172.22.65.101) 56(84) bytes of data.
64 bytes from 172.22.65.101: icmp_seq=1 ttl=64 time=0.799 ms
64 bytes from 172.22.65.101: icmp_seq=2 ttl=64 time=0.000 ms
64 bytes from 172.22.65.101: icmp_seq=3 ttl=64 time=6.43 ms
64 bytes from 172.22.65.101: icmp_seq=4 ttl=64 time=0.000 ms
64 bytes from 172.22.65.101: icmp_seq=5 ttl=64 time=3.81 ms
64 bytes from 172.22.65.101: icmp_seq=6 ttl=64 time=0.706 ms
^C
--- 172.22.65.101 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5027ms
rtt min/avg/max/mdev = 0.000/1.959/6.437/2.383 ms

Des idées? Lorsque je surveille la connexion avec SHOW PROCESSLIST; sur l'hôte MySQL, je peux voir que la commande est "connect" et que l'utilisateur est "utilisateur non authentifié". Cela dure jusqu'à ce que la connexion soit établie. (L'utilisateur est alors affiché comme "myuser" et la commande est "sleep")

Je suis développeur et j'ai besoin de vos suggestions pour trouver le goulot d'étranglement!

Mon my.cnf sur l'hôte:

[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice  = 0

[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 128K
thread_cache_size = 8
myisam-recover = BACKUP
query_cache_limit = 1M
query_cache_size = 16M
expire_logs_days = 10
max_binlog_size = 100M
skip-federated

[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[isamchk]
key_buffer = 16M

Client:

mysql  Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using readline 5.2

Serveur:

mysql  Ver 14.12 Distrib 5.0.75, for debian-linux-gnu (i486) using readline 5.2

Réponses:


17

Vous êtes probablement en retard sur une tentative de récupération et de vérification du DNS inverse de l'hôte qui se connecte. Vous pouvez tester cela en activant skip_name_resolvedans la [mysqld]section my.cnf du serveur .

Si c'est effectivement le cas (démontré par ce paramètre éliminant le retard), vous pouvez résoudre le problème en configurant DNS correctement (en avant et en arrière) pour le client, ou en exécutant skip_name_resolvetout le temps (ce qui signifie que vous pouvez n'utilisez pas de noms d'hôtes dans vos GRANTtables).


Cela l'a corrigé! J'ai défini skip_name_resolve dans le my.cnf de mon hôte MySQL, redémarré MySQL et le problème a été résolu. Je te dois de la bière. :)
Lennart

Ravi d'être utile. :)
chaos

1
super merci! juste pour être clair cependant (au cas où quelqu'un gâcherait comme moi), c'est simplement "skip_name_resolve" sur une seule ligne, pas "skip_name_resolve = 1" ou quoi que ce soit ... sinon votre service ne démarrera pas!
James Crowley
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.