Disaster Prevention and Recovery
================================
Database Backups
----------------
LOCK
TABLES. *Note `FLUSH': FLUSH. You only need a read lock; this allows
other threads to continue to query the tables while you are making a
copy of the files in the database directory. The `FLUSH TABLE' is
needed to ensure that the all active index pages is written to disk
before you start the backup.
Starting from 3.23.56 and 4.0.12 `BACKUP TABLE' will not allow you to
overwrite existing files as this would be a security risk.
If you want to make an SQL level backup of a table, you can use `SELECT
INTO OUTFILE' or `BACKUP TABLE'. *Note SELECT::. *Note BACKUP TABLE::.
Another way to back up a database is to use the `mysqldump' program or
the `mysqlhotcopy script'. *Note `mysqldump': mysqldump. *Note
`mysqlhotcopy': mysqlhotcopy.
1. Do a full backup of your database:
shell> mysqldump --tab=/path/to/some/dir --opt db_name
or
shell> mysqlhotcopy db_name /path/to/some/dir
these
methods will not work if your database contains `InnoDB' tables.
`InnoDB' does not store table contents in database directories,
and `mysqlhotcopy' works only for `MyISAM' and `ISAM' tables.)
changes to the database that are made subsequent to the point at
which you executed `mysqldump'.
resume replication after you restore the slave's data. If your slave is
subject to replicating `LOAD DATA INFILE' commands, you should also
backup the `SQL-LOAD*' files which may exist in the `slave-load-tmpdir'
(which is `tmpdir' by default) directory. The slave will need these
files to resume replication of any interrupted `LOAD DATA INFILE'.
If you have to restore something, try to recover your tables using
`REPAIR TABLE' or `myisamchk -r' first. That should work in 99.9% of
all cases. If `myisamchk' fails, try the following procedure (this
will only work if you have started MySQL with `--log-bin', see *Note
Binary log::):
1. Restore the original `mysqldump' backup, or binary backup.
2. Execute the following command to re-run the updates in the binary
log:
shell> mysqlbinlog hostname-bin.[0-9]* | mysql
In your case you may want to re-run only certain binlogs, from
certain positions (usually you want to re-run all binlogs from the
date of the restored backup, possibly excepted some wrong queries).
See *Note mysqlbinlog:: for more information on the `mysqlbinlog'
utility and how to use it.
If you are using the update log (which will be removed in MySQL
5.0) you can execute the content of the update log like this:
shell> ls -1 -t -r hostname.[0-9]* | xargs cat | mysql
`ls' is used to get all the update log files in the right order.
You can also do selective backups with `SELECT * INTO OUTFILE
'file_name' FROM tbl_name' and restore with `LOAD DATA INFILE
'file_name' REPLACE ...' To avoid duplicate records, you need a
`PRIMARY KEY' or a `UNIQUE' key in the table. The `REPLACE' keyword
causes old records to be replaced with new ones when a new record
duplicates an old record on a unique key value.
If you get performance problems in making backups on your system, you
can solve this by setting up replication and do the backups on the slave
instead of on the master. *Note Replication Intro::.
If you are using a Veritas filesystem, you can do:
1. From a client (or Perl), execute: `FLUSH TABLES WITH READ LOCK'.
2. From another shell, execute: `mount vxfs snapshot'.
3. From the first client, execute: `UNLOCK TABLES'.
4. Copy files from snapshot.
5. Unmount snapshot.
`BACKUP TABLE' Syntax
---------------------
BACKUP TABLE tbl_name[,tbl_name...] TO '/path/to/backup/directory'
copies
`.frm' (definition) and `.MYD' (data) files. The index file can be
rebuilt from those two.
Before using this command, please see *Note Backup::.
a read lock for
each table in the group.
The command returns a table with the following columns:
*Column* *Value*
Table Table name
Op Always `backup'
Msg_type One of `status', `error',
`info', or `warning'
Msg_text The message
Note that `BACKUP TABLE' is only available in MySQL version 3.23.25 and
later.
`RESTORE TABLE' Syntax
----------------------
RESTORE TABLE tbl_name[,tbl_name...] FROM '/path/to/backup/directory'
Restores the table(s) from the backup that was made with `BACKUP
TABLE'. Existing tables will not be overwritten; if you try to restore
over an existing table, you will get an error. Restoring will take
longer than backing up due to the need to rebuild the index. The more
keys you have, the longer it will take. Just as `BACKUP TABLE',
`RESTORE TABLE' currently works only for `MyISAM' tables.
The command returns a table with the following columns:
*Column* *Value*
Table Table name
Op Always `restore'
Msg_type One of `status', `error',
`info', or `warning'
Msg_text The message
`CHECK TABLE' Syntax
--------------------
CHECK TABLE tbl_name[,tbl_name...] [option [option...]]
option = QUICK | FAST | MEDIUM | EXTENDED | CHANGED
`CHECK TABLE' works only on `MyISAM' and `InnoDB' tables. On `MyISAM'
tables, it's the same thing as running `myisamchk --medium-check
table_name' on the table.
If you don't specify any option, `MEDIUM' is used.
Checks the table or tables for errors. For `MyISAM' tables, the key
statistics are updated. The command returns a table with the following
columns:
*Column* *Value*
Table Table name
Op Always `check'
Msg_type One of `status', `error',
`info', or `warning'
Msg_text The message
up to
date' you should normally run a repair of the table. *Note Table
maintenance::. `Table is already up to date' means that the storage
manager for the table indicated that there was no need to check the
table.
The different check types are as follows:
since the last
check or haven't been closed properly.
`MEDIUM' Scan rows to verify that deleted links are okay. This also
calculates a key checksum for the rows and verifies this
with a calculated checksum for the keys.
`EXTENDED' Do a full key lookup for all keys for each row. This
ensures that the table is 100% consistent, but will take a
long time!
For dynamically sized `MyISAM' tables, a started check will always do a
`MEDIUM' check. For statically sized rows, we skip the row scan for
`QUICK' and `FAST' as the rows are very seldom corrupted.
You can combine check options, as in the following example that does a
quick check on the table to see whether it was closed properly:
CHECK TABLE test_table FAST QUICK;
*Note*: that in some cases `CHECK TABLE' will change the table! This
happens if the table is marked as 'corrupted' or 'not closed properly'
but `CHECK TABLE' didn't find any problems in the table. In this case,
`CHECK TABLE' will mark the table as okay.
If a table is corrupted, then it's most likely that the problem is in
the indexes and not in the data part. All of the above check types
checks the indexes thoroughly and should thus find most errors.
If you just want to check a table that you assume is okay, you should
use no check options or the `QUICK' option. The latter should be used
when you are in a hurry and can take the very small risk that `QUICK'
didn't find an error in the datafile. (In most cases MySQL should find,
under normal usage, any error in the datafile. If this happens then
the table will be marked as 'corrupted', in which case the table can't
be used until it's repaired.)
`FAST' and `CHANGED' are mostly intended to be used from a script (for
example to be executed from `cron') if you want to check your table
from time to time. In most cases, `FAST' is to be prefered over
`CHANGED'. (The only case when it isn't is when you suspect that you
have found a bug in the `MyISAM' code.)
`EXTENDED' is only to be used after you have run a normal check but
still get strange errors from a table when MySQL tries to update a row
or find a row by key (this is very unlikely if a normal check has
succeeded!).
Some things reported by `CHECK TABLE' can't be corrected automatically:
* `Found row where the auto_increment column has the value 0'.
This means that you have a row in the table where the
`AUTO_INCREMENT' index column contains the value 0. (It's
possible to create a row where the `AUTO_INCREMENT' column is 0 by
explicitly setting the column to 0 with an `UPDATE' statement.)
This isn't an error in itself, but could cause trouble if you
decide to dump the table and restore it or do an `ALTER TABLE' on
the table. In this case, the `AUTO_INCREMENT' column will change
value, according to the rules of `AUTO_INCREMENT' columns, which
could cause problems such as a duplicate key error.
To get rid of the warning, just execute an `UPDATE' statement to
set the column to some other value than 0.
`REPAIR TABLE' Syntax
---------------------
REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name...] [QUICK] [EXTENDED] [USE_FRM]
`REPAIR TABLE' works only on `MyISAM' tables and is the same as running
`myisamchk -r table_name' on the table.
Normally you should never have to run this command, but if disaster
strikes you are very likely to get back all your data from a MyISAM
table with `REPAIR TABLE'. If your tables get corrupted a lot, you
should try to find the reason for it, to eliminate the need to use
`REPAIR TABLE'. *Note Crashing::. *Note MyISAM table problems::.
`REPAIR TABLE' repairs a possibly corrupted table. The command returns a
table with the following columns:
*Column* *Value*
Table Table name
Op Always `repair'
Msg_type One of `status', `error',
`info', or `warning'
Msg_text The message
repairing the table with `myisamchk --safe-recover', as `REPAIR TABLE'
does not yet implement all the options of `myisamchk'. In the near
future, we will make it more flexible.
If `QUICK' is given, `REPAIR TABLE' tries to repair only the index tree.
compress
very well. This type of repair is like that done by `myisamchk
--safe-recover'.
As of `MySQL' 4.0.2, there is a `USE_FRM' mode for `REPAIR'. Use it if
the `.MYI' file is missing or if its header is corrupted. In this mode
MySQL will recreate the table, using information from the `.frm' file.
This kind of repair cannot be done with `myisamchk'.
*Warning:* If `mysqld' dies during a `REPAIR TABLE', it's essential
that you do at once another `REPAIR' on the table before executing any
other commands on it. (It's of course always good to start with a
backup). In the worst case you can have a new clean index file without
information about the datafile and when the next command you do may
overwrite the datafile. This is not a likely, but possible scenario.
used.
Using `myisamchk' for Table Maintenance and Crash Recovery
----------------------------------------------------------
To check/repair MyISAM tables (`.MYI' and `.MYD') you should use the
`myisamchk' utility. To check/repair ISAM tables (`.ISM' and `.ISD')
you should use the `isamchk' utility. *Note Table types::.
In the following text we will talk about `myisamchk', but everything
also applies to the old `isamchk'.
of
its options), how to set up a table maintenance schedule, and how to
use `myisamchk' to perform its various functions.
TABLE' is easier to use and you don't have to worry about flushing
tables. *Note `OPTIMIZE TABLE': OPTIMIZE TABLE.
Even though the repair in `myisamchk' is quite secure, it's always a
good idea to make a backup _before_ doing a repair (or anything that
could make a lot of changes to a table)
`myisamchk' Invocation Syntax
.............................
`myisamchk' is invoked like this:
shell> myisamchk [options] tbl_name
table. To get more information or to tell `myisamchk' to take
corrective action, specify options as described here and in the
following sections.
`tbl_name' is the database table you want to check/repair. If you run
`myisamchk' somewhere other than in the database directory, you must
specify the path to the file, because `myisamchk' has no idea where your
database is located. Actually, `myisamchk' doesn't care whether the
files you are working on are located in a database directory; you can
copy the files that correspond to a database table into another
location and perform recovery operations on them there.
You can name several tables on the `myisamchk' command-line if you
wish. You can also specify a name as an index file name (with the
`.MYI' suffix), which allows you to specify all tables in a directory
by using the pattern `*.MYI'. For example, if you are in a database
directory, you can check all the tables in the directory like this:
shell> myisamchk *.MYI
If you are not in the database directory, you can check all the tables
there by specifying the path to the directory:
shell> myisamchk /path/to/database_dir/*.MYI
You can even check all tables in all databases by specifying a wildcard
with the path to the MySQL data directory:
shell> myisamchk /path/to/datadir/*/*.MYI
The recommended way to quickly check all tables is:
myisamchk --silent --fast /path/to/datadir/*/*.MYI
isamchk --silent /path/to/datadir/*/*.ISM
If you want to check all tables and repair all tables that are
corrupted, you can use the following line:
myisamchk --silent --force --fast --update-state -O key_buffer=64M \
-O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M \
/path/to/datadir/*/*.MYI
isamchk --silent --force -O key_buffer=64M -O sort_buffer=64M \
-O read_buffer=1M -O write_buffer=1M /path/to/datadir/*/*.ISM
The above assumes that you have more than 64 M free.
Note that if you get an error like:
myisamchk: warning: 1 clients is using or hasn't closed the table properly
If `mysqld' is running, you must force a sync/close of all tables with
`FLUSH TABLES' and ensure that no one is using the tables while you are
running `myisamchk'. In MySQL Version 3.23 the easiest way to avoid
this problem is to use `CHECK TABLE' instead of `myisamchk' to check
tables.
General Options for `myisamchk'
...............................
`myisamchk' supports the following options.
`-# or --debug=debug_options'
Output debug log. The `debug_options' string often is
`'d:t:o,filename''.
`-? or --help'
Display a help message and exit.
`-O var=option, --set-variable var=option'
Set the value of a variable. Please note that `--set-variable' is
deprecated since MySQL 4.0, just use `--var=option' on its own.
The possible variables and their default values for myisamchk can
be examined with `myisamchk --help':
*Variable* *Value*
key_buffer_size523264
read_buffer_size262136
write_buffer_size262136
sort_buffer_size2097144
sort_key_blocks16
decode_bits 9
`sort_buffer_size' is used when the keys are repaired by sorting
keys, which is the normal case when you use `--recover'.
`key_buffer_size' is used when you are checking the table with
`--extended-check' or when the keys are repaired by inserting key
row by row in to the table (like when doing normal inserts).
Repairing through the key buffer is used in the following cases:
* If you use `--safe-recover'.
* If the temporary files needed to sort the keys would be more
than twice as big as when creating the key file directly.
This is often the case when you have big `CHAR', `VARCHAR' or
`TEXT' keys as the sort needs to store the whole keys during
sorting. If you have lots of temporary space and you can
force `myisamchk' to repair by sorting you can use the
`--sort-recover' option.
Reparing through the key buffer takes much less disk space than
using sorting, but is also much slower.
If you want a faster repair, set the above variables to about 1/4
of your available memory. You can set both variables to big
values, as only one of the above buffers will be used at a time.
`-s or --silent'
Silent mode. Write output only when errors occur. You can use `-s'
twice (`-ss') to make `myisamchk' very silent.
`-v or --verbose'
Verbose mode. Print more information. This can be used with `-d'
and `-e'. Use `-v' multiple times (`-vv', `-vvv') for more
verbosity!
`-V or --version'
Print the `myisamchk' version and exit.
the table
can only be locked by another `myisamchk' command.
Check Options for `myisamchk'
.............................
`-c or --check'
Check table for errors. This is the default operation if you are
not giving `myisamchk' any options that override this.
`-e or --extend-check'
Check the table very thoroughly (which is quite slow if you have
many indexes). This option should only be used in extreme cases.
Normally, `myisamchk' or `myisamchk --medium-check' should, in most
cases, be able to find out if there are any errors in the table.
If you are using `--extended-check' and have much memory, you
should increase the value of `key_buffer_size' a lot!
`-F or --fast'
Check only tables that haven't been closed properly.
`-C or --check-only-changed'
Check only tables that have changed since the last check.
`-f or --force'
Restart `myisamchk' with `-r' (repair) on the table, if
`myisamchk' finds any errors in the table.
`-i or --information'
Print informational statistics about the table that is checked.
`-m or --medium-check'
Faster than extended-check, but only finds 99.99% of all errors.
Should, however, be good enough for most cases.
`-U or --update-state'
Store in the `.MYI' file when the table was checked and if the
table crashed. This should be used to get full benefit of the
`--check-only-changed' option, but you shouldn't use this option
if the `mysqld' server is using the table and you are running
`mysqld' with `--skip-external-locking'.
`-T or --read-only'
Don't mark table as checked. This is useful if you use `myisamchk'
to check a table that is in use by some other application that
doesn't use locking (like `mysqld --skip-external-locking').
Repair Options for myisamchk
............................
The following options are used if you start `myisamchk' with `-r' or
`-o':
`-B or --backup'
Make a backup of the `.MYD' file as `filename-time.BAK'
`--correct-checksum'
Correct checksum information for table.
`-D # or --data-file-length=#'
Max length of datafile (when re-creating datafile when it's
'full').
`-e or --extend-check'
Try to recover every possible row from the datafile. Normally
this will also find a lot of garbage rows. Don't use this option
if you are not totally desperate.
`-f or --force'
Overwrite old temporary files (`table_name.TMD') instead of
aborting.
`-k # or --keys-used=#'
If you are using `ISAM', tells the `ISAM' storage engine to update
only the first `#' indexes. If you are using `MyISAM', tells
which keys to use, where each binary bit stands for one key (first
key is bit 0). This can be used to get faster inserts!
Deactivated indexes can be reactivated by using `myisamchk -r'.
`-l or --no-symlinks'
Do not follow symbolic links. Normally `myisamchk' repairs the
table a symlink points at. This option doesn't exist in MySQL 4.0,
as MySQL 4.0 will not remove symlinks during repair.
code. Use at your own risk!*
`-r or --recover'
Can fix almost anything except unique keys that aren't unique
(which is an extremely unlikely error with `ISAM'/`MyISAM' tables).
If you want to recover a table, this is the option to try first.
Only if `myisamchk' reports that the table can't be recovered by
`-r', you should then try `-o'. (Note that in the unlikely case
that `-r' fails, the datafile is still intact.) If you have lots
of memory, you should increase the size of `sort_buffer_size'!
`-o or --safe-recover'
Uses an old recovery method (reads through all rows in order and
updates all index trees based on the found rows); this is an order
of magnitude slower than `-r', but can handle a couple of very
unlikely cases that `-r' cannot handle. This recovery method also
uses much less disk space than `-r'. Normally one should always
first repair with `-r', and only if this fails use `-o'.
If you have lots of memory, you should increase the size of
`key_buffer_size'!
`-n or --sort-recover'
Force `myisamchk' to use sorting to resolve the keys even if the
temporary files should be very big.
`--character-sets-dir=...'
Directory where character sets are stored.
`--set-character-set=name'
Change the character set used by the index
`-t or --tmpdir=path'
Path for storing temporary files. If this is not set, `myisamchk'
will use the environment variable `TMPDIR' for this. Starting
from MySQL 4.1, `tmpdir' can be set to a list of paths separated
by colon `:' (semicolon `;' on Windows). They will be used in
round-robin fashion.
`-q or --quick'
Faster repair by not modifying the datafile. One can give a second
`-q' to force `myisamchk' to modify the original datafile in case
of duplicate keys
`-u or --unpack'
Unpack file packed with myisampack.
Other Options for `myisamchk'
.............................
Other actions that `myisamchk' can do, besides repair and check tables:
it should use: `myisamchk
--describe --verbose table_name'' or using `SHOW KEYS' in MySQL.
`-d or --description'
Prints some information about table.
`-A or --set-auto-increment[=value]'
Force `AUTO_INCREMENT' to start at this or higher value. If no
value is given, then sets the next `AUTO_INCREMENT' value to the
highest used value for the auto key + 1.
`-S or --sort-index'
Sort the index tree blocks in high-low order. This will optimise
seeks and will make table scanning by key faster.
`-R or --sort-records=#'
Sorts records according to an index. This makes your data much
more localised and may speed up ranged `SELECT' and `ORDER BY'
operations on this index. (It may be very slow to do a sort the
first time!) To find out a table's index numbers, use `SHOW
INDEX', which shows a table's indexes in the same order that
`myisamchk' sees them. Indexes are numbered beginning with 1.
`myisamchk' Memory Usage
........................
Memory allocation is important when you run `myisamchk'. `myisamchk'
uses no more memory than you specify with the `-O' options. If you are
going to use `myisamchk' on very large files, you should first decide
how much memory you want it to use. The default is to use only about
3M to fix things. By using larger values, you can get `myisamchk' to
operate faster. For example, if you have more than 32M RAM, you could
use options such as these (in addition to any other options you might
specify):
shell> myisamchk -O sort=16M -O key=16M -O read=1M -O write=1M ...
Using `-O sort=16M' should probably be enough for most cases.
with more
space and restart `myisamchk'.
When repairing, `myisamchk' will also need a lot of disk space:
space
is needed on the same disk as the original record file!
* Space for the new index file that replaces the old one. The old
index file is truncated at start, so one usually ignore this space.
This space is needed on the same disk as the original index file!
* When using `--recover' or `--sort-recover' (but not when using
`--safe-recover'), you will need space for a sort buffer for:
`(largest_key + row_pointer_length)*number_of_rows * 2'. You can
check the length of the keys and the row_pointer_length with
`myisamchk -dv table'. This space is allocated on the temporary
disk (specified by `TMPDIR' or `--tmpdir=#').
If you have a problem with disk space during repair, you can try to use
`--safe-recover' instead of `--recover'.
Using `myisamchk' for Crash Recovery
....................................
If you run `mysqld' with `--skip-external-locking' (which is the
default on some systems, like Linux), you can't reliably use `myisamchk'
to check a table when `mysqld' is using the same table. If you can be
sure that no one is accessing the tables through `mysqld' while you run
`myisamchk', you only have to do `mysqladmin flush-tables' before you
start checking the tables. If you can't guarantee the above, then you
must take down `mysqld' while you check the tables. If you run
`myisamchk' while `mysqld' is updating the tables, you may get a
warning that a table is corrupt even if it isn't.
If you are not using `--skip-external-locking', you can use `myisamchk'
to check tables at any time. While you do this, all clients that try
to update the table will wait until `myisamchk' is ready before
continuing.
If you use `myisamchk' to repair or optimise tables, you *must* always
ensure that the `mysqld' server is not using the table (this also
applies if you are using `--skip-external-locking'). If you don't take
down `mysqld' you should at least do a `mysqladmin flush-tables' before
you run `myisamchk'. Your tables *may be corrupted* if the server and
`myisamchk' access the tables simultaneously.
This chapter describes how to check for and deal with data corruption
in MySQL databases. If your tables get corrupted frequently you should
try to find the reason for this! *Note Crashing::.
The `MyISAM' table section contains reason for why a table could be
corrupted. *Note MyISAM table problems::.
When performing crash recovery, it is important to understand that each
table `tbl_name' in a database corresponds to three files in the
database directory:
*File* *Purpose*
`tbl_name.frm' Table definition
(form) file
`tbl_name.MYD' Datafile
`tbl_name.MYI' Index file
Each of these three file types is subject to corruption in various
ways, but problems occur most often in datafiles and index files.
`myisamchk' works by creating a copy of the `.MYD' (data) file row by
row. It ends the repair stage by removing the old `.MYD' file and
renaming the new file to the original file name. If you use `--quick',
`myisamchk' does not create a temporary `.MYD' file, but instead
assumes that the `.MYD' file is correct and only generates a new index
file without touching the `.MYD' file. This is safe, because
`myisamchk' automatically detects if the `.MYD' file is corrupt and
aborts the repair in this case. You can also give two `--quick'
options to `myisamchk'. In this case, `myisamchk' does not abort on
some errors (like duplicate key) but instead tries to resolve them by
modifying the `.MYD' file. Normally the use of two `--quick' options is
useful only if you have too little free disk space to perform a normal
repair. In this case you should at least make a backup before running
`myisamchk'.
How to Check Tables for Errors
..............................
To check a MyISAM table, use the following commands:
`myisamchk tbl_name'
This finds 99.99% of all errors. What it can't find is corruption
that involves *only* the datafile (which is very unusual). If you
want to check a table, you should normally run `myisamchk' without
options or with either the `-s' or `--silent' option.
`myisamchk -m tbl_name'
This finds 99.999% of all errors. It checks first all index
entries for errors and then it reads through all rows. It
calculates a checksum for all keys in the rows and verifies that
they checksum matches the checksum for the keys in the index tree.
`myisamchk -e tbl_name'
This does a complete and thorough check of all data (`-e' means
"extended check"). It does a check-read of every key for each row
to verify that they indeed point to the correct row. This may
take a long time on a big table with many keys. `myisamchk' will
normally stop after the first error it finds. If you want to
obtain more information, you can add the `--verbose' (`-v')
option. This causes `myisamchk' to keep going, up through a
maximum of 20 errors. In normal usage, a simple `myisamchk' (with
no arguments other than the table name) is sufficient.
`myisamchk -e -i tbl_name'
Like the previous command, but the `-i' option tells `myisamchk' to
print some informational statistics, too.
How to Repair Tables
....................
In the following section we only talk about using `myisamchk' on
`MyISAM' tables (extensions `.MYI' and `.MYD'). If you are using
`ISAM' tables (extensions `.ISM' and `.ISD'), you should use `isamchk'
instead.
Starting with MySQL Version 3.23.14, you can repair MyISAM tables with
the `REPAIR TABLE' command. *Note REPAIR TABLE::.
The symptoms of a corrupted table include queries that abort
unexpectedly and observable errors such as these:
* `tbl_name.frm' is locked against change
* Can't find file `tbl_name.MYI' (Errcode: ###)
* Unexpected end of file
* Record file is crashed
* Got error ### from table handler
To get more information about the error you can run `perror ###'.
Here is the most common errors that indicates a problem with the
table:
shell> perror 126 127 132 134 135 136 141 144 145
126 = Index file is crashed / Wrong file format
127 = Record-file is crashed
132 = Old database file
134 = Record was already deleted (or record file crashed)
135 = No more room in record file
136 = No more room in index file
141 = Duplicate unique key or constraint on write or update
144 = Table is crashed and last repair failed
145 = Table was marked as crashed and should be repaired
Note that error 135 (no more room in record file), is not an error
that can be fixed by a simple repair. In this case you have to do:
ALTER TABLE table MAX_ROWS=xxx AVG_ROW_LENGTH=yyy;
You can also use this technique for error 136 (no more room in
index file).
In the other cases, you must repair your tables. `myisamchk' can
usually detect and fix most things that go wrong.
The repair process involves up to four stages, described here. Before
you begin, you should `cd' to the database directory and check the
permissions of the table files. Make sure they are readable by the Unix
user that `mysqld' runs as (and to you, because you need to access the
files you are checking). If it turns out you need to modify files,
they must also be writable by you.
If you are using MySQL Version 3.23.16 and above, you can (and should)
use the `CHECK' and `REPAIR' commands to check and repair `MyISAM'
tables. *Note CHECK TABLE::. *Note REPAIR TABLE::.
The manual section about table maintenance includes the options to
`isamchk'/`myisamchk'. *Note Table maintenance::.
The following section is for the cases where the above command fails or
if you want to use the extended features that `isamchk'/`myisamchk'
provides.
If you are going to repair a table from the command-line, you must first
take down the `mysqld' server. Note that when you do `mysqladmin
shutdown' on a remote server, the `mysqld' server will still be alive
for a while after `mysqladmin' returns, until all queries are stopped
and all keys have been flushed to disk.
*Stage 1: Checking your tables*
Run `myisamchk *.MYI' or `myisamchk -e *.MYI' if you have more time.
Use the `-s' (silent) option to suppress unnecessary information.
If the `mysqld' server is done you should use the -update option to tell
`myisamchk' to mark the table as 'checked'.
You have to repair only those tables for which `myisamchk' announces an
error. For such tables, proceed to Stage 2.
If you get weird errors when checking (such as `out of memory' errors),
or if `myisamchk' crashes, go to Stage 3.
*Stage 2: Easy safe repair*
Note: If you want repairing to go much faster, you should add: `-O
sort_buffer=# -O key_buffer=#' (where # is about 1/4 of the available
memory) to all `isamchk/myisamchk' commands.
and the
delete links point at the correct locations within the datafile, this
should work, and the table is fixed. Start repairing the next table.
Otherwise, use the following procedure:
1. Make a backup of the datafile before continuing.
2. Use `myisamchk -r tbl_name' (`-r' means "recovery mode"). This will
remove incorrect records and deleted records from the datafile and
reconstruct the index file.
3. If the preceding step fails, use `myisamchk --safe-recover
tbl_name'. Safe recovery mode uses an old recovery method that
handles a few cases that regular recovery mode doesn't (but is
slower).
If you get weird errors when repairing (such as `out of memory'
errors), or if `myisamchk' crashes, go to Stage 3.
*Stage 3: Difficult repair*
You should only reach this stage if the first 16K block in the index
file is destroyed or contains incorrect information, or if the index
file is missing. In this case, it's necessary to create a new index
file. Do so as follows:
1. Move the datafile to some safe place.
2. Use the table description file to create new (empty) data and
index files:
shell> mysql db_name
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE table_name;
mysql> quit
If your SQL version doesn't have `TRUNCATE TABLE', use `DELETE FROM
table_name' instead.
3. Copy the old datafile back onto the newly created datafile.
(Don't just move the old file back onto the new file; you want to
retain a copy in case something goes wrong.)
Go back to Stage 2. `myisamchk -r -q' should work now. (This shouldn't
be an endless loop.)
As of `MySQL' 4.0.2 you can also use `REPAIR ... USE_FRM' which
performs the whole procedure automatically.
*Stage 4: Very difficult repair*
You should reach this stage only if the description file has also
crashed. That should never happen, because the description file isn't
changed after the table is created:
1. Restore the description file from a backup and go back to Stage 3.
You can also restore the index file and go back to Stage 2. In
the latter case, you should start with `myisamchk -r'.
2. If you don't have a backup but know exactly how the table was
created, create a copy of the table in another database. Remove
the new datafile, then move the description and index files from
the other database to your crashed database. This gives you new
description and index files, but leaves the datafile alone. Go
back to Stage 2 and attempt to reconstruct the index file.
Table Optimisation
..................
To coalesce fragmented records and eliminate wasted space resulting from
deleting or updating records, run `myisamchk' in recovery mode:
shell> myisamchk -r tbl_name
You can optimise a table in the same way using the SQL `OPTIMIZE TABLE'
statement. `OPTIMIZE TABLE' does a repair of the table and a key
analysis, and also sorts the index tree to give faster key lookups.
There is also no possibility of unwanted interaction between a utility
and the server, because the server does all the work when you use
`OPTIMIZE TABLE'. *Note OPTIMIZE TABLE::.
`myisamchk' also has a number of other options you can use to improve
the performance of a table:
* `-S', `--sort-index'
* `-R index_num', `--sort-records=index_num'
* `-a', `--analyze'
For a full description of the option. *Note myisamchk syntax::.
Setting Up a Table Maintenance Regimen
--------------------------------------
Starting with MySQL Version 3.23.13, you can check MyISAM tables with
the `CHECK TABLE' command. *Note CHECK TABLE::. You can repair tables
with the `REPAIR TABLE' command. *Note REPAIR TABLE::.
It is a good idea to perform table checks on a regular basis rather than
waiting for problems to occur. For maintenance purposes, you can use
`myisamchk -s' to check tables. The `-s' option (short for `--silent')
causes `myisamchk' to run in silent mode, printing messages only when
errors occur.
It's also a good idea to check tables when the server starts up. For
example, whenever the machine has done a reboot in the middle of an
update, you usually need to check all the tables that could have been
affected. (This is an "expected crashed table".) You could add a test to
`mysqld_safe' that runs `myisamchk' to check all tables that have been
modified during the last 24 hours if there is an old `.pid' (process
ID) file left after a reboot. (The `.pid' file is created by `mysqld'
when it starts up and removed when it terminates normally. The
presence of a `.pid' file at system startup time indicates that
`mysqld' terminated abnormally.)
An even better test would be to check any table whose last-modified time
is more recent than that of the `.pid' file.
You should also check your tables regularly during normal system
operation. At MySQL AB, we run a `cron' job to check all our important
tables once a week, using a line like this in a `crontab' file:
35 0 * * 0 /path/to/myisamchk --fast --silent /path/to/datadir/*/*.MYI
This prints out information about crashed tables so we can examine and
repair them when needed.
for us.
We recommend that to start with, you execute `myisamchk -s' each night
on all tables that have been updated during the last 24 hours, until
you come to trust MySQL as much as we do.
Normally you don't need to maintain MySQL tables that much. If you are
changing tables with dynamic size rows (tables with `VARCHAR', `BLOB'
or `TEXT' columns) or have tables with many deleted rows you may want
to from time to time (once a month?) defragment/reclaim space from the
tables.
You can do this by using `OPTIMIZE TABLE' on the tables in question or
if you can take down the `mysqld' server for a while do:
isamchk -r --silent --sort-index -O sort_buffer_size=16M */*.ISM
myisamchk -r --silent --sort-index -O sort_buffer_size=16M */*.MYI
Getting Information About a Table
---------------------------------
To get a description of a table or statistics about it, use the
commands shown here. We explain some of the information in more detail
later:
report
an error for a table that is updated while it runs. However,
because `myisamchk' doesn't change the table in describe mode,
there isn't any risk of destroying data.
* myisamchk -d -v tbl_name To produce more information about what
`myisamchk' is doing, add `-v' to tell it to run in verbose mode.
* myisamchk -eis tbl_name Shows only the most important information
from a table. It is slow because it must read the whole table.
* myisamchk -eiv tbl_name This is like `-eis', but tells you what is
being done.
Example of `myisamchk -d' output:
MyISAM file: company.MYI
Record format: Fixed length
Data records: 1403698 Deleted blocks: 0
Recordlength: 226
packed stripped
5 167 2 multip. unsigned short
6 177 4 multip. unsigned long
7 155 4 multip. text
8 138 4 multip. unsigned long
9 177 4 multip. unsigned long
193 1 text
Example of `myisamchk -d -v' output:
MyISAM file: company
Record format: Fixed length
File-version: 1
Creation time: 1999-10-30 12:12:51
Recover time: 1999-10-31 19:13:01
Status: checked
Data records: 1403698 Deleted blocks: 0
Datafile parts: 1403698 Deleted data: 0
Datafilepointer (bytes): 3 Keyfile pointer (bytes): 3
Max datafile length: 3791650815 Max keyfile length: 4294967294
Recordlength: 226
table description:
Key Start Len Index Type Rec/key Root Blocksize
1 2 8 unique double 1 15845376 1024
2 15 10 multip. text packed stripped 2 25062400 1024
3 219 8 multip. double 73 40907776 1024
4 63 10 multip. text packed stripped 5 48097280 1024
5 167 2 multip. unsigned short 4840 55200768 1024
6 177 4 multip. unsigned long 1346 65145856 1024
7 155 4 multip. text 4995 75090944 1024
8 138 4 multip. unsigned long 87 85036032 1024
9 177 4 multip. unsigned long 178 96481280 1024
193 1 text
Example of `myisamchk -eis' output:
Checking MyISAM file: company
Key: 1: Keyblocks used: 97% Packed: 0% Max levels: 4
Key: 2: Keyblocks used: 98% Packed: 50% Max levels: 4
Key: 3: Keyblocks used: 97% Packed: 0% Max levels: 4
Key: 4: Keyblocks used: 99% Packed: 60% Max levels: 3
Key: 5: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 6: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 7: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 8: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 9: Keyblocks used: 98% Packed: 0% Max levels: 4
Total: Keyblocks used: 98% Packed: 17%
Records: 1403698 M.recordlength: 226
Packed: 0%
Recordspace used: 100% Empty space: 0%
Blocks/Record: 1.00
Record blocks: 1403698 Delete blocks: 0
Recorddata: 317235748 Deleted data: 0
Lost space: 0 Linkdata: 0
User time 1626.51, System time 232.36
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 627, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 639, Involuntary context switches 28966
Example of `myisamchk -eiv' output:
Checking MyISAM file: company
Data records: 1403698 Deleted blocks: 0
- check file-size
- check delete-chain
block_size 1024:
index 1:
index 2:
index 3:
index 4:
index 5:
index 6:
index 7:
index 8:
index 9:
No recordlinks
- check index reference
- check data record references index: 1
Key: 1: Keyblocks used: 97% Packed: 0% Max levels: 4
- check data record references index: 2
Key: 2: Keyblocks used: 98% Packed: 50% Max levels: 4
- check data record references index: 3
Key: 3: Keyblocks used: 97% Packed: 0% Max levels: 4
- check data record references index: 4
Key: 4: Keyblocks used: 99% Packed: 60% Max levels: 3
- check data record references index: 5
Key: 5: Keyblocks used: 99% Packed: 0% Max levels: 3
- check data record references index: 6
Key: 6: Keyblocks used: 99% Packed: 0% Max levels: 3
- check data record references index: 7
Key: 7: Keyblocks used: 99% Packed: 0% Max levels: 3
- check data record references index: 8
Key: 8: Keyblocks used: 99% Packed: 0% Max levels: 3
- check data record references index: 9
Key: 9: Keyblocks used: 98% Packed: 0% Max levels: 4
Total: Keyblocks used: 9% Packed: 17%
- check records and index references
[LOTS OF ROW NUMBERS DELETED]
Records: 1403698 M.recordlength: 226 Packed: 0%
Recordspace used: 100% Empty space: 0% Blocks/Record: 1.00
Record blocks: 1403698 Delete blocks: 0
Recorddata: 317235748 Deleted data: 0
Lost space: 0 Linkdata: 0
User time 1639.63, System time 251.61
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 10580, Swaps 0
Blocks in 4 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 10604, Involuntary context switches 122798
Here are the sizes of the data and index files for the table used in the
preceding examples:
-rw-rw-r-- 1 monty tcx 317235748 Jan 12 17:30 company.MYD
-rw-rw-r-- 1 davida tcx 96482304 Jan 12 18:35 company.MYM
Explanations for the types of information `myisamchk' produces are
given here. The "keyfile" is the index file. "Record" and "row" are
synonymous:
* ISAM file Name of the ISAM (index) file.
* Isam-version Version of ISAM format. Currently always 2.
* Creation time When the datafile was created.
* Recover time When the index/datafile was last reconstructed.
* Data records How many records are in the table.
* Deleted blocks How many deleted blocks still have reserved space.
You can optimise your table to minimise this space. *Note
Optimisation::.
* Data file: Parts For dynamic record format, this indicates how
many data blocks there are. For an optimised table without
fragmented records, this is the same as `Data records'.
* Deleted data How many bytes of non-reclaimed deleted data there
are. You can optimise your table to minimise this space. *Note
Optimisation::.
* Data file pointer The size of the datafile pointer, in bytes. It
is usually 2, 3, 4, or 5 bytes. Most tables manage with 2 bytes,
but this cannot be controlled from MySQL yet. For fixed tables,
this is a record address. For dynamic tables, this is a byte
address.
* Keyfile pointer The size of the index file pointer, in bytes. It
is usually 1, 2, or 3 bytes. Most tables manage with 2 bytes, but
this is calculated automatically by MySQL. It is always a block
address.
* Max datafile length How long the table's datafile (`.MYD' file)
can become, in bytes.
* Max keyfile length How long the table's key file (`.MYI' file) can
become, in bytes.
* Recordlength How much space each record takes, in bytes.
* Record format The format used to store table rows. The preceding
examples use `Fixed length'. Other possible values are
`Compressed' and `Packed'.
* table description A list of all keys in the table. For each key,
some low-level information is presented:
- Key This key's number.
- Start Where in the record this index part starts.
- Len How long this index part is. For packed numbers, this
should always be the full length of the column. For strings,
it may be shorter than the full length of the indexed column,
because you can index a prefix of a string column.
- Index `unique' or `multip.' (multiple). Indicates whether one
value can exist multiple times in this index.
- Type What data-type this index part has. This is an ISAM
data-type with the options `packed', `stripped' or `empty'.
- Root Address of the root index block.
- Blocksize The size of each index block. By default this is
1024, but the value may be changed at compile time.
after
a table is loaded (or greatly changed) with `myisamchk -a'.
If this is not updated at all, a default value of 30 is given.
* In the first example above, the 9th key is a multi-part key with
two parts.
maximum).
* Packed MySQL tries to pack keys with a common suffix. This can
only be used for `CHAR'/`VARCHAR'/`DECIMAL' keys. For long strings
like names, this can significantly reduce the space used. In the
third example above, the 4th key is 10 characters long and a 60%
reduction in space is achieved.
* Max levels How deep the B-tree for this key is. Large tables with
long keys get high values.
* Records How many rows are in the table.
* M.recordlength The average record length. For tables with
fixed-length records, this is the exact record length.
* Packed MySQL strips spaces from the end of strings. The `Packed'
value indicates the percentage of savings achieved by doing this.
* Recordspace used What percentage of the datafile is used.
* Empty space What percentage of the datafile is unused.
to 1.0 as
possible. If it gets too big, you can reorganise the table with
`myisamchk'. *Note Optimisation::.
* Recordblocks How many blocks (links) are used. For fixed format,
this is the same as the number of records.
* Deleteblocks How many blocks (links) are deleted.
* Recorddata How many bytes in the datafile are used.
* Deleted data How many bytes in the datafile are deleted (unused).
* Lost space If a record is updated to a shorter length, some space
is lost. This is the sum of all such losses, in bytes.
description of what it means.
[Назад] [Содержание] [Вперед]
| Главная |