web-dev-qa-db-fra.com

MySQL: erreur de lecture des paquets de communication

Je reçois cet avertissement dans mysql,

[Warning] Aborted connection 21 to db: 'MyDB' user: 'MyUser' Host: 'localhost' (Got an error reading communication packets)

J'ai parcouru quelques sujets sur Google et, selon certaines suggestions, j'ai augmenté le max_allowed_packet de 128 to 512 to 1024 toujours le même comportement.

J'utilise Drupal 7, et oui il y a beaucoup de types de données blob, mais 1024 Mb de max_allowed_packet devrait suffire à mon avis.

Une autre solution de contournement pour surmonter cet avertissement?

ÉDITER:

Ajout de certains paramètres comme suggestions/réponse de @ Rolando, je reçois toujours le même avertissement.

Ma configuration mysql ressemble à ceci:

[client]
port        = 3306
socket      = /tmp/mysql.sock
default-character-set = utf8

[mysqld]
port        = 3306
socket      = /tmp/mysql.sock
skip-external-locking
key_buffer_size = 16K 
max_allowed_packet = 1024M 
table_open_cache = 128 
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 192K
# Query cache disabled
thread_cache_size = 8
myisam-recover = BACKUP
max_connections = 100
thread_concurrency = 10
tmp_table_size = 128M
max_heap_table_size = 128M
log_error                = /var/log/mysql/mysql-error.log
log_slow_queries        = /var/log/mysql/mysql-slow.log
long_query_time = 2

log_warnings = 2

server-id   = 1
binlog-format = row
replicate-same-server-id = 0
auto-increment-increment = 2
auto-increment-offset = 1
log_bin = mysql-bin
log-slave-updates
relay-log=mysqld-relay-bin
expire_logs_days        = 10
max_binlog_size         = 100M

innodb_data_home_dir = /var/db/mysql
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /var/db/mysql
innodb_buffer_pool_size = 8G
character-set-server = utf8
#innodb_additional_mem_pool_size = 2M
innodb_log_file_size = 2047M
innodb_log_buffer_size = 32M
innodb_flush_log_at_trx_commit = 2
innodb_thread_concurrency = 8
innodb_lock_wait_timeout = 50
innodb_flush_method = O_DIRECT

[mysqldump]
quick
quote-names
max_allowed_packet = 16M
default-character-set = utf8

[mysql]
default-character-set = utf8

[myisamchk]
key_buffer_size = 32M
sort_buffer_size = 32M

[mysqlhotcopy]
interactive-timeout

[mysqld_save]
syslog

Mon application utilise uniquement InnoDB, mais il existe peu de bases de données comme mysql, fournies avec les installations mysql standard, seules celles qui utilisent le type de moteur MyISAM, je suppose que cela ne devrait pas être mon souci cependant.

Comme vous pouvez le voir, j'ai également une réplication, l'avertissement est le même sur le serveur répliqué également, dont la configuration est identique à celle-ci.

mysqlinnodb
14
user18530

Je suis heureux que vous ayez dit que toutes vos données sont InnoDB, je peux donc répondre comme suit: Si max_allowed_packet est au maximum à 1G et vous avez toujours des problèmes, il n'y a vraiment que deux endroits à regarder:

  1. innodb_log_buffer_size : la taille en octets du tampon qu'InnoDB utilise pour écrire dans les fichiers journaux sur le disque. La valeur par défaut est 8 Mo. Un tampon de journal volumineux permet d'exécuter de grandes transactions sans qu'il soit nécessaire d'écrire le journal sur le disque avant la validation des transactions. Ainsi, si vous avez de grosses transactions, l'agrandissement du tampon de journal permet d'économiser les E/S disque.
  2. innodb_log_file_size : la taille en octets de chaque fichier journal d'un groupe de journaux. La taille combinée des fichiers journaux doit être inférieure à 4 Go. La valeur par défaut est 5 Mo. Les valeurs sensibles vont de 1 Mo à 1/N-ème de la taille du pool de mémoire tampon, où N est le nombre de fichiers journaux dans le groupe. Plus la valeur est élevée, moins l'activité de vidage du point de contrôle est nécessaire dans le pool de mémoire tampon, ce qui permet d'économiser les E/S de disque. Mais des fichiers journaux plus volumineux signifient également que la récupération est plus lente en cas de panne.

J'ai abordé quelque chose comme il y a environ 2 ans

SUGGESTIONS

Vous devez augmenter les journaux de transactions InnoDB . Voici les étapes pour augmenter en toute sécurité innodb_log_buffer_size et innodb_log_file_size :

Étape 01: ajoutez-les à /etc/my.cnf

[mysqld]
innodb_log_buffer_size = 32M
innodb_log_file_size = 2047M

Étape 02: exécutez cela dans mysql

mysql> SET GLOBAL innodb_fast_shutdown = 0;

Étape 03: Arrêtez mysql

service mysql stop

Étape 04: Écarter les anciens journaux

mv ib_logfile0 ib_logfile0.bak
mv ib_logfile1 ib_logfile1.bak

Étape 05: démarrez mysql

service mysql start

C'est ça.

L'infrastructure InnoDB devrait maintenant avoir suffisamment d'espace de journalisation pour les BLOB de différentes tailles.

Essaie !!!

10
RolandoMySQLDBA

Après avoir lu le commentaire de @ user19292 en janvier '16 sur cette ancienne question, j'ai mis à jour de 5.7.9 à 5.7.12 et le problème a disparu.

1
IsraelWebDev

Je viens de passer environ 5-6 heures à changer les options et à essayer différentes versions de MySQL, j'ai toujours eu l'erreur.

Je pense que c'est de l'eider parce que:

  • mon PHP ne ferme pas correctement la connexion db (c'est un avertissement, pas une erreur), mysql_close() ou équivalent.
  • ou parce que le serveur cache/proxy nginx est configuré pour fermer la connexion si le client la ferme, le serveur cache/proxy n'attend pas le serveur Origin (où se trouve également mysql).
0
adrianTNT