MySQL下罕見的啟動掉敗與備份掉敗成績的處理教程。本站提示廣大學習愛好者：（MySQL下罕見的啟動掉敗與備份掉敗成績的處理教程）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL下罕見的啟動掉敗與備份掉敗成績的處理教程正文
啟動掉敗
重啟辦事器後-->重啟運用辦事(Confluence)-->報錯，數據庫銜接掉敗（mysql設置了開機自啟動）-->檢查mysql數據庫狀況：
[root@fisheye ~]# ps -ef | grep mysql root 25555 21974 0 11:28 pts/0 00:00:00 grep mysql
啟動mysql辦事器
[root@fisheye data]# service mysql start
MySQL server PID file could not be found![掉敗] Starting MySQL.............. ERROR! The server quit without updating PID file (/mydata/data/fisheye..pid).[掉敗]
檢查毛病日記：
[root@fisheye data]# tail -100 fisheye.err
InnoDB: Last MySQL binlog file position 0 337403929, file name ./mysql-bin.000016 141013 1:13:28 InnoDB: Waiting for the background threads to start 141013 1:13:29 InnoDB: 5.5.33 started; log sequence number 1006647152 17:13:29 UTC - mysqld got signal 11 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help di141013 01:13:29 mysqld_safe mysqld from pid file /mydata/data/fisheye.pid ended
未發明顯著性毛病提醒，所以手動創立一個pid文件嘗嘗
[root@fisheye data]# touch /mydata/data/fisheye.pi
再停止重啟辦事：
[root@fisheye data]# service mysql restart
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
忽然想到之前看過此類報錯的文章，記得有能夠是磁盤空間缺乏招致的mysql沒法啟動。
[root@fisheye data]# df -h
（文件體系 容量 已用 可用 已用% 掛載點）
/dev/sda1 9.5G 9.5G 0 100% /
/dev/sda4 5.5G 1.3G 4.0G 24% /mnt/backup
/dev/mapper/IhuilianVG-IhuilianLV00
22G 4.2G 17G 20% /var/www/app
tmpfs 1.3G 0 1.3G 0% /dev/shm
果真如斯，上面枚舉一些相似成績(沒法啟動)的處理思緒：
1.能夠是datadir目次存在的分區滿了(df -h )
處理辦法：翻開設置裝備擺設文件/etc/my.cnf，在[mysqld]節下從新指定命據目次(datadir)，並將本來的數據目次遷徙到從新制訂的數據目次處
關於遷徙：(1)、cp或許tar的時刻必定要把權限給帶上，然則為避免不測建議再受權一次；(2)、數據比擬年夜時必定要先緊縮再遷徙，包管完全性，特殊是scp到其他機械時能夠會超時所以必定要緊縮(tar.gz)；(3)、若是挪動至別的的辦事器必定要包管mysql版本分歧。
2.能夠是/mydata/data/fisheye.pid文件沒有寫的權限
處理辦法 ：賜與權限，履行 “chown -R mysql:mysql /mydata/data/” 然後從新啟動mysqld！
3.能夠過程裡曾經存在mysql過程
處理辦法：用敕令“ps -ef|grep mysqld”檢查能否有mysqld過程，假如有應用“kill -9 過程號”殺逝世，然後從新啟動mysqld！
4.能夠是第二次在機械上裝置mysql，有殘存數據影響了辦事的啟動。
處理辦法：去mysql的數據目次/data看看，假如存在mysql-bin.index，就趕緊把它刪除失落吧，它就是禍首罪魁了。
5.skip-federated字段成績(報錯信息：[ERROR] /mydata/data/mysql/libexec/mysqld: unknown option '--skip-federated')
處理辦法：檢討一下/etc/my.cnf文件中有無沒被正文失落的skip-federated字段，假如有就立刻正文失落吧。
6.selinux惹的禍，假如是centos體系，默許會開啟selinux
處理辦法：封閉它，翻開/etc/selinux/config，把SELINUX=enforcing改成SELINUX=disabled後存盤加入重啟機械嘗嘗。
備份掉敗
解釋
履行 mysqldump 時湧現找不到某一個 tables 而且中止履行？及鎖表後延長湧現的成績記載！
成績及計劃以下
Error Meaage: 履行mysqldump 時湧現找不到某一個 tables 而且中止履行
[root@test100 data]# mysqldump fx > fx.sql
mysqldump: Got error: 1146: Table 'user_suggest_report' doesn't exist when using LOCK TABLES
斟酌加上 --skip-lock-tables或許-R停止鎖表嘗嘗，也是不可，信息以下
[root@test100 data]#mysqldump --skip-lock-tables fx > fx.sql
Error: Couldn't read status information for table vote_results () mysqldump: Couldn't execute 'show create table `user_suggest_report`': Table 'fx.user_suggest_report' doesn't exist (1146)
上岸辦事器檢查能否存在此表
[root@test100 data]#mysql -h127.0.0.1 -D fx mysql> show tables; #檢查一切的表 --> 發明是表存在的
+--------------------------------+ | Tables_in_fx | +--------------------------------+ | user_suggest_report | +--------------------------------+ 80 rows in set (0.00 sec)
刪除此表
mysql> drop table user_suggest_report; #既然是存在的，然則體系卻認定不存在解釋存在成績，索性想刪除嘗嘗
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'user_suggest_report' at line 1
進入mysql存儲目次下將其數據表挪動或刪除
[root@test100 data]# cat /etc/my.cnf | grep datadir datadir=/var/lib/mysql [root@test100 data]# cd /var/lib/mysql/fx/ [root@test100 fx]# mv user_suggest_report.frm /data
重啟mysql辦事器
[root@test100 fx]# service mysqld restart
從新備份操作
[root@test100 data]# mysqldump fx > fx.150109.sql #操作勝利
