Guto, what version of MySQL you are running and on what operating system and version?
Please upgrade to the latest 3.23.47. Many bugs in earlier versions have been fixed. Starting from 3.23.44 you have the following forced recovery option which you can use to dump your tables from a corrupt database. See the online manual at http://www.innodb.com/ibman.html for more information. Best regards, Heikki Tuuri Innobase Oy --- Order technical MySQL/InnoDB support at https://order.mysql.com/ See http://www.innodb.com for the online manual and latest news on InnoDB .............. 6.1 Forcing recovery In some cases apparent database page corruption is actually due to the operating system which has corrupted its own file cache, and the data on disk may be ok. It is best first to try rebooting your computer. It may remove the errors which appeared as database page corruption. If there is database page corruption, you may want to dump your tables from the database with SELECT INTO OUTFILE, and usually most of the data is intact and correct. But the corruption may cause InnoDB background operations to crash or assert, or even the InnoDB roll-forward recovery to crash. Starting from the InnoDB version 3.23.44 there is a my.cnf option with which you can force InnoDB to start up, and you can also prevent background operations from running, so that you will be able to dump your tables. For example, you can set set-variable = innodb_force_recovery = 4 in my.cnf. The alternatives for innodb_force_recovery are listed below. The database must not otherwise be used with these options! As a safety measure InnoDB prevents a user from modifying data when this option is > 0. A bigger number below means that all precautions of lower numbers are included. If you are able to dump your tables with an option at most 4, then you are relatively safe that only some data on corrupt individual pages is lost. Option 6 is more dramatic, because database pages are left in an obsolete state, which in turn may introduce more corruption into B-trees and other database structures. 1 (SRV_FORCE_IGNORE_CORRUPT) let the server run even if it detects a corrupt page; 2 (SRV_FORCE_NO_BACKGROUND) prevent the main thread from running: if a crash would occur in purge, this prevents it; 3 (SRV_FORCE_NO_TRX_UNDO) do not run transaction rollbacks after recovery; 4 (SRV_FORCE_NO_IBUF_MERGE) prevent also insert buffer merge operations: if they would cause a crash, better not do them; 5 (SRV_FORCE_NO_UNDO_LOG_SCAN) do not look at undo logs when starting the database: InnoDB will treat even incomplete transactions as committed; 6 (SRV_FORCE_NO_LOG_REDO) do not do the log roll-forward in connection with recovery. .......... ....................................... Dear folks, Itīs the first time Iīm using this list and now I got a really big problem. Itīs the fourth time the error below hapens to my server and every time it happened I had to process back my backup file. Iīve been working all day long and I donīt wanna loose the information this time. How can I get inside the log and delete manually this uncommitted transaction to put my server up again? Is there a way to do such a thing? Thanks. Guto Vannini 020116 17:21:23 mysqld started 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 96570467 InnoDB: Doing recovery: scanned up to log sequence number 0 96587059 Innobase: 1 uncommitted transaction(s) which must be rolled back Innobase: Starting rollback of uncommitted transactions Innobase: Rolling back trx no 760417 mysqld got signal 11; The manual section 'Debugging a MySQL server' tells you how to use a stack trace and/or the core file to produce a readable backtrace that may help in finding out why mysqld died. 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, aborting backtrace. 020116 17:21:23 mysqld ended --------------------------------------------------------------------- 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
