The following options to mysqld can be used to
change the behavior of MyISAM tables. For
additional information, see Section 5.2.2, “Command Options”.
Set the mode for automatic recovery of crashed
MyISAM tables.
Don't flush key buffers between writes for any
MyISAM table.
Note: If you do this, you
should not access MyISAM tables from
another program (such as from another MySQL server or with
myisamchk) when the tables are in use.
Doing so risks index corruption. Using
--external-locking does not eliminate this
risk.
The following system variables affect the behavior of
MyISAM tables. For additional information, see
Section 5.2.3, “System Variables”.
bulk_insert_buffer_size
The size of the tree cache used in bulk insert optimization. Note: This is a limit per thread!
myisam_max_extra_sort_file_size
Used to help MySQL to decide when to use the slow but safe key cache index creation method. Note: This parameter was given in bytes before MySQL 5.0.6, when it was removed.
myisam_max_sort_file_size
The maximum size of the temporary file that MySQL is allowed
to use while re-creating a MyISAM index
(during REPAIR TABLE, ALTER
TABLE, or LOAD DATA INFILE). If
the file size would be larger than this value, the index is
created using the key cache instead, which is slower. The
value is given in bytes.
myisam_sort_buffer_size
Set the size of the buffer used when recovering tables.
Automatic recovery is activated if you start
mysqld with the
--myisam-recover option. In this case, when the
server opens a MyISAM table, it checks whether
the table is marked as crashed or whether the open count variable
for the table is not 0 and you are running the server with
external locking disabled. If either of these conditions is true,
the following happens:
MySQL Enterprise.
Subscribers to MySQL Network Monitoring and Advisory Service
receive notification if the --myisam-recover
option has not been set. For more information see
http://www.mysql.com/products/enterprise/advisors.html.
The server checks the table for errors.
If the server finds an error, it tries to do a fast table repair (with sorting and without re-creating the data file).
If the repair fails because of an error in the data file (for example, a duplicate-key error), the server tries again, this time re-creating the data file.
If the repair still fails, the server tries once more with the old repair option method (write row by row without sorting). This method should be able to repair any type of error and has low disk space requirements.
If the recovery wouldn't be able to recover all rows from
previously completed statements and you didn't specify
FORCE in the value of the
--myisam-recover option, automatic repair aborts
with an error message in the error log:
Error: Couldn't repair table: test.g00pages
If you specify FORCE, a warning like this is
written instead:
Warning: Found 344 of 354 rows when repairing ./test/g00pages
Note that if the automatic recovery value includes
BACKUP, the recovery process creates files with
names of the form
.
You should have a cron script that
automatically moves these files from the database directories to
backup media.
tbl_name-datetime.BAK

User Comments
Add your own comment.