Ervin, ----- Original Message ----- From: "Ervin Gerke" <[EMAIL PROTECTED]> To: "'Heikki Tuuri'" <[EMAIL PROTECTED]> Sent: Tuesday, December 10, 2002 8:53 PM Subject: RE: InnoDB crash?
> Heikki, > > That's all mysqld reported in err log. In fact I wasn't able to do a > check table since mysqld died (SIGSEGV) on me right after logging that > message in .err log. In fact I don't run anything funny on the hardware > side. No RAIDs or anything. I am copying this to [EMAIL PROTECTED], so that other users can follow the discussion. Looks like InnoDB asserts when it does the background purge immediately after a startup. You should set set-variable=innodb_force_recovery=2 in my.cnf. If that does not help, try a value 4. Then run CHECK TABLE on your tables. You may have serious corruption. You may have to dump all tables and recreate the whole InnoDB tablespace. In mild cases it is enough to dump + DROP + CREATE + reimport one or a few tables. The log sequence number you have is 288 GB. You have done of processing with the database. Regards, Heikki Innobase Oy sql query > Well here goes when I try to start mysqld without innodb_force_recovery > and that message appears repeatedly (I'm using the rc.d script): > > ------------------ > /usr/bin/mysqld_safe: line 311: 7413 Segmentation fault > $NOHUP_NICENESS $ledir/$MYSQLD $defaults --basedir=$MY_BASEDIR_VERSION > --datadir=$DATADIR $USER_OPTION --pid-file=$pid_file --skip-locking > >>$err_log 2>&1 > ------------------ > > The whole .err log reads (repeatedly again): > > ------------------ > Number of processes running now: 1 > mysqld-max process hanging, pid 7451 - killed > 021210 13:35:35 mysqld restarted > 021210 13:35:35 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 72 4284476337 > InnoDB: Doing recovery: scanned up to log sequence number 72 4284476337 > 021210 13:35:36 InnoDB: Flushing modified pages from the buffer pool... > 021210 13:35:36 InnoDB: Started > /usr/sbin/mysqld-max: ready for connections > 021210 13:35:37 InnoDB: Assertion failure in thread 7176 in file > page0page.c line 450 > InnoDB: We intentionally generate a memory trap. > InnoDB: Send a detailed bug report to [EMAIL PROTECTED] > 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=268431360 > read_buffer_size=1044480 > > Number of processes running now: 1 > mysqld-max process hanging, pid 7481 - killed > 021210 13:35:37 mysqld restarted > 021210 13:35:37 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 72 4284476337 > InnoDB: Doing recovery: scanned up to log sequence number 72 4284476337 > 021210 13:35:38 InnoDB: Flushing modified pages from the buffer pool... > 021210 13:35:38 InnoDB: Started > /usr/sbin/mysqld-max: ready for connections > 021210 13:35:39 InnoDB: Assertion failure in thread 7176 in file > page0page.c line 450 > InnoDB: We intentionally generate a memory trap. > InnoDB: Send a detailed bug report to [EMAIL PROTECTED] > 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=268431360 > read_buffer_size=1044480 > ...... > ---------- > > Should I let InnoDB to be fully recovered and then run checks on my > tables? > > > --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
