阿里云服務器 MySQL 經常自動停止、掛掉、重啟。打開 MySQL 的 error.log 錯誤信息，在阿里云 CentOS 的路徑為 /alidata/log/mysql/error.log,如下：

2016-03-13 00:16:37 0[Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use--explicit_defaults_for_timestampserver option(see documentationformore details). 2016-03-13 00:16:37 30576[Note] Plugin'FEDERATED'is disabled. 2016-03-13 00:16:37 30576[Note] InnoDB: Using atomics to ref count buffer pool pages 2016-03-13 00:16:37 30576[Note] InnoDB: The InnoDB memory heap is disabled 2016-03-13 00:16:37 30576[Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2016-03-13 00:16:37 30576[Note] InnoDB: Memory barrier is not used 2016-03-13 00:16:37 30576[Note] InnoDB: Compressed tables use zlib 1.2.3 2016-03-13 00:16:37 30576[Note] InnoDB: Using Linux native AIO 2016-03-13 00:16:37 30576[Note] InnoDB: Using CPU crc32 instructions 2016-03-13 00:16:37 30576[Note] InnoDB: Initializing buffer pool, size=64.0M 2016-03-13 00:16:37 30576[Note] InnoDB: Completed initialization of buffer pool 2016-03-13 00:16:37 30576[Note] InnoDB: Highest supported file format is Barracuda. 2016-03-13 00:16:37 30576[Note] InnoDB: The log sequence numbers 52296883 and 52296883inibdata filesdonot match the log sequence number 93636989inthe ib_logfiles! 2016-03-13 00:16:37 30576[Note] InnoDB: Database was not shutdown normally! 2016-03-13 00:16:37 30576[Note] InnoDB: Starting crash recovery. 2016-03-13 00:16:37 30576[Note] InnoDB: Reading tablespace information from the .ibd files... 2016-03-13 00:16:37 30576[Note] InnoDB: Restoring possible half-written data pages 2016-03-13 00:16:37 30576[Note] InnoDB: from the doublewrite buffer...InnoDB: Last MySQL binlog file position 0 9828, file name mysql-bin.000335 2016-03-13 00:16:37 30576[Note] InnoDB: 128 rollback segment(s)are active. 2016-03-13 00:16:37 30576[Note] InnoDB: Waitingforpurge to start 2016-03-13 00:16:37 30576[Note] InnoDB: 5.6.21 started;log sequence number 93636989 2016-03-13 00:16:38 30576[Note] Recovering after a crash using mysql-bin 2016-03-13 00:16:38 30576[Note] Starting crash recovery... 2016-03-13 00:16:38 30576[Note] Crash recovery finished. 2016-03-13 00:16:40 30576[Note] Server hostname(bind-address):'*';port: 3306 2016-03-13 00:16:40 30576[Note] IPv6 is not available. 2016-03-13 00:16:40 30576[Note] -'0.0.0.0'resolves to'0.0.0.0'; 2016-03-13 00:16:40 30576[Note] Server socket created on IP:'0.0.0.0'. 2016-03-13 00:16:41 30576[Note] Event Scheduler: Loaded 0 events 2016-03-13 00:16:41 30576[Note] /alidata/server/mysql/bin/mysqld: readyforconnections.Version:'5.6.21-log'socket:'/tmp/mysql.sock'port: 3306 MySQL Community Server(GPL)160313 00:16:41 mysqld_safe Number of processes running now: 0160313 00:16:41 mysqld_safe mysqld restarted

MySQL 的 error.log 中，我們很難找出出是哪里出了問題。去 Google 了一下，給出的答案基本是修改”/alidata/server/mysql/my.cnf”:

innodb_buffer_pool_size=64M# 默認為128M，修改成64M、32M或者8M，但實際上重啟 MySQL 之后以為能運行，實際上過了一會 MySQL 還是會出現不知原因地自動關閉。

注意去看其中的2016-03-13 00:16:37 30576[Note] InnoDB: Database was not shutdown normally!說明了 MySQL 非正常關閉，MySQL 也不知道自己為什么被關閉掉了。。。于是， MySQL 覺得真奇怪，自己又重啟了自己的進程開始 Crash Recoverying，如下：

接著，大家又猜想這條2016-03-13 00:16:37 30576[Note] InnoDB: The log sequence numbers 52296883 and 52296883inibdata filesdonot match the log sequence number 93636989inthe ib_logfiles!Google，發現原來就是這里搗鬼，才出現了 MySQL 再重啟之后，又繼續自動關閉，再重啟。于是，嘗試按照 StackOverflow 上面的 suggestions 去做：

重啟，又可以了。。。沒一會，嚓，MySQL 又宕了！這次不僅宕，而且 error.log 又多了因 * innodb_force_recovery = 6 * 而引起的錯誤。

怎么辦？現在我們回到下面這條日志：

2016-03-13 00:16:37 30576[Note] InnoDB: Database was not shutdown normally!

現在我們要看看，為什么 MySQL 會不正常關閉呢！？現在我們打開top看看。下面使用htop進行查看：

一看 mysql 進程占用的 VIRT 怎么這么多！這時，你要是多刷新幾下你服務器上搭建的 WordPress 網站的主頁的話，會出現 mysql 內存占用率超過 50% 的情況，這時候 mysql 進程就會被 linux 內核殺死。也就出現了我們在 MySQL 的 error.log 中看到的“[Note] InnoDB: Database was not shutdown normally!” 日志了。

為了確定這個猜測是否真實，我們去看看 kernel 日志。

接著你會看到：

看到最后的兩條：

好了，終于找出原因了，內存不夠，殺死了 mysqld 進程。

下面是我的優化方案：

1.創建 SWAP 分區：
檢查系統Swap文件信息

sudo swapon -s free -m

檢查硬盤可用空間

df -h

創建Swap文件

sudo /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024

激活Swap

sudo /sbin/mkswap /var/swap.1 sudo /sbin/swapon /var/swap.1

使Swap在主機重啟后依然生效

sudo nano /etc/fstab

加入以下內容

/var/swap.1 swap swap defaults 0 0 All done!

2.降低數據庫 InnoDB 引擎的緩沖區大小，以及限制 MySQL 的最大連接數(max_connections)：
降低 InnoDB 緩沖區大小為 64M 或者 32M（到mysql配置文件中修改）

innodb_buffer_pool_size=64M

限制最大連接數為100，在服務器配置很低時可以繼續降低

max_connections=100

修改完重啟 MySQL：

service mysqld restart

注釋：max_connections 的默認值是 151，可以動態更改這個值。參見：max_connections

如有必要，可以重啟服務器: reboot

總結

以上是生活随笔為你收集整理的sqlyog怎么连接mysql错误2003_网站突然连不上，MySQL连接错误经常内存不够宕机的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。