"Table 'mysql.plugin' doesn't exist"引起de血案

       回過頭想一想，一開始查下mysql_install_db這個命令，也不至於承受着巨大的壓力折騰兩天，不得不說，折騰下來的收穫真的不小，好記性不如爛筆頭，記錄下來共勉。 
   故事的開頭是用./mysqld_safe命令起不來MySQL，錯誤提示：ERROR 2002: Can't connect to local MySQL server through socket '/tmp/mysql.sock'，查看/tmp目錄中確實沒有mysql.sock，又看了log-err:[ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it. 「Please run mysql_upgrade to create it」，若是一開始注意到這句話用mysql_upgrade 命令會不會就沒有後頭的事了，查了下這個命令，仍是沒太明白這個命令在此處用的做用，internet上都是說MySQL升級時使用。[採用MySQL_upgrade升級受權表方式升級] 
  當時使用了./mysql_install_db命令，我不知道師弟用的什麼參數，指定的配置文件確定仍是/etc/my.cnf，(沒想到mysql_install_db命令的結果是新建了個數據庫實例，而且通常會新建一個xxx.cnf文件)。而後也新指定了datadir,basedir爲data目錄（之前的在var目錄），生成了新的受權表，my.cnf。mysqld_safe能夠起來了，感受本身棒棒的，可是當咱們登錄phpmyadmin後完全傻了，之前的數據庫都沒有了，沒有第一時間去查mysql_install_db命令的應用場景，滿腦子是闖大禍了，數據被刪了，要怎麼去恢復數據庫，要不要請示項目leader，本身先補救再說。。。 
  恢復數據庫之旅開始，咱們居然找到了之前/var目錄下的全部數據，可是沒有想到直接更改my.cnf配置到這個目錄就能夠，而是堅決的認爲mysql的數據庫都是默認在data目錄的，不能更改，var下的只是副本或者啥的，仍是太年輕了T T。咱們的作法是用var下的數據去data目錄下恢復，使用.frm文件恢復了表結構，按internet上說用ibdata1去恢復數據，可是就是不成功，都沒想到用mysql-bin.00000x文件去恢復，仍是由於太年輕T T。中間還有一個重大的插曲，ssh不能鏈接到阿里雲服務器了，沒辦法，只好將這件事告訴了項目leader，好的是他讓我彆着急，我能不着急嗎，這數據要是真沒了責任都是個人T T。以後leader給阿里雲打電話，工做人員說雲上有近三天的快照，leader說他晚上去恢復到某一天快照，讓咱們不要擔憂。確實是鬆了口氣，恰好也到下班時間，晚上吃了頓好的，以緩解我白天的壓力。 
  然而次日一大早leader打電話說，快照裏頭沒有仍是怎麼的，總之就是經過快照不行，仍是得本身搞。ssh連接不了是由於Linux的var目錄被誰刪了，扶額，哪一個缺心眼乾的，沒事喜歡亂刪。又開始折騰着恢復數據，internet上的方法看的多了，大都是複製之類的，我就想能不能直接指定配置文件中的路徑到./mysql/var呢，反正全部文件都是從var目錄cp的。說幹就幹，mysql起來了，可是登錄進去後每一個數據庫是空的，然而磁盤上每一個數據庫中是有.frm文件的，查看日誌，」Cannot find or open table xxx from the internal data dictionary of InnoDB through the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but hava forgotton to delete the corresponding .frm……, the table contains indexes that this version of the engine doesn’t support.」這段英語說個啥信息，先無論，先給mysql用戶賦予權限試試，重啓，又看到了熟悉的數據熟悉的表！！！結束~ 
  後記： 
  今天（2016/4/25）大早上，甲方工做人員告訴我錄入數據提交不成功，我看到控制檯報：#1030-Get error -1 from storage engine，原來是前幾天捯飭MySQL的時候在my.cnf加了一個參數innodb_force_recovery=4，插入操做被忽略。註釋掉或者設置爲0就能夠執行正常操做了。