無法啓動mysql服務器

我得到了啓動我的mysql服務器的問題，它工作正常，直到我將「準備好」mysql配置文件（/usr/local/share/mysql/my-huge.cnf）複製到/etc/my.cnf，然後我重新啓動我的mysql服務器並且不幸它停止了，而不是重新啓動。無法啓動mysql服務器

我沒有任何控制檯錯誤，但是這出現在我的/var/db/mysql/hostname.pid文件：

120312 17:57:43 mysqld_safe mysqld from pid file /var/db/mysql/hostname.pid ended 
120312 17:58:09 mysqld_safe Starting mysqld daemon with databases from /var/db/mysql 
120312 17:58:09 InnoDB: The InnoDB memory heap is disabled 
120312 17:58:09 InnoDB: Mutexes and rw_locks use GCC atomic builtins 
120312 17:58:09 InnoDB: Compressed tables use zlib 1.2.3 
120312 17:58:09 InnoDB: Initializing buffer pool, size = 128.0M 
120312 17:58:09 InnoDB: Completed initialization of buffer pool 
120312 17:58:09 InnoDB: highest supported file format is Barracuda. 
InnoDB: The log sequence number in ibdata files does not match 
InnoDB: the log sequence number in the ib_logfiles! 
120312 17:58:09 InnoDB: Database was not shut down normally! 
InnoDB: Starting crash recovery. 
InnoDB: Reading tablespace information from the .ibd files... 
InnoDB: Restoring possible half-written data pages from the doublewrite 
InnoDB: buffer... 
120312 17:58:09 InnoDB: Assertion failure in thread 34387018176 in file fsp0fsp.c line 2040 
InnoDB: Failing assertion: inode 
InnoDB: We intentionally generate a memory trap. 
InnoDB: Submit a detailed bug report to http://bugs.mysql.com. 
InnoDB: If you get repeated assertion failures or crashes, even 
InnoDB: immediately after the mysqld startup, there may be 
InnoDB: corruption in the InnoDB tablespace. Please refer to 
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html 
InnoDB: about forcing recovery. 
17:58:09 UTC - mysqld got signal 6 ; 
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 
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail. 

key_buffer_size=8388608 
read_buffer_size=131072 
max_used_connections=0 
max_threads=151 
thread_count=0 
connection_count=0 
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338444 K bytes of memory 
Hope that's ok; if not, decrease some variables in the equation. 

120312 17:58:09 mysqld_safe mysqld from pid file /var/db/mysql/hostname.pid ended

的哪些錯誤？

來源

2012-03-12 Cyclone

備份舊的cnf文件。您的服務器的配置與您的my-huge.cnf不匹配 - 嘗試從ib_data文件備份我的服務器時，出現與linux類似的錯誤。 MyISAM工作正常，但innodb沒有，因爲它使用其他文件來組成你的表.. – B4NZ41 2012-03-12 18:26:53

您的ibdata文件大小錯誤。

更確切地說，您的ibdata文件與您在新my.cnf文件中指定的文件大小不同。在my.cnf文件的舊版本和新版本中檢查ibdata的值（以及bin日誌文件），你會發現它們是不同的。

你會有使用舊值來獲取數據庫啓動;在那裏檢查其他的innodb值：使所有重要的值相同（在你工作後你會改回它們）。一旦你開始了，轉儲你的dbs，然後關閉mysqld。編輯my.cnf文件，刪除ibdata，重新啓動數據庫，然後重新導入您的數據庫。 Presto - 固定。

來源

2012-03-12 18:27:39

嗯，它非常奇怪，因爲當我刪除日誌文件，「ibdata」文件，最後是'my.cnf'文件... mysql正在盯着，但爲什麼它開始沒有配置？當我將任何配置文件放入'/ etc'時，出現問題...... – Cyclone 2012-03-12 18:41:25

如果沒有配置文件，mysqld將以所有默認值啓動，所以這就是沒有配置文件的原因。我認爲你應該對這一系列任務好：備份（因爲你有ibdata文件中的數據），刪除ibdata和ib_logfile [01]，設置你想要的配置，開始 - 你就可以使用它。重新加載你的數據，你會一切設置。 – 2012-03-13 12:38:58

它看起來像你my.cnf文件不好或有一些壞的條目。你有my.cnf的副本，你用my-huge.cnf取代了嗎？我會嘗試在兩個文件上運行差異，看看發生了什麼。

來源

2012-03-12 18:24:43 Peter

它不是我自己的'my.cnf'文件 - 它的讀取使用mysql安裝後出現的文件，默認情況下沒有'/ etc /'中的'my.cnf'文件但是mysql服務器工作正常！然後我複製了示例文件，並開始出現問題，也嘗試刪除此文件並啓動mysql服務器 - 沒有結果，也嘗試用我在另一臺服務器上使用的文件替換此cnf文件 - 但仍然無法啓動。 .. – Cyclone 2012-03-12 18:28:53

也許Innodb日誌已損壞。您應該備份重命名此日誌並重新啓動mysqld，然後mysqld創建新日誌並希望正確重啓。

來源

2012-03-12 18:26:12 ontananza

已經嘗試過你所說的 - 沒有結果。 – Cyclone 2012-03-12 18:38:38

無法啓動mysql服務器

回答

相關問題