Oracle 5.0, Reference Manual

Page: 1283 / 3232

Backing Up and Recovering an
InnoDB
Database
1263
•
1
(
SRV_FORCE_IGNORE_CORRUPT
)
Let the server run even if it detects a corrupt page. Try to make
SELECT * FROM tbl_name
jump
over corrupt index records and pages, which helps in dumping tables.
•
2
(
SRV_FORCE_NO_BACKGROUND
)
Prevent the main thread from running. If a crash would occur during the purge operation, this
recovery value prevents it.
•
3
(
SRV_FORCE_NO_TRX_UNDO
)
Do not run transaction rollbacks after recovery.
•
4
(
SRV_FORCE_NO_IBUF_MERGE
)
Prevent insert buffer merge operations. If they would cause a crash, do not do them. Do not calculate
table statistics.
•
5
(
SRV_FORCE_NO_UNDO_LOG_SCAN
)
Do not look at undo logs when starting the database:
InnoDB
treats even incomplete transactions as
committed.
•
6
(
SRV_FORCE_NO_LOG_REDO
)
Do not do the log roll-forward in connection with recovery.
The database must not otherwise be used with any nonzero value of
innodb_force_recovery
[1243] . As a safety measure,
InnoDB
prevents users from performing
INSERT
,
UPDATE
, or
DELETE
operations when
innodb_force_recovery
[1243] is greater than 0.
You can
SELECT
from tables to dump them, or
DROP
or
CREATE
tables even if forced recovery is used.
If you know that a given table is causing a crash on rollback, you can drop it. You can also use this to
stop a runaway rollback caused by a failing mass import or
ALTER TABLE
. You can kill the
mysqld
process and set
innodb_force_recovery
[1243] to
3
to bring the database up without the rollback,
then
DROP
the table that is causing the runaway rollback.
14.2.5.3.
InnoDB
Checkpoints
InnoDB
implements a checkpoint mechanism known as “fuzzy” checkpointing.
InnoDB
flushes
modified database pages from the buffer pool in small batches. There is no need to flush the buffer
pool in one single batch, which would in practice stop processing of user SQL statements during the
checkpointing process.
During crash recovery,
InnoDB
looks for a checkpoint label written to the log files. It knows that all
modifications to the database before the label are present in the disk image of the database. Then
InnoDB
scans the log files forward from the checkpoint, applying the logged modifications to the
database.
InnoDB
writes to its log files on a rotating basis. It also writes checkpoint information to the first
log file at each checkpoint. All committed modifications that make the database pages in the buffer
pool different from the images on disk must be available in the log files in case
InnoDB
has to do a
recovery. This means that when
InnoDB
starts to reuse a log file, it has to make sure that the database
page images on disk contain the modifications logged in the log file that
InnoDB
is going to reuse. In
other words,
InnoDB
must create a checkpoint and this often involves flushing of modified database
pages to disk.
The preceding description explains why making your log files very large may reduce disk I/O in
checkpointing. It often makes sense to set the total size of the log files as large as the buffer pool or
even larger. The disadvantage of using large log files is that crash recovery can take longer because
there is more logged information to apply to the database.