<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="innodb-checkpoints">
      </a>
      17.11.3 InnoDB Checkpoints
     </h3>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045160628320">
  </a>
  <p>
   Making your
   <a class="link" href="glossary.html#glos_log_file" title="log file">
    log files
   </a>
   very
      large may reduce disk I/O during
   <a class="link" href="glossary.html#glos_checkpoint" title="checkpoint">
    checkpointing
   </a>
   . It often
      makes sense to set the total size of the log files as large as the
      buffer pool or even larger.
  </p>
  <h4>
   <a name="idm46045160624608">
   </a>
   How Checkpoint Processing Works
  </h4>
  <p>
   <code class="literal">
    InnoDB
   </code>
   implements a
   <a class="link" href="glossary.html#glos_checkpoint" title="checkpoint">
    checkpoint
   </a>
   mechanism known
      as
   <a class="link" href="glossary.html#glos_fuzzy_checkpointing" title="fuzzy checkpointing">
    fuzzy
      checkpointing
   </a>
   .
   <code class="literal">
    InnoDB
   </code>
   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
      disrupt processing of user SQL statements during the checkpointing
      process.
  </p>
  <p>
   During
   <a class="link" href="glossary.html#glos_crash_recovery" title="crash recovery">
    crash recovery
   </a>
   ,
   <code class="literal">
    InnoDB
   </code>
   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
   <code class="literal">
    InnoDB
   </code>
   scans the log files forward from
      the checkpoint, applying the logged modifications to the database.
  </p>
 </div>
 <br/>
</div>
