（2006）MySQL服务器不见了

本文介绍了（2006）MySQL服务器不见了的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我已经阅读了很多线程以及有关此问题的MySQL文档，但似乎没有任何建议起作用。

I've read so many threads as well as the MySQL documentation about this issue and nothing suggested seems to work.

这是myf

[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 lc-messages-dir = /usr/share/mysql skip-external-locking default-storage-engine=INNODB character-set-server=utf8 collation-server=utf8_bin interactive_timeout = 2880000 wait_timeout = 2880000 net_write_timeout = 6000 net_read_timeout = 6000 delayed_insert_timeout = 6000 key_buffer = 256M key-buffer-size = 32M max_allowed_packet = 600M thread_stack = 256K thread_cache_size = 8 max-connections = 500 thread-cache-size = 50 open-files-limit = 65535 table-definition-cache = 4096 table-open-cache = 10240 query-cache-type = 0 query_cache_limit = 2M query_cache_size = 32M myisam-recover = BACKUP innodb_buffer_pool_size = 384M innodb_additional_mem_pool_size = 20M innodb_log_file_size = 10M innodb_log_buffer_size = 64M innodb_flush_log_at_trx_commit = 1 innodb_lock_wait_timeout = 180 log_error = /var/log/mysql/error.log expire_logs_days = 10 max_binlog_size = 100M [mysqldump] quick quote-names max_allowed_packet = 64M [isamchk] key_buffer = 32M

此外，我在MySQL CLI中运行查询确保我的设置保持不变，并且看起来像这样：

In addition I ran queries in the MySQL CLI to make sure my settings were sticking, and they appear to be:

mysql> select @@global.wait_timeout, @@session.wait_timeout; +-----------------------+------------------------+ | @@global.wait_timeout | @@session.wait_timeout | +-----------------------+------------------------+ | 2880000 | 2880000 | +-----------------------+------------------------+

mysql> select @@global.max_allowed_packet, @@session.max_allowed_packet; +-----------------------------+------------------------------+ | @@global.max_allowed_packet | @@session.max_allowed_packet | +-----------------------------+------------------------------+ | 629145600 | 629145600 | +-----------------------------+------------------------------+

服务器环境：Ubuntu Server 14.04LTS

Server environment: Ubuntu Server 14.04LTS

MySQL版本：5.6

这是一个专用的MySQL服务器，上面没有其他应用程序。

This is a dedicated MySQL server, it has no other apps on it.

我的内存不足：

MemTotal: 32948824 kB MemFree: 31494136 kB Cached: 281624 kB SwapCached: 0 kB SwapTotal: 33550332 kB SwapFree: 33550332 kB

推荐答案

我终于能够解决此问题，绕过MySQL Workbench迁移工具，并使用mysqldup生成用于还原到服务器的数据库.sql文件。这是我的工作：

I was finally able to fix this issue but bypassing the MySQL Workbench Migration Tool and using mysqldup to generate the database .sql file used to restore to the server. Here's what I did:

从正在超时的MySQL服务器上删除所有数据库

已导出通过mysqldump从备份数据库中获取所有数据

将该转储文件恢复到新的MySQL服务器（超时的数据库）

Ran mysql_upgrade，所有表均正常执行查询：现在一切正常

Deleted all databases from the MySQL server that was timing out

Exported all the data from our backup database via mysqldump

Restored that dump file to the new MySQL server (the one that was timing out)

Ran mysql_upgrade, all tables OK Executed the query: everything now works

这很奇怪：mysqlcheck和mysql_upgrade ，在因某种原因超时的数据库上运行时，返回状态为OK，但未发现任何错误。我不知道为什么，但是我认为这是一个非常奇怪和烦人的问题，考虑到这正是mysqlcheck的目的。

Here's the strange thing: mysqlcheck and mysql_upgrade, when run on the database that was somehow timing out, were returning status OK and not finding any errors. I do not know why, but I see this is a pretty strange and annoying problem, considering that's exactly what mysqlcheck is for.

如果您遇到此问题，请尝试从较早的备份（如果有）中还原数据库，并查看是否可行。

Anyway if you're having this problem try to restore the database from an older backup (if you have one) and see if that works.