Dyntex.net Support Centre: MySQL Reference Manual p.518

<< previous page -- table of contents -- next page >>

Chapter_1

Chapter_2

Chapter_3

Chapter_4

Chapter_5

Return to Table of Contents

Table of Contents
1. General Information
2. MySQL Installation
3. Tutorial Introduction
4. Database Administration
5. MySQL Optimisation
6. MySQL Language Reference
7. MySQL Table Types
8. MySQL APIs
9. Extending MySQL

518 MySQL Technical Reference for Version 4.0.3 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections If your database gets corrupted or your disk fails, you have to do the recovery from a backup. In the case of corruption, you should rst nd a backup which is not corrupted. From a backup do the recovery from the general log les of MySQL according to instructions in the MySQL manual. 7.5.6.1 Checkpoints InnoDB implements a checkpoint mechanism called a fuzzy checkpoint. InnoDB will ush modied database pages from the buer pool in small batches, there is no need to ush the buer pool in one single batch, which would in practice stop processing of user SQL statements for a while. In crash recovery InnoDB looks for a checkpoint label written to the log les. It knows that all modications to the database before the label are already present on the disk image of the database. Then InnoDB scans the log les forward from the place of the checkpoint applying the logged modications to the database. InnoDB writes to the log les in a circular fashion. All committed modications which make the database pages in the buer pool dierent from the images on disk must be available in the log les in case InnoDB has to do a recovery. This means that when InnoDB starts to reuse a log le in the circular fashion, it has to make sure that the database page images on disk already contain the modications logged in the log le InnoDB is going to reuse. In other words, InnoDB has to make a checkpoint and often this involves ushing of modied database pages to disk. The above explains why making your log les very big may save disk I/O in checkpointing. It can make sense to set the total size of the log les as big as the buer pool or even bigger. The drawback in big log les is that crash recovery can last longer because there will be more log to apply to the database. 7.5.7 Moving an InnoDB Database to Another Machine InnoDB data and log les are binary-compatible on all platforms if the oating-point num- ber format on the machines is the same. You can move an InnoDB database simply by

MySQL Reference Manual

Our Partners

SpiritHost - web hosting for spiritual and education sites
SpiritHit.com - Religious and Spiritual Portal

Return to Table of Contents	Back to top

Web Hosting: Manuals & FAQ's

1. Unix-Based Web Hosting
2. Unix Dedicated Servers
3. Windows Dedicated Servers
4. CuteFTP User’s Guide
5. CuteHTML User’s Guide
6. WS_FTP Pro User's Guide
7. Miva Order User's Guide
8. Miva Merchant User's Guide