MySQL server has gone away - exactement 60 secondes
J'ai récemment découvert qu'une requête sql qui a été en cours d'exécution fine précédemment est maintenant à expiration au bout de 60 secondes et de lancer une erreur. La requête est lent, mais qui se déroule dans le cadre d'un travail de nuit donc c'est pas un problème en soi (donc merci de ne pas me suggère d'optimiser).
Je suis en mesure de reproduire l'erreur de manière constante par l'exécution de "sélectionner" SLEEP(120);" à partir de PHP comme indiqué ci-dessous. Toutefois, l'exécution de la même déclaration à partir d'un client MySQL est réussi (retourne 0). J'ai tenté d'ajuster wait_timeout (mis à 28800), mais n'ont eu aucune chance. J'ai aussi redémarré à la fois le serveur de base de données et la machine elle-même.
Le fait qu'il a toujours fois à exactement 60 secondes me donne à penser qu'il est susceptible d'être un choix et pas une des ressources limitées question.
Je suis en cours d'exécution:
Windows Server 2003
MySql 5.1.36-communauté
PHP 5.3
Ci-dessous sont mon code de test, la sortie et les résultats de SHOW VARIABLES
Merci!
CODE:
set_error_handler("sqlErrorHandler");
set_time_limit(12000);
$link = mysql_connect("$MYSQL_Host","$MYSQL_User","$MYSQL_Pass");
mysql_select_db($MYSQL_db, $link);
echo "mysql_ping = " . (mysql_ping($link) ? "LIVE" : "DEAD") . "<br /><br />";
$sql = "SELECT SLEEP(120);";
$start = microtime(true);
mysql_query($sql, $link);
echo "**query done**<br />";
allDone();
function allDone(){
global $start, $sql;
$end = microtime(true);
echo "sql : $sql<br />";
echo "elapsed : " . ($end - $start) . "<br />";
echo "<br />";
}
function sqlErrorHandler($errno, $errstr, $errfile, $errline){
global $link;
echo "Error : $errno<br />$errstr<br />";
echo "mysql_ping : " . (mysql_ping($link) ? "LIVE" : "DEAD") . "<br />";
echo "<br />";
allDone();
}
De SORTIE :
mysql_ping = LIVE
Error : 2
mysql_query() [function.mysql-query]: MySQL server has gone away
mysql_ping : DEAD
sql : SELECT SLEEP(120);
elapsed : 60.051116943359
Error : 2
mysql_query() [function.mysql-query]: Error reading result set's header
mysql_ping : DEAD
sql : SELECT SLEEP(120);
elapsed : 60.0511469841
**query done**
sql : SELECT SLEEP(120);
elapsed : 60.051155090332
MONTRER VARIABLES:
Variable_name=Value
auto_increment_increment=1
auto_increment_offset=1
autocommit=ON
automatic_sp_privileges=ON
back_log=50
basedir=C:\\Program Files\\MySQL\\MySQL Server 5.1\\
big_tables=OFF
binlog_cache_size=32768
binlog_format=STATEMENT
bulk_insert_buffer_size=8388608
character_set_client=utf8
character_set_connection=utf8
character_set_database=latin1
character_set_filesystem=binary
character_set_results=utf8
character_set_server=latin1
character_set_system=utf8
character_sets_dir=C:\\Program Files\\MySQL\\MySQL Server 5.1\\share\\charsets\\
collation_connection=utf8_general_ci
collation_database=latin1_swedish_ci
collation_server=latin1_swedish_ci
completion_type=0
concurrent_insert=1
connect_timeout=10
datadir=C:\\Documents and Settings\\All Users\\Application Data\\MySQL\\MySQL Server 5.1\\Data\\
date_format=%Y-%m-%d
datetime_format=%Y-%m-%d %H:%i:%s
default_week_format=0
delay_key_write=ON
delayed_insert_limit=100
delayed_insert_timeout=300
delayed_queue_size=1000
div_precision_increment=4
engine_condition_pushdown=ON
error_count=0
event_scheduler=OFF
expire_logs_days=0
flush=OFF
flush_time=1800
foreign_key_checks=ON
ft_boolean_syntax=+ -><()~*:""&|
ft_max_word_len=84
ft_min_word_len=4
ft_query_expansion_limit=20
ft_stopword_file=(built-in)
general_log=OFF
general_log_file=C:\\Documents and Settings\\All Users\\Application Data\\MySQL\\MySQL Server 5.1\\Data\\p1.log
group_concat_max_len=1024
have_community_features=YES
have_compress=YES
have_crypt=NO
have_csv=YES
have_dynamic_loading=YES
have_geometry=YES
have_innodb=YES
have_ndbcluster=NO
have_openssl=DISABLED
have_partitioning=YES
have_query_cache=YES
have_rtree_keys=YES
have_ssl=DISABLED
have_symlink=YES
identity=0
ignore_builtin_innodb=OFF
init_connect=
init_file=
init_slave=
innodb_adaptive_hash_index=ON
innodb_additional_mem_pool_size=2097152
innodb_autoextend_increment=8
innodb_autoinc_lock_mode=1
innodb_buffer_pool_size=96468992
innodb_checksums=ON
innodb_commit_concurrency=0
innodb_concurrency_tickets=500
innodb_data_file_path=ibdata1:10M:autoextend
innodb_data_home_dir=D:\\MySQL Datafiles\\
innodb_doublewrite=ON
innodb_fast_shutdown=1
innodb_file_io_threads=4
innodb_file_per_table=OFF
innodb_flush_log_at_trx_commit=1
innodb_flush_method=
innodb_force_recovery=0
innodb_lock_wait_timeout=50
innodb_locks_unsafe_for_binlog=OFF
innodb_log_buffer_size=1048576
innodb_log_file_size=19922944
innodb_log_files_in_group=2
innodb_log_group_home_dir=.\\
innodb_max_dirty_pages_pct=90
innodb_max_purge_lag=0
innodb_mirrored_log_groups=1
innodb_open_files=300
innodb_rollback_on_timeout=OFF
innodb_stats_on_metadata=ON
innodb_support_xa=ON
innodb_sync_spin_loops=20
innodb_table_locks=ON
innodb_thread_concurrency=8
innodb_thread_sleep_delay=10000
innodb_use_legacy_cardinality_algorithm=ON
insert_id=0
interactive_timeout=28800
join_buffer_size=131072
keep_files_on_create=OFF
key_buffer_size=50331648
key_cache_age_threshold=300
key_cache_block_size=1024
key_cache_division_limit=100
language=C:\\Program Files\\MySQL\\MySQL Server 5.1\\share\\english\\
large_files_support=ON
large_page_size=0
large_pages=OFF
last_insert_id=0
lc_time_names=en_US
license=GPL
local_infile=ON
log=OFF
log_bin=OFF
log_bin_trust_function_creators=OFF
log_bin_trust_routine_creators=OFF
log_error=C:\\Documents and Settings\\All Users\\Application Data\\MySQL\\MySQL Server 5.1\\Data\\p1.err
log_output=FILE
log_queries_not_using_indexes=OFF
log_slave_updates=OFF
log_slow_queries=OFF
log_warnings=1
long_query_time=10.000000
low_priority_updates=OFF
lower_case_file_system=ON
lower_case_table_names=1
max_allowed_packet=1048576
max_binlog_cache_size=4294963200
max_binlog_size=1073741824
max_connect_errors=10
max_connections=800
max_delayed_threads=20
max_error_count=64
max_heap_table_size=16777216
max_insert_delayed_threads=20
max_join_size=18446744073709551615
max_length_for_sort_data=1024
max_prepared_stmt_count=16382
max_relay_log_size=0
max_seeks_for_key=4294967295
max_sort_length=1024
max_sp_recursion_depth=0
max_tmp_tables=32
max_user_connections=0
max_write_lock_count=4294967295
min_examined_row_limit=0
multi_range_count=256
myisam_data_pointer_size=6
myisam_max_sort_file_size=107374182400
myisam_recover_options=OFF
myisam_repair_threads=1
myisam_sort_buffer_size=12582912
myisam_stats_method=nulls_unequal
myisam_use_mmap=OFF
named_pipe=OFF
net_buffer_length=16384
net_read_timeout=30
net_retry_count=10
net_write_timeout=80
new=OFF
old=OFF
old_alter_table=OFF
old_passwords=OFF
open_files_limit=2048
optimizer_prune_level=1
optimizer_search_depth=62
optimizer_switch=index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on
pid_file=C:\\Documents and Settings\\All Users\\Application Data\\MySQL\\MySQL Server 5.1\\Data\\p1.pid
plugin_dir=C:\\Program Files\\MySQL\\MySQL Server 5.1\\lib/plugin
port=3306
preload_buffer_size=32768
profiling=OFF
profiling_history_size=15
protocol_version=10
pseudo_thread_id=3230
query_alloc_block_size=8192
query_cache_limit=1048576
query_cache_min_res_unit=4096
query_cache_size=33554432
query_cache_type=ON
query_cache_wlock_invalidate=OFF
query_prealloc_size=8192
rand_seed1=
rand_seed2=
range_alloc_block_size=4096
read_buffer_size=65536
read_only=OFF
read_rnd_buffer_size=262144
relay_log=
relay_log_index=
relay_log_info_file=relay-log.info
relay_log_purge=ON
relay_log_space_limit=0
report_host=
report_password=
report_port=3306
report_user=
rpl_recovery_rank=0
secure_auth=OFF
secure_file_priv=
server_id=0
shared_memory=OFF
shared_memory_base_name=MYSQL
skip_external_locking=ON
skip_networking=OFF
skip_show_database=OFF
slave_compressed_protocol=OFF
slave_exec_mode=STRICT
slave_load_tmpdir=C:\\WINDOWS\\TEMP
slave_net_timeout=3600
slave_skip_errors=OFF
slave_transaction_retries=10
slow_launch_time=2
slow_query_log=OFF
slow_query_log_file=C:\\Documents and Settings\\All Users\\Application Data\\MySQL\\MySQL Server 5.1\\Data\\p1-slow.log
sort_buffer_size=262144
sql_auto_is_null=ON
sql_big_selects=ON
sql_big_tables=OFF
sql_buffer_result=OFF
sql_log_bin=ON
sql_log_off=OFF
sql_log_update=ON
sql_low_priority_updates=OFF
sql_max_join_size=18446744073709551615
sql_mode=
sql_notes=ON
sql_quote_show_create=ON
sql_safe_updates=OFF
sql_select_limit=18446744073709551615
sql_slave_skip_counter=
sql_warnings=OFF
ssl_ca=
ssl_capath=
ssl_cert=
ssl_cipher=
ssl_key=
storage_engine=InnoDB
sync_binlog=0
sync_frm=ON
system_time_zone=Eastern Daylight Time
table_definition_cache=256
table_lock_wait_timeout=50
table_open_cache=619
table_type=InnoDB
thread_cache_size=38
thread_handling=one-thread-per-connection
thread_stack=196608
time_format=%H:%i:%s
time_zone=SYSTEM
timed_mutexes=OFF
timestamp=1256827484
tmp_table_size=16777216
tmpdir=C:\\WINDOWS\\TEMP
transaction_alloc_block_size=8192
transaction_prealloc_size=4096
tx_isolation=REPEATABLE-READ
unique_checks=ON
updatable_views_with_limit=YES
version=5.1.36-community
version_comment=MySQL Community Server (GPL)
version_compile_machine=ia32
version_compile_os=Win32
wait_timeout=28800
warning_count=0
- Qu'advient-il si vous exécutez le SPECTACLE des VARIABLES de requête via un script php. Ne le délai d'attente de la modification des valeurs?
- J'ai couru AFFICHER les VARIABLES de PHP et les paramètres de délai d'expiration sont les mêmes
- Ne rien afficher dans la base de données mysql journal lorsque cela se produit?
- nope, pas d'entrées dans le journal des erreurs pour aujourd'hui. Autres fichiers journaux ne semblent pas exister
- +1 pour
gone in 60 seconds
- Ouvert à cette question, juste pour voir si quelqu'un a fait la référence. +1
Vous devez vous connecter pour publier un commentaire.
Le php option
mysql.connect_timeout
est la raison pour cela. Ce n'est pas seulement utilisé pour le délai de connexion, mais en l'attente de la première réponse du serveur. Vous pouvez l'augmenter comme ceci:default_socket_timeout
est le chemin à parcourir, même si la connexion TCP/IP et pas prise de fichier de base.Quand je suis tombé sur ce problème, il n'était pas causé par la wait_timeout (qui est la valeur par défaut de 8 heures), mais par max_allowed_packet avec une grande instruction INSERT. Changement de max_allowed_packet à partir de PHP n'a eu aucun effet, mais quand je l'ai changé dans la section mysqld de /etc/my.cnf et redémarré le serveur MySQL, le problème a disparu.
Il y a tout un tas de choses qui peuvent être en cause. J'avais lu à travers ces et d'essayer chacun d'eux
http://dev.mysql.com/doc/refman/5.1/en/gone-away.html
J'ai travaillé pour plusieurs sociétés d'hébergement web au fil des années et généralement quand je vois cela, c'est la wait_timeout sur le serveur de fin bien que cela ne semble pas être le cas ici.
Si vous trouvez la solution, j'espère que vous le poster. J'aimerais bien le savoir.
C'est quelque chose que je fais, (mais le plus souvent avec la classe MySQLi).
SET time_zone='+00:00'
) lors de la reconnexion, si nécessaire.L'augmentation de SQL d'Attente Délai d'attente a travaillé pour moi dans ce cas, essayez ceci:
avant première "normal" des requêtes SQL.
Mon cas était une corruption de base de données après une mise à niveau mineure dans mysql fondamentalement 5.0.x 5.1.x
avec la DB en myisam.
Les mêmes lignes de la requête:
MySQL server has gone away
Erreur de lecture du résultat de l'ensemble de l'en-tête
Après la réparation de la & optimisation avec mysqlcheck, il est revenu à la normale, sans la nécessité de modifier le délai d'attente du socket.
J'ai résolu ce problème avec
J'ai remarqué quelque chose de peut-être pertinente.
J'ai eu deux scripts en cours d'exécution, à la fois de faire plutôt requêtes lentes. L'un d'eux verrouillé une table et l'autre en attente. Celle qui attendait a default_socket_timeout = 300. Finalement, il cesser avec "MySQL server has gone away". Cependant, la base de la liste de processus a continué à montrer de la requête, le lent encore en cours d'exécution et les autres verrouillé et l'attente.
Donc je ne pense pas que mysqld est le coupable. Quelque chose a changé dans le php mysql client. Très probablement la default_socket_timeout que je vais maintenant définie sur -1 pour voir si cela change quoi que ce soit.
J'ai le même problème avec mysqli.
Ma solution est http://php.net/manual/ru/mysqli.configuration.php
J'ai eu ce problème récemment. Je suis tombé sur une option:
default_authentication_plugin
Pour une raison quelconque, il l'avait mise à
caching_sha2_password
, mais la mise à jour de la valeur demysql_native_password
fixe pour moi. Je ne suis pas sûr de ce que les différences sont, alors attention!Espère que cela aide quelqu'un!
J'ai eu du mal sur une restauration de base de données à l'aide de mysqldumper (programme php). J'ai été en mesure de le faire fonctionner en changeant la "mssql.délai d'attente" dans le php.ini. Il a été défini par défaut à 60, et j'ai changé de 300.
Dans notre cas, le coupable était le mondiale (pas de "local") MySQL variable "wait_timeout".
De comparer les résultats des requêtes suivantes:
à
Dans notre cas, la première requête a montré une wait_timeout de 28800, mais la 2ème requête a montré une valeur de 10 (secondes).
Nous avons vérifié que la modification de la variable globale a résolu le problème. Voici un simple script PHP qui reproduit notre condition:
Dès que le temps de sommeil a dépassé le mondial wait_timeout valeur, on obtient l'erreur: "Warning: mysqli_query(): MySQL server has gone away".
Pour modifier la valeur, nous avons dû modifier le paramètre dans notre Amazon RDS tableau de bord.
Par mes expériences quand il arrive sur la lumière, des requêtes, il est un moyen de résoudre le problème. Il semble que lorsque vous démarrez ou redémarrez
mysql
aprèsapache
ce problème commence à apparaître et à la source du problème est confus ouvrir des sockets dans lephp
processus.Pour le résoudre:
Premier redémarrage de mysql service
Puis redémarrez apache service
Il arrive si la connexion a été ouverte pour très peu de temps, mais aucune action n'a été fait dans le serveur MySQL. Dans ce cas, le délai d'attente se produit avec le message d'erreur "MySQL server has gone away". Les réponses ci-dessus peuvent travailler et ne peuvent pas travailler. Même accepté la réponse n'a pas de travail pour moi. Alors, j'ai essayé un truc et il a bien fonctionné pour moi. Logiquement, pour éviter cette erreur, nous devons garder la connexion MySQL en cours d'exécution ou en court, la garder vivante. Supposons que nous essayons de en Vrac insérer 250k enregistrements. En général, il faut du temps pour créer analyser des données à partir de quelque part et faire en Vrac requête, puis l'insérer. Dans ce scénario, la plupart d'entre nous utilisent une boucle pour créer de la chaîne SQL. Donc, nous allons compter le nombre d'itération et de faire un mannequin à la base de données après une certaine itération. Il va garder la connexion.
Veuillez consulter ce lien http://bugs.php.net/bug.php?id=45150
semble comme ils ont déménagé à natif MYSQL en PHP5.3 et il a quelques difficultés à travailler avec l'IPV6.
Essayez d'utiliser "127.0.0.1" au lieu de "localhost"