On Wed, 2006-06-21 at 17:31 +0800, Nyoman D wrote: > Hello tanya-jawab, > > Hari ini tiba2 mysqld saya mati, setelah saya login melalui ssh dan > coba restart service nggak bisa....berikut error lognya: > > bash-2.05b$ /usr/libexec/mysqld --log > 060621 0:53:22 InnoDB: Out of memory in additional memory pool. > InnoDB: InnoDB will start allocating memory from the OS. > InnoDB: You may get better performance if you configure a bigger > InnoDB: value in the MySQL my.cnf file for > InnoDB: innodb_additional_mem_pool_size. > 060621 0:53:22 InnoDB: Database was not shut down normally. > InnoDB: Starting recovery from log files... > InnoDB: Starting log scan based on checkpoint at > InnoDB: log sequence number 0 2341750307 > 060621 0:53:51 InnoDB: Assertion failure in thread 3210376288 in file > os0file.c line 1062 > InnoDB: We intentionally generate a memory trap. > InnoDB: Send a detailed bug report to mysql@lists.mysql.com > 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 diagnose > the problem, but since we have already crashed, something is definitely wrong > and this may fail > > key_buffer_size=8388600 > record_buffer=131072 > sort_buffer=2097144 > max_used_connections=0 > max_connections=100 > threads_connected=0 > It is possible that mysqld could use up to > key_buffer_size + (record_buffer + sort_buffer)*max_connections = 225791 K > bytes of memory > Hope that's ok, if not, decrease some variables in the equation > > Attempting backtrace. You can use the following information to find out > where mysqld died. If you see no messages after this, something went > terribly wrong... > Bogus stack limit or frame pointer, fp=0xbfe9e24c, stack_bottom=0x562c9a10, > thread_stack=65536, aborting backtrace. > Trying to get some variables. > Some pointers may be invalid and cause the dump to abort... > thd->query at 0x552107a0 is invalid pointer > thd->thread_id=9990912 > > Successfully dumped variables, if you ran with --log, take a look at the > details of what thread 9990912 did to cause the crash. In some cases of > really > bad corruption, the values shown above may be invalid > > The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains > information that should help you find out what is causing the crash > > Saya pertama curiga ada database yang rusak, setelah nge google > katanya bisa pakai myisamchk -r -q untuk repair, tapi tetap saja nggak > bisa di running servicenya, akhirnya coba-coba mv /var/lib/mysql > /var/lib/mysql.org dan jalanin lagi servicenya.... horeeee sempat > senang karena service nya jalan, kemudian saya coba: > service mysqld stop > mv /var/lib/mysql /var/lib/mysql.new dan mv /var/lib/mysql.org /var/lib/mysql > dan timpa file2 ib* dari /var/lib/mysql.new kemudian jalanin lagi > service mysqld start > service mysqld jalan normal, tapi ketika coba akses databasenya error: > > Error > SQL query: > SHOW INDEX FROM `accounts` ; > > MySQL said: > #1016 - Can't open file: 'accounts.InnoDB'. (errno: 1) > > Ada cara cepat biar databasenya bisa up lagi ?? > > Thanks > > Nyoman.
-- FAQ milis di http://wiki.linux.or.id/FAQ_milis_tanya-jawab Unsubscribe: kirim email ke [EMAIL PROTECTED] Arsip dan info milis selengkapnya di http://linux.or.id/milis
