< Day Day Up > |
This section discusses how to make database backups and how to perform table maintenance. The syntax of the SQL statements described here is given in the MySQL Language Reference . Much of the information here pertains primarily to MyISAM tables. InnoDB backup procedures are given in Section 9.9, "Backing Up and Recovering an InnoDB Database." 4.6.1 Database BackupsBecause MySQL tables are stored as files, it is easy to do a backup. To get a consistent back up, do a LOCK TABLES on the relevant tables, followed by FLUSH TABLES for the tables. You need only a read lock; this allows other clients to continue to query the tables while you are making a copy of the files in the database directory. The FLUSH TABLES statement is needed to ensure that the all active index pages are written to disk before you start the backup. If you want to make an SQL-level backup of a table, you can use SELECT INTO ... OUTFILE or BACKUP TABLE . For SELECT INTO ... OUTFILE , the output file cannot already exist. For BACKUP TABLE , the same is true as of MySQL 3.23.56 and 4.0.12, because this would be a security risk. Another way to back up a database is to use the mysqldump program or the mysqlhotcopy script . See Section 7.8, "The mysqldump Database Backup Program," and Section 7.9, "The mysqlhotcopy Database Backup Program."
If your MySQL server is a slave replication server, then regardless of the backup method you choose, you should also back up the master. info and relay-log.info files when you back up your slave's data. These files are always needed to resume replication after you restore the slave's data. If your slave is subject to replicating LOAD DATA INFILE commands, you should also back up any SQL_LOAD-* files that may exist in the directory specified by the --slave-load-tmpdir option. (This location defaults to the value of the tmpdir variable if not specified.) The slave needs these files to resume replication of any interrupted LOAD DATA INFILE operations. If you have to restore MyISAM tables, try to recover them using REPAIR TABLE or myisamchk -r first. That should work in 99.9% of all cases. If myisamchk fails, try the following procedure. Note that it will work only if you have enabled binary logging by starting MySQL with the --log-bin option; see Section 4.8.4, "The Binary Log."
You can also do selective backups of individual files:
If you have performance problems with your server while making backups, one strategy that can help is to set up replication and perform backups on the slave rather than on the master. See Section 5.1, "Introduction to Replication." If you are using a Veritas filesystem, you can make a backup like this:
4.6.2 Table Maintenance and Crash RecoveryThe following text discusses how to use myisamchk to check or repair MyISAM tables (tables with .MYI and .MYD files). The same concepts apply to using isamchk to check or repair ISAM tables (tables with .ISM and .ISD files). See Chapter 8, "MySQL Storage Engines and Table Types." You can use the myisamchk utility to get information about your database tables or to check, repair, or optimize them. The following sections describe how to invoke myisamchk (including a description of its options), how to set up a table maintenance schedule, and how to use myisamchk to perform its various functions. Even though table repair with myisamchk is quite secure, it's always a good idea to make a backup before doing a repair (or any maintenance operation that could make a lot of changes to a table). myisamchk operations that affect indexes can cause FULLTEXT indexes to be rebuilt with full-text parameters that are incompatible with the values used by the MySQL server. To avoid this, read the instructions in Section 4.6.2.2, "General Options for myisamchk." In many cases, you may find it simpler to do MyISAM table maintenance using the SQL statements that perform operations that myisamchk can do:
These statements were introduced in different versions, but all are available from MySQL 3.23.14 on. The statements can be used directly, or by means of the mysqlcheck client program, which provides a command-line interface to them. One advantage of these statements over myisamchk is that the server does all the work. With myisamchk , you must make sure that the server does not use the tables at the same time. Otherwise , there can be unwanted interaction betweeen myisamchk and the server. 4.6.2.1 myisamchk Invocation SyntaxInvoke myisamchk like this: shell> myisamchk [ options ] tbl_name The options specify what you want myisamchk to do. They are described in the following sections. You can also get a list of options by invoking myisamchk --help . With no options, myisamchk simply checks your table as the default operation. To get more information or to tell myisamchk to take corrective action, specify options as described in the following discussion. tbl_name is the database table you want to check or repair. If you run myisamchk somewhere other than in the database directory, you must specify the path to the database directory, because myisamchk has no idea where the database is located. In fact, myisamchk doesn't actually 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 some other 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 table by naming its index file (the file with the .MYI suffix). This 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 MyISAM tables in that 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 MyISAM and ISAM tables is: shell> myisamchk --silent --fast /path/to/datadir /*/*.MYI shell> isamchk --silent /path/to/datadir /*/*.ISM If you want to check all MyISAM and ISAM tables and repair any that are corrupted, you can use the following commands: shell> 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 shell> isamchk --silent --force -O key_buffer=64M \ -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M \ /path/to/datadir /*/*.ISM These commands assume that you have more than 64MB free. For more information about memory allocation with myisamchk , see Section 4.6.2.6, "myisamchk Memory Usage." You must ensure that no other program is using the tables while you are running myisamchk . Otherwise, when you run myisamchk , it may display the following error message: warning: clients are using or haven't closed the table properly This means that you are trying to check a table that has been updated by another program (such as the mysqld server) that hasn't yet closed the file or that has died without closing the file properly. If mysqld is running, you must force it to flush any table modifications that are still buffered in memory by using FLUSH TABLES . You should then ensure that no one is using the tables while you are running myisamchk . The easiest way to avoid this problem is to use CHECK TABLE instead of myisamchk to check tables. 4.6.2.2 General Options for myisamchkThe options described in this section can be used for any type of table maintenance operation performed by myisamchk . The sections following this one describe options that pertain only to specific operations, such as table checking or repairing.
You can also set the following variables by using -- var_name = value options:
It is also possible to set variables by using -- set-variable = var_name = value or -O var_name = value syntax. However, this syntax is deprecated as of MySQL 4.0. The possible myisamchk variables and their default values can be examined with myisamchk --help : 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 --extend-check or when the keys are repaired by inserting keys row by row into the table (like when doing normal inserts ). Repairing through the key buffer is used in the following cases:
Repairing 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 key_buffer_size and sort_buffer_size variables to about 25% of your available memory. You can set both variables to large values, because only one of them is used at a time. myisam_block_size is the size used for index blocks. It is available as of MySQL 4.0.0. The ft_min_word_len and ft_max_word_len variables are available as of MySQL 4.0.0. ft_stopword_file is available as of MySQL 4.0.19. ft_min_word_len and ft_max_word_len indicate the minimum and maximum word length for FULLTEXT indexes. ft_stopword_file names the stopword file. These need to be set under the following circumstances. If you use myisamchk to perform an operation that modifies table indexes (such as repair or analyze), the FULLTEXT indexes are rebuilt using the default full-text parameter values for minimum and maximum word length and the stopword file unless you specify otherwise. This can result in queries failing. The problem occurs because these parameters are known only by the server. They are not stored in MyISAM index files. To avoid the problem if you have modified the minimum or maximum word length or the stopword file in the server, specify the same ft_min_word_len , ft_max_word_len , and ft_stopword_file values to myisamchk that you use for mysqld . For example, if you have set the minimum word length to 3, you can repair a table with myisamchk like this: shell> myisamchk --recover --ft_min_word_len=3 tbl_name .MYI To ensure that myisamchk and the server use the same values for full-text parameters, you can place each one in both the [mysqld] and [myisamchk] sections of an option file: [mysqld] ft_min_word_len=3 [myisamchk] ft_min_word_len=3 An alternative to using myisamchk is to use the REPAIR TABLE , ANALYZE TABLE , OPTIMIZE TABLE , or ALTER TABLE . These statements are performed by the server, which knows the proper full-text parameter values to use. 4.6.2.3 Check Options for myisamchkmyisamchk supports the following options for table checking operations:
4.6.2.4 Repair Options for myisamchkmyisamchk supports the following options for table repair operations:
4.6.2.5 Other Options for myisamchkmyisamchk supports the following options for actions other than table checks and repairs:
4.6.2.6 myisamchk Memory UsageMemory 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 tables, you should first decide how much memory you want it to use. The default is to use only about 3MB to perform repairs. By using larger values, you can get myisamchk to operate faster. For example, if you have more than 32MB 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. Be aware that myisamchk uses temporary files in TMPDIR . If TMPDIR points to a memory filesystem, you may easily get out of memory errors. If this happens, set TMPDIR to point at some directory located on a filesystem with more space and run myisamchk again. When repairing, myisamchk will also need a lot of disk space:
If you have a problem with disk space during repair, you can try to use --safe-recover instead of --recover . 4.6.2.7 Using myisamchk for Crash RecoveryIf you run mysqld with --skip-external-locking (which is the default on some systems, such as 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 this, then you must stop 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 when 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 optimize 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 become corrupted if the server and myisamchk access the tables simultaneously . This section 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 why. See Section A.4.2, "What to Do If MySQL Keeps Crashing." The MyISAM table section contains reasons for why a table could be corrupted. See Section 8.1.4, "MyISAM Table Problems." When performing crash recovery, it is important to understand that each MyISAM table tbl_name in a database corresponds to three files in the database directory:
Each of these three file types is subject to corruption in various ways, but problems occur most often in data files 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 whether the .MYD file is corrupt and aborts the repair if it is. You can also specify the --quick option twice to myisamchk . In this case, myisamchk does not abort on some errors (such as duplicate-key errors) 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 . 4.6.2.8 How to Check MyISAM Tables for ErrorsTo check a MyISAM table, use the following commands:
In most cases, a simple myisamchk with no arguments other than the table name is sufficient to check a table. 4.6.2.9 How to Repair TablesThe discussion in this section describes how to use myisamchk on MyISAM tables (extensions .MYI and .MYD ). If you are using ISAM tables (extensions .ISM and .ISD ), you should use isamchk instead; the concepts are similar. If you are using MySQL 3.23.16 and above, you can (and should) use the CHECK TABLE and REPAIR TABLE statements to check and repair MyISAM tables. The symptoms of a corrupted table include queries that abort unexpectedly and observable errors such as these:
To get more information about the error you can run perror ### , where ### is the error number. The following example shows how to use perror to find the meanings for the most common error numbers that indicate a problem with a 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) and error 136 (no more room in index file) are not errors that can be fixed by a simple repair. In this case, you have to use ALTER TABLE to increase the MAX_ROWS and AVG_ROW_LENGTH table option values: ALTER TABLE tbl_name MAX_ROWS= xxx AVG_ROW_LENGTH= yyy ; If you don't know the current table option values, use SHOW CREATE TABLE tbl_name . For the other errors, you must repair your tables. myisamchk can usually detect and fix most problems that occur. The repair process involves up to four stages, described here. Before you begin, you should change location to the database directory and check the permissions of the table files. On Unix, make sure that they are readable by the 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. The options that you can use for table maintenance with myisamchk and isamchk are described in several of the earlier subsections of Section 4.6.2, "Table Maintenance and Crash Recovery." The following section is for the cases where the above command fails or if you want to use the extended features that myisamchk and isamchk provide. If you are going to repair a table from the command line, you must first stop 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 down, you should use the --update-state 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 a repair operation to go much faster, you should set the values of the sort_buffer_size and key_buffer_size variables each to about 25% of your available memory when running myisamchk or isamchk . First, try myisamchk -r -q tbl_name ( -r -q means "quick recovery mode"). This will attempt to repair the index file without touching the data file. If the data file contains everything that it should and the delete links point at the correct locations within the data file, this should work, and the table is fixed. Start repairing the next table. Otherwise, use the following procedure:
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 reach this stage only if the first 16KB 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 :
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 TABLE tbl_name USE_FRM , which performs the whole procedure automatically. Stage 4: Very difficult repair You should reach this stage only if the .frm description file has also crashed. That should never happen, because the description file isn't changed after the table is created:
4.6.2.10 Table OptimizationTo 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 optimize a table in the same way by 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 . myisamchk also has a number of other options you can use to improve the performance of a table:
For a full description of the options, see Section 4.6.2.1, "myisamchk Invocation Syntax." 4.6.3 Setting Up a Table Maintenance ScheduleIt is a good idea to perform table checks on a regular basis rather than waiting for problems to occur. One way to check and repair MyISAM tables is with the CHECK TABLE and REPAIR TABLE statements. These are available starting with MySQL 3.23.16. Another way to check tables is to use myisamchk . For maintenance purposes, you can use myisamchk -s . 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. For example, whenever the machine has done a restart in the middle of an update, you usually need to check all the tables that could have been affected. (These are "expected crashed tables.") To check MyISAM tables automatically, start the server with the --myisam-recover option, available as of MySQL 3.23.25. If your server is too old to support this option, 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 restart. (The .pid file is created by mysqld when it starts 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 that we can examine and repair them when needed. Because we haven't had any unexpectedly crashed tables (tables that become corrupted for reasons other than hardware trouble) for a couple of years now (this is really true), once a week is more than enough 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 MySQL tables need little maintenance. If you are changing MyISAM tables with dynamic size rows (tables with VARCHAR , BLOB , or TEXT columns) or have tables with many deleted rows you may want to defragment/ reclaim space from the tables from time to time (once a month?). You can do this by using OPTIMIZE TABLE on the tables in question. Or, if you can stop the mysqld server for a while, change location into the data directory and use this command while the server is stopped: shell> myisamchk -r -s --sort-index -O sort_buffer_size=16M */*.MYI For ISAM tables, the command is similar: shell> isamchk -r -s --sort-index -O sort_buffer_size=16M */*.ISM 4.6.4 Getting Information About a TableTo obtain a description of a table or statistics about it, use the commands shown here. We explain some of the information in more detail later:
Sample output for some of these commands follows. They are based on a table with these data and index file sizes: -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 Example of myisamchk -d output: MyISAM file: company.MYI Record format: Fixed length Data records: 1403698 Deleted blocks: 0 Recordlength: 226 table description: Key Start Len Index Type 1 2 8 unique double 2 15 10 multip. text packed stripped 3 219 8 multip. double 4 63 10 multip. text 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 Datafile pointer (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 Explanations for the types of information myisamchk produces are given here. "Keyfile" refers to the index file. "Record" and "row" are synonymous.
If a table has been compressed with myisampack , myisamchk -d prints additional information about each table column. See Section 7.2, "myisampack, the MySQL Compressed Read-Only Table Generator," for an example of this information and a description of what it means. |
< Day Day Up > |