Date: 2011-03-24 07:48:01 +0100 (Thu, 24 Mar 2011)
New Revision: 25500
Copied "crash recovery" to the backup glossary.
Again, probably needs to be adapted for the backup context.
(To be less scary, if nothing else.)
--- trunk/dynamic-docs/glossary/backup.xml 2011-03-24 06:46:43 UTC (rev 25499)
+++ trunk/dynamic-docs/glossary/backup.xml 2011-03-24 06:48:01 UTC (rev 25500)
Changed blocks: 3, Lines Added: 31, Lines Deleted: 1; 2153 bytes
@@ -183,6 +183,34 @@
+ <glossent id="crash_recovery">
+ <gterm>crash recovery</gterm>
+ The cleanup activities that occur when InnoDB is started again
+ after a crash. Changes that were committed before the crash, but
+ not yet written into the tablespace files, are reconstructed
+ from the <emphasis role="bold">doublewrite buffer</emphasis>.
+ When the database is shut down normally, this type of activity
+ is performed during shutdown by the
+ <emphasis role="bold">purge</emphasis> operation.
+ During normal operation, committed data can be stored in the
+ insert buffer for a period of time before being written to the
+ tablespace files. There is always a tradeoff between keeping the
+ tablespace files up-to-date, which introduces performance
+ overhead during normal operation, and buffering the data, which
+ can make shutdown and crash recovery take longer.
+<!-- <gseealso glosid=""/> -->
@@ -473,7 +501,8 @@
in the <emphasis role="bold">redo log</emphasis>. (This point in
time is regardless of transaction boundaries; it can fall in the
middle of one or more transactions.) It is used internally by
- InnoDB during crash recovery and for managing the buffer pool.
+ InnoDB during <emphasis role="bold">crash recovery</emphasis>
+ and for managing the buffer pool.
In the <emphasis role="bold">MySQL Enterprise Backup</emphasis>
@@ -487,6 +516,7 @@
+ <gseealso glosid="crash_recovery"/>
|• svn commit - mysqldoc@oter02: r25500 - trunk/dynamic-docs/glossary||john.russell||24 Mar|