[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mysql-internals
Subject:    bk commit - mysqldoc tree (1.766)
From:       heikki () mysql ! com
Date:       2003-08-28 22:32:50
[Download RAW message or body]

Below is the list of changes that have just been committed into a local
mysqldoc repository of heikki. When heikki does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html

ChangeSet
  1.766 03/08/29 01:32:46 heikki@hundin.mysql.fi +1 -0
  manual.texi:
    Add forgotten section about forcing recovery

  Docs/manual.texi
    1.705 03/08/29 01:32:37 heikki@hundin.mysql.fi +79 -2
    Add forgotten section about forcing recovery

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	heikki
# Host:	hundin.mysql.fi
# Root:	/home/heikki/mysqldoc

--- 1.704/Docs/manual.texi	Thu Aug 28 12:19:00 2003
+++ 1.705/Docs/manual.texi	Fri Aug 29 01:32:37 2003
@@ -46099,6 +46099,15 @@
 (Available from 3.23.40 up.)
 The default value for this is @code{fdatasync}.
 Another option is @code{O_DSYNC}.
+@item @code{innodb_force_recovery} @tab
+Warning: this option should only be defined in an emergency situation
+when you want to dump your tables from a corrupt database!
+Possible values are 1 - 6. See below at section 'Forcing
+recovery' about the meanings of the values.
+As a safety measure InnoDB prevents a user from modifying
+data when this option is > 0.
+This option is
+available starting from version 3.23.44.
 @end multitable
 
 
@@ -46575,11 +46584,79 @@
 MySQL manual.
 
 @menu
-* InnoDB checkpoints::          Checkpoints
+* Forcing recovery::          Forcing recovery
+* InnoDB checkpoints::        Checkpoints
 @end menu
 
 
-@node InnoDB checkpoints,  , Backing up, Backing up
+@node Forcing recovery, InnoDB checkpoints, Backing up, Backing up
+@subsubsection Forcing recovery
+
+If there is database page corruption, you may want to dump
+your tables from the database with @code{SELECT INTO OUTFILE},
+and usually most of the data
+is intact and correct. But the corruption may cause
+@code{SELECT * FROM table}, or 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 @file{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
+@example
+set-variable = innodb_force_recovery = 4
+@end example
+in @file{my.cnf}.
+
+The alternatives for @code{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 doing @code{INSERT},
+@code{UPDATE}, or @code{DELETE} when this option is > 0.
+
+Starting from version 3.23.53 and 4.0.4, you are allowed to
+@code{DROP} or @code{CREATE} a table even if
+forced recovery is used. If you know that a certain table is causing
+a crash in rollback, you can drop it.
+You can use this also to stop a runaway rollback
+caused by a failing mass import or @code{ALTER TABLE}.
+You can kill the mysqld process and
+use the @file{my.cnf} option @code{innodb_force_recovery=3}
+to bring your database up without the rollback.
+Then @code{DROP} the table which is causing the runaway rollback.
+
+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.
+
+@itemize @bullet
+@item 1 (SRV_FORCE_IGNORE_CORRUPT) let the server run even if it detects a
+                                corrupt page; try to make
+                                @code{SELECT * FROM table}
+                                jump over corrupt index records and pages,
+                                which helps in dumping tables;
+@item 2 (SRV_FORCE_NO_BACKGROUND) prevent the main thread from
+                                running: if a crash would occur
+                                in purge, this prevents it;
+@item 3 (SRV_FORCE_NO_TRX_UNDO) do not run transaction rollbacks
+                                after recovery;
+@item 4 (SRV_FORCE_NO_IBUF_MERGE) prevent also insert buffer merge operations:
+                                if they would cause a crash, better
+                                not do them; do not calculate table statistics;
+@item 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;
+@item 6 (SRV_FORCE_NO_LOG_REDO)   do not do the log roll-forward
+                                in connection with recovery.
+@end itemize
+
+
+@node InnoDB checkpoints,  , Forcing recovery, Backing up
 @subsubsection Checkpoints
 
 InnoDB implements a checkpoint mechanism called a fuzzy

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals?unsub=mysql-internals@progressive-comp.com

[prev in list] [next in list] [prev in thread] [next in thread]