Managing Backup and Recovery - MySQL...

Managing Backup and RecoverySaturday, 30 January 2010 10:34

Despite the steps you take to secure and protect your databases, events such as powerfailures, natural disasters, and equipment failure can lead to the corruption and loss of data.

As a result, one of the most important steps that you can take to protect your data is to makecertain that you maintain backup copies of your databases in a reliable and safe location.Ensuring that MySQL databases are backed up regularly should be part of any maintenanceroutine.

These backup files will contain the database and table definitions necessary to re-create yourdatabase structure as well as the instructions necessary to repopulate your tables. Using thesebackup files, you can recover your data to the state it was in at the time you performed the lastbackup. Further, you can use the binary log files to recover your data to post-backup currentstate. To summarize, backup and restore process involves:

- Use the mysqldump utility to back up tables in a single database or multiple databases. - Use backup files with mysql monitor to reload databases. - Use binary log files to update the databases after reloading.

Backing up or Exporting Databases Using mysqldump

The mysqldump program is the primary method in MySQL for backing up tables and databasesand it can back up individual databases, tables in those databases, or multiple databases.When you run mysqldump, the utility creates a text file that contains the SQL statementsnecessary to create your database and tables safely and add data to those tables. This file isreferred to as a backup file or dump file.

This section describes the usage of mysqldump utility.

Copying Data Directory

It is possible to back up databases simply by copying the data directory to a backup location.Most installations routinely take disk snapshot backups at various points. This method hasseveral limitations, though. For example, if data is being accessed and updated during filecopy, you might be copying tables that are in an inconsistent state. In addition, file-level

1 / 21


copying may help MyISAM tables but InnoDB tables can be more complicated at file level.

Portability

It is simpler to use mysqldump which saves data as portable text files versus OS-level datadirectory copies.

Using mysqldump

There are three syntax variants of mysqldump where you can backup a single database,several enumerated databases, or all databases managed by MySQL.

Using the single database variant, the backup may be done for chosen tables. As a rule, theoutput of mysqldump is sent to a file with > backupfile.sql.

mysqldump - Syntax

mysqldump [options] dbname [tables] mysqldump [options] --databases [moreoptions] dbname1 [dbname2 ...] mysqldump [options] --all-databases [moreoptions] mysqldump --tab=/path/to/some/dir --opt dbname1 mysqldump - Options

The table lists some useful options that apply to mysqldump command.

mysqldump - Options

--add-drop-table Inserts a DROP TABLE command before every CREATE TABLE ; when tables are read in, existing tables are deleted. This option is part of --opt and holds by default. --add-locks Inserts LOCK TABLE before the first INSERT command and UNLOCK after the last INSERT command; generally speeds up reading in a database; this option is part of --opt and holds by default. However, the option should not be used with InnoDB tables. --all Specifies all the detailed MySQL-specific options in the CREATE TABLE command.

2 / 21


-A --all-databases Saves all databases managed by MySQL; CREATE DATABASE and USE are placed in the backup file. -B --databases Stores several databases. --compatible=name Determines with what database system or standard the backup should be compatible. Allowable settings are ansi, mysql323, mysql40, postgresql, oracle, mssql, db2, maxdb, no_key_options, no_table_options, no_field_options. It is allowed to have more than one key word, separated by commas. --complete-inserts Generates for each data record a separate INSERT command. --create-options Includes all MySQL-specific options in CREATE commands. This option is part of -- opt and holds by default. --default-character-set

=name

Specifies the character set in which the backup file is to be created (by default UTF8). --delayed-inserts Creates INSERT commands with the option DELAYED . -K --disable-keys Inserts ALTER TABLE ... DISABLE KEYS or ... ENABLE KEYS before or after INSERT commands; indexes are thereby not updated until the end of the insertion process, which is faster. -e --extended-insert Generates few INSERT commands with which several records can be inserted simultaneously (more efficient and reduces the size of the backup file). This option is part of --opt and holds by default. -F --flush-logs Updates the logging files before the backup is begun. -f --force Continues even after errors. --hex-blob Outputs the content of binary fields (BLOBs) in hexadecimal format. -x --lock-all-tables Executes LOCK TABLE READ for the entire database. This ensures that during the entire backup no table can be changed. Note that --lock-tables does not offer this protection, but prevents changes only during the time in which a table is locked. At this time another table can be changed. -l --lock-tables Executes a LOCK TABLE READ for every table before the data are read; this ensures that no data can be changed while mysqldump is running. This option is part of -- opt and holds by default. The obvious draw-back is that all write processes are blocked until mysqldump is done, which can take a while with large databases (with InnoDB tables, you should use --single-transaction instead of --lock-tables ). --master-data [=n] Adds a comment at the end of the output containing a CHANGE MASTER command. This command is suitable for replication on a slave system. If n=1 is passed as parameter, then the CHANGE MASTER command is added in a normal fashion (not as a comment), so that it is automatically executed when the backup is restored. This option also activates --lock-all- tables if --single-transaction is not used at the same time. --no-create-db Creates no CREATE DATABASES commands. (These commands are created only if the option --all-databases or --databases is used.) --no-create-info Creates no CREATE TABLE commands, but only the INSERT commands. --no-data Creates no INSERT commands (but only CREATE TABLE commands in order to restore the database schema). --opt Shorthand for the following options: --add-drop-table, --create-options, --add-locks, --disable-keys, --extended-insert, --lock-tables, --quick, --set-charset. In most cases, this is an optimal setting, for which reason it holds by default. If you don't wish this, you must use --skip-opt . -q --quick Outputs results record by record without internal intermediate storage. This option is part of --opt and holds by default. Without this option, first the entire table is moved into RAM and then output; the advantage of --quick is the lower memory requirement; the disadvantage is that the MySQL server is generally blocked for a longer period of time; --quick should definitely be used for very large tables (when the entire table cannot be held in RAM of the local computer). -Q --quote-names Encloses table and column names in single quotes (e.g., 'name' ). --set-charset Changes the active character set at the start of mysqldump output, and at the end, the previously valid character set is restored. This option is part of --opt and holds by default. It can be deactivated with --skip-char-set . --skip-opt Deactivates the default option --opt . --single-transaction Results in all tables being read within a single transaction; this makes sense only when InnoDB tables are used, in which Backup this option ensures that no data are changed during output. This option deactivates --lock-tables .

3 / 21


-T dir --tab=dir Writes the result directly into the specified directory, whereby for each table two files are created, one with the table structure (*.sql ) and the second with the stored data in the format of the command SELECT ... INTO OUTFILE ( *.txt ). -w cnd --where=condition Considers only data records that satisfy the WHERE condition cnd or condition ; the entire option must be placed in quotation marks, e.g., "-wprice>5" or " --where=ID=3" . -X --xml Creates an XML file with the contents of the table (without information on the table structure).

If you are using --tab, then the second file (tablename.txt) contains the contents of the tabledirectly (that is, not in the form of INSERTcommands). This has several advantages: The resulting file is somewhat more compact, and a later importation can be executed significantly more quickly. (However, the operation is more complex, and only a single table can be handled.)

Formatting Options

See Export/Import lesson for formatting options.

The options --fields and --lines should each be set in quotation marks. The following exampleshows how you can pass the double quote itself as a character to the option:

> mysqldump -u root -p --tab /tmp "--fields-enclosed-by="" ...

To reinput the file thus generated (*.txt) with mysqldump, you can use either the program mysqlimport, discussed in the following section, or the SQL command LOAD DATA.

Backing up a Single Database

MySQL allows you to back up all tables in a database or only specific tables in that database.In both cases, you use the mysqldump client utility and you specify the name of the database.When backing up only specific tables, you must specify those table names as well. In thissection, you learn how to perform both types of backups.

Backing up the Entire Database

The first form of the mysqldump command that you examine backs up all the tables in a

4 / 21


database. The database is backed up to a backup file that includes the table definitions and theINSERT statements necessary to repopulate the tables. To use this form of the command, youmust specify the name of the database and the path and filename of the backup file, as shownin the following syntax:

mysqldump >

As you can see, your command includes the mysqldump utility name, followed by the databasename. The path and filename are then introduced by a right arrow (>) that tells the mysqldumputility to send the backed-up definitions and data to the specified file. If you do not include theright arrow and path and filename, the backup output would merely be displayed in yourcommand line.

Here are a number of examples of mysqldump.

Code Sample:

mysqldump -usakila_admin -psakila sakila > c:mysqlbackupssakila_080311.sql Code Explanation

Entire backup of sakila.

All tables in the database will be backed up.

The script includes both the CREATE TABLE and INSERT statements.

The output is saved in c:mysqlbackupssakila_080311.sql.

Code Sample:

mysqldump -usakila_admin -psakila -X sakila actor > c:mysqlbackupsactor_080311.xml Code Explanation

5 / 21


Create an XML output file for the actor table.

Note: The filenames in our examples contain a date/time. It's a good idea to use some sort ofconsistent naming convention for your backup files to distinguish and locate the right one.

Contents of the Backup SQL Script

Once the file has been created, you can view its contents by using a text editor. The contentsof the sakila_080311.sql file looks like:

Set Variables

MySQL saves some system values in user-defined variables to restore the original systemsettings should they be changed by any of the statements while executing the backup file,thereby ensuring that your environment is left in the same state after the restore via executionof the statements in the backup file.

The SET statement saves the current value associated with the character_set_client systemvariable to the @old_character_set_clientuser-defined variable.

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=CHARACTER_SET_CLIENT */;

We then use SET at the end of the backup file to restore character_set_client system variablefrom @old_character_set_clientwe had saved before the statements:

/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;

The following table describes the system variables that are used to assign values touser-defined variables in the backup file.

System variable

6 / 21


Description

character_set_client The character set that MySQL uses to process SQL statements sent by a client application. By default, MySQL uses the latin1 character set. character_set_results The character set that MySQL uses to return query results to a client application. By default, MySQL uses the latin1 character set. collation_connection The collation associated with the character set used for the connection. By default, MySQL uses the latin1_swedish_ci collation. unique_checks Specifies whether MySQL checks for uniqueness in a column configured with a unique index. By default, MySQL checks for uniqueness. foreign_key_checks Specifies whether MySQL checks foreign key constraints in a column configured as a foreign key. By default, MySQL checks foreign key constraints. sql_mode Specifies the SQL mode in which MySQL should operate. The mode determines what SQL syntax is supported and how data should be validated. By default, no mode is set. Enclosing Characters /*! and */

Note that the SET statements begin with the /*! symbols and end with the */ symbols. Thesymbols ensure the statements are executed by MySQL but ignored if they are executed inanother database management system. This allows your basic SQL statements in the backupfile to be used by other database systems, while preventing errors on statements that are important and unique to MySQL.

These symbols at the beginning of the statements are also followed by a number whichrepresents a MySQL server version. This number tells MySQL to execute the statement only ifthat version or a later version is being used. For example, 40101 indicates that the statementshould be executed only on MySQL version 4.01.01 or above.

Set Names

Now take a look at one other SET statement that is included at the beginning of a backup file:

/*!40101 SET NAMES utf8 */;

The SET NAMES statement specifies the name of the character set that should be used duringthe execution of the statements in the backup file. The statement applies to current connectiononly. In this case, the SET NAMES statement causes utf8 character set to beused, same as when the backup file was created.

The contents of the backup file that we have seen so far is common to backup files createdwith the mysqldump utility.

7 / 21


Tables

The other information in the file is specific to the tables that you have backed up. For eachtable, the file includes a table definition and an INSERT statement. The table definition isintroduced by comments similar to the following:

---- Table structure for table 'actor'--

In this case, the comments tell you that the information that follows applies to the actor table.The comments are then followed by a DROP TABLE statement followed by the CREATETABLEstatement then defines the table as it was at time of backup.

After the CREATE TABLE statement, the backup file includes the section that inserts data inthe actor table:

---- Dumping data for table 'actor'-- LOCK TABLES 'actor' WRITE;/*!40000 ALTER TABLE 'actor' DISABLE KEYS */;INSERT INTO 'actor' VALUES (1,'PENELOPE','GUINESS','2006-02-15 09:34:33'),...;/*!40000 ALTER TABLE 'actor' ENABLE KEYS */;UNLOCK TABLES;

An ALTER TABLE statement that tells MySQL to disable the indexes precedes each INSERTstatement. The ALTER TABLEstatement at the end of this group of statements re-enables the indexes. MySQL does this toimprove the performance of the insert operations where the indexes created after the insertsare done.

Warning: This process, however, works only for MyISAM table types and is ignored by othertable types.

A LOCK TABLES statement also precedes the INSERT statement, placing a WRITE lock onthe table so that no other values can be inserted in the table until after this

8 / 21


INSERTstatement has been executed. After the INSERTstatement runs, the table is then unlocked.

The INSERT statement in the backup file provides values for all columns in the table as theywere at time of backup. In usual Inserts, we do not specify several columns such as auto-increments, last-updates.

Ignoring Foreign Key Constraints

Both the INSERT statement and the CREATE TABLE statement that precedes it is that theycreate a table and insert data in a table that includes foreign key constraints.

If you were to try to create the same table manually before referenced tables are in place, youwould encounter an error. MySQL, however, allows all tables to be created and values to beinserted when done through a backup file, regardless of the foreign key constraints.

This way, MySQL can ignore the order of appearance of tables in the backup file.

Flush Logs

The option --flush-logs flushes your log files and a new binary log file is created. This isimportant when creating a backup because binary log files allow you to restore your databasefully.

By flushing the logs, you get an exact starting point for using the binary logs when refreshingyour restored database. It is recommended that you use the --flush- logs option whenever youback up your data.

To flush the logs, see following example:

9 / 21


Code Sample:

mysqldump --flush-logs -u sakila_admin -psakila sakila >c:mysqlbackupssakiladb_080311.sql Code Explanation

Logs are flushed before the backup starts.

A new log file is created with an incremented suffix (discussed in another lesson).

Now when you need to restore the database, it will be easier locating the proper log(s) to read.

Backing up Individual Tables

To use the mysqldump client utility to back up individual tables in a database, add theapplicable table names after the database name in your mysqldump command:

mysqldump [ [...]] > Backing up Multiple Databases

You can back up multiple databases with the mysqldump client utility. The backup file willinclude not only tables but also the statements necessary to create the databases that arebeing backed up.

You can use two formats of the mysqldump utility to back up multiple databases. In the firstformat you specify the databases by adding the --databases option followed by at least onedatabase name, and the second format allows you to back up all databases that are currentlystored on your MySQL server.

Code Explanation

10 / 21


Back up the sakila and sakila1i databases.

Database Information in the Backup File ---- Current Database: 'sakila'--CREATE DATABASE /*!32312 IF NOT EXISTS*/ 'sakila';USE 'sakila';

The file first includes comments indicating that the statements that follow apply to the sakiladatabase. After the comments, the file contains a CREATE DATABASE statement, which willadd the sakila database to your system. Notice that the statement includes the clause /*!32312 IF NOT EXISTS*/, which is not executed unless the statement runs against a MySQL server, version 3.23.12 orlater.

Note: Using the multi-db form of the mysqldump command is useful if you want the backup fileto contain the necessary database definition, which makes the file more comprehensive. If thebackup file doesn't include the database definition, you must first manually create the databasebefore restoring the backup.

Backing up all Databases

If you plan to back up all the databases on your system, use mysqldump as shown:

mysqldump --all-databases >

The backup file will contain all the necessary database and table information for all the tables inall the databases.

Warning: With all-databases option, mysqldump will back up the mysql administrative databaseas well, which could be a security risk if the backup file is not properly secured.

Warning: mysqldump does not dump the INFORMATION_SCHEMA database, even if youname that database explicitly in your command - mysqldump quitely ignores the request.

11 / 21


Restoring Your Database

Despite your best efforts to protect your databases, disasters can occur, and you might find itnecessary to restore one or more of your databases. If you have backed up your files regularlyand enabled binary logging, restoring your database consists of two steps:

1. Use the mysql monitor to execute the backup script to reload a MySQL database. 2. Use the appropriate binary logs to update the database.

These two steps restore a database to the point of database errors, thus preventing anysignificant data loss in case of a faulure or a disaster.

Reloading Your Database

If you are restoring data from a backup file that does not include a database definition, thedatabase must exist before restoring. For example, to restore a database from thesakila_041031.sql file, which does not include a database definition, you would use:

mysqldump --flush-logs -usakila_admin -psakila --databases sakila1 sakila > c:mysqlbackupssakila_twodb_080311.sql

Code Explanation

Create database sakilaktsatfu.

Restore the sakila backup into sakilaktsatfu.

If you are restoring a database from a backup file that includes the necessary databasedefinition, you need not specify a database with mysql monitor:

12 / 21


Code Explanation

Restore database sakila1 with database information.

You can also use the mysql client utility in interactive mode, as seen before:

source Code Sample: DROP DATABASE IF EXISTS sakilaktsatfu;CREATE DATABASE sakilaktsatfu;USE sakilakutsatfu;source c:mysqlbackupssakiladb_080311.sql Code Explanation

Create database sakilaktsatfu and restore the backup into sakilaktsatfu.

Creating a backup file that includes the necessary database definitions makes restoring yourdatabases a simpler process. In addition, if you're restoring multiple databases from a singlefile, the file must contain the necessary database definitions.

Updating the Restored Database From Binary Log Files

Once database is reloaded, the data is only as current as your last backup, which is wherebinary logging comes in.

After you reload your database into your system, you will most likely want to get the databaseto its most current state since it was backed up. You will use binary logs which track all datamodifications that occur in your databases.

MySQL provides two methods for applying updates from a binary log - restoring data directlyfrom the binary log file or exporting binary log data to a text file and then restoring it from thatfile.

13 / 21


You must have binary logging enabled on your system to be able to use it to update a restoreddatabase, covered in other lessons.

Restoring Data Directly From a Binary Log

To apply updated data to the database that you've reloaded, you must know which log filesapply. By comparing the log file timestamps to the backup file timestamp, you should be able tofigure out easily which logs apply.

In addition, if you used the --flush-logs option when you backed up the database, you can startright at the beginning of the file instead of struggling to know where to look for data starting inthe middle of a log file.

After you identify the log files that you should apply, you can use the mysqlbinlog client utility toexecute the statements in the log file. For example, the following mysqlbinlog commandexecutes the SQL statements in the -bin.000028 log file:

mysqlbinlog "c:program filesmysqlmysql server 5.0data-bin.000028" | mysql

The mysqlbinlog command is followed by the path and the name of the log file. In addition, thecommand sends (pipes) the SQL statements to the mysql client utility to be executed asnecessary. If you plan to execute multiple log files, you should start with the oldest one first andwork your way through to the most current file.

If you want to apply the change in the log files to only one database, you can specify the --one-databaseoption with the database name:

mysqlbinlog "c:program filesmysqlmysql server 5.0data-bin.000028" |mysql --one-database sakila1

Notice that you must include the name of the database after the --one-database option. Whenyou do this, MySQL processes only those logged statements that apply to the specifieddatabase.

Selective Changes from Log Files

14 / 21


In some cases, you may want to re-run only certain binary logs, from certain positions (usuallyyou want to re-run all binary logs from the date of the restored backup, excepting possiblysome incorrect statements).

The log file may contain statements that you don't want executed. For example, the log filemight contain DROP DATABASE statements or CREATE TABLE statements that you don'twant executed. There are really not many options to pick and choose which statements areexecuted except for specifying statements pertaining to a specific database. You can getaround this issue by exporting the contents of the binary log file to a text file.

Restoring Binary Log Data From a Text File

The mysqlbinlog client utility allows you to export data to a text file. From there, you can sortthrough the text file to remove any statements that you don't want to execute. Of course, thelarger the log file, the more difficult this process can be, but there might be times when this isthe only way you can ensure that your database is fully restored. After you're satisfied that thetext file contains only the correct statements, you can use the mysql client utility to execute thestatements.

The first step, then, is to export the data in the log file to the text file. For example, the followingmysqlbinlog command exports the mysql_bin.log.000028 log file to the binlog000028.txt file:

mysqlbinlog "mysql_bin.log.000028" >c:mysqlbackupsbinlog000028.txt

After editing the text file as necessary, execute the statements in the text file:

mysql

All SQL statements that are saved in the text file are executed. If you want to run onlystatements related to a specific database, you can use the --one-database option in the sameway you saw earlier, as shown in the following example:

mysql --one-database sakila

As the command shows, you specify the --one-database option and the name of the database,followed by the left arrow and the path and filename of the text file. Any updates that wererecorded in the binary log file - and exported to the text file - are applied to the database.

15 / 21


Enabling and Disabling Binary Logging

When restoring databases and applying log file statements, you might find that you want toexecute a statement that you don't want logged. For example, suppose that you want to drop adatabase before you restore it. If you run the DROP DATABASE statement, that statement islogged to the binary log file. You can manually turn off logging in a session by using a SETstatement to set the sql_log_binsystem variable, as shown in the following syntax:

SET SQL_LOG_BIN={0 | 1}

If sql_log_bin is set to 0, logging is disabled, generally before executing a statement thatshould not be logged. If set to 1, logging is enabled.

This allows you to control which statements are logged, which can be critical to restoring your database effectively.

As this section demonstrates, restoring a database is as simple as retrieving a backup file fromyour hard disk and then applying the statements in the applicable binary logs. In the followingexercise, you restore the database that was backed up in the previous Try It Out section. Torestore the database, you first remove the original database from your system and then use thesource command in the mysql client utility to execute the SQL statement in the backup file.

Though the process of restoring a database is straightforward; it can be a very time-consumingprocess leading to substantial downtime for your database.

Recovering Corrupt MyISAM Tables

If you have to restore MyISAM tables that have become corrupt, try to recover them usingREPAIR TABLE or myisamchk -r first. That should work in 99.9% of all cases. If myisamchkfails, we will follow the usual Restore progress described in the lesson.

mysqlhotcopy - A Database Backup Program

16 / 21


mysqlhotcopy is a Perl script that uses LOCK TABLES, FLUSH TABLES, and cp or scp tomake fast database or table backups, but there are some constraints.

- Runs only on the same machine where the database directories are located. - Works only for backing up MyISAM and ARCHIVE tables. - Runs on limited operating systems like Unix and NetWare.

Read more about it at http://dev.mysql.com/doc/refman/5.0/en/mysqlhotcopy.html

Backing Up and Recovering an InnoDB Database

If you can afford to shut down your MySQL server, you can make a binary backup that consistsof all files used by InnoDB to manage its tables, using the following procedure:

1. Shut down your MySQL server, ensure shut down proceeds without errors. 2. Copy all your data files (ibdata files and .ibd files) into a secure and reliable location. 3. Copy all your ib_logfile files. 4. Copy your configuration file(s) (my.cnf or similar). 5. Copy all the .frm files for your InnoDB tables.

Replication works with InnoDB tables, so you can use MySQL replication capabilities to keep acopy of your database at database sites requiring high availability.

In addition to making binary backups, you should also regularly make dumps of your tables withmysqldump. The reason for this is that a binary file might be corrupted with no visible signs.Dumped tables are stored into text files that are simpler and human-readable, so spotting tablecorruption becomes easier. mysqldump also has a --single- transaction option thatyou can use to make a consistent snapshot without locking out other clients.

In case your MySQL server crashes or shuts down abnormally, normally a restart will cause InnoDBto automatically check the logs and performs a roll-forward of the database to the present. InnoDBautomatically rolls back uncommitted transactions at the time of the crash. While recovering,

17 / 21


mysqldoutput looks like:

InnoDB: Database was not shut down normally.InnoDB: Starting recovery from log files...InnoDB: Starting log scan based on checkpoint atInnoDB: log sequence number 0 13674004InnoDB: Doing recovery: scanned up to log sequence number 0 11239631...InnoDB: Doing recovery: scanned up to log sequence number 0 19864819InnoDB: 1 uncommitted transaction(s) which must be rolled backInnoDB: Starting rollback of uncommitted transactionsInnoDB: Rolling back trx no 9287InnoDB: Rolling back of trx no 9287 completedInnoDB: Rollback of uncommitted transactions completedInnoDB: Starting an apply batch of log records to the database...InnoDB: Apply batch completedInnoDB: Startedmysqld: ready for connections

In some cases, apparent database page corruption may actually be only in the OS file cacheand the data on disk may be fine. An OS-level restart may eliminate some of the perceiveddatabase errors.

In case of a serious data corruption or a disk failure, the recovery will have to performed from abackup. You must locate and use a backup that has no corruption. After restoring the basebackup, do the recovery from the binary log files using mysqlbinlog as before.

In some corruption situations it may be sufficient to dump, drop, and re-create just the fewcorrupt tables. Use CHECK TABLE SQL statement to identify if a table is corrupt. Please notethat CHECK TABLE cannot detect every possiblecorruption. You can also use innodb_tablespace_monitorto check the file integrity of the tablespace files. Find more on this in MySQL documentation.

In database page corruption situations, exporting your tables with SELECT INTO OUTFILE mayget most of the data intact.

Stop Background Processes - Forced Recovery

18 / 21


It is possible that the corruption may cause the SELECT statements or InnoDB backgroundoperations to crash or lead to a InnoDBroll-forward recovery which then leads to a real crash. You can force the InnoDBengine to start without the background operations to dump your tables without headaches. Addthe following option to the [mysqld]section of your configuration file before restarting the server:

[mysqld]innodb_force_recovery = 4

The value innodb_force_recovery is bit- ored, so the larger values of this setting includes allprecautions with smaller values. If you are able to dump your tables with an option value of atmost 4, then you are relatively safe that only some data on corrupt individual pages is lost. Avalue of 6 is more drastic because database pages are left in an obsolete state, which in turnmay introduce more corruption into B-trees and other database structures.

- 1 (SRV_FORCE_IGNORE_CORRUPT)

Let the server run even if it detects a corrupt page. Try to make SELECT * FROM tbl_namejump over corrupt index records and pages, which helps in dumping tables.

- 2 (SRV_FORCE_NO_BACKGROUND)

Prevent the main thread from running. If a crash would occur during the purge operation, thisrecovery value prevents it.

- 3 (SRV_FORCE_NO_TRX_UNDO)

Do not run transaction rollbacks after recovery.

- 4 (SRV_FORCE_NO_IBUF_MERGE)

Prevent also insert buffer merge operations. If they would cause a crash, do not do them. Donot calculate table statistics.

- 5 (SRV_FORCE_NO_UNDO_LOG_SCAN)

19 / 21


Do not look at undo logs when starting the database: InnoDB treats even incompletetransactions as committed.

- 6 (SRV_FORCE_NO_LOG_REDO)

Do not do the log roll-forward in connection with recovery.

You can SELECT from tables to dump them, or DROP or CREATE tables even if forcedrecovery is used. If you know that a given table is causing a crash on rollback, you can drop it.You can also use this to stop a runaway rollback caused by a failing mass import or ALTER TABLE. You can kill the mysqldprocess and set innodb_force_recoveryto 3to bring the database up without the rollback, then DROPthe table that is causing the runaway rollback.

The database must not otherwise be used with any non-zero value of innodb_force_recovery.As a safety measure, InnoDBprevents users from performing INSERT, UPDATE, or DELETEoperations when innodb_force_recoveryis greater than 0.

Recovery using Checkpoints

InnoDB implements a checkpoint mechanism known as fuzzy checkpointing. InnoDB flushes

20 / 21


modified database pages from the buffer pool in small batches. Flushing pool in a single batchwould halt processing of user SQL statements when the checkpointing is running.

During crash recovery, InnoDB looks for a checkpoint label written to the log files and theengine knows that all modifications to the database before the label are already present in thedatabase disk image. Then InnoDB scans and appliesmodifications forward from the checkpoint, saving precious recovery time.

Note: Having very large log files saves disk I/O in checkpointing but the crash recovery cantake longer due to larger logged information to apply. But, then how often are we planning ondoing crash recovery?

InnoDB Hot Backup

InnoDB Hot Backup is mentioned on MySQL website as a commercial add-on online backuptool you can use to backup your InnoDB database while it is running,without needing a shut down or any locks or disturbing your normal database processing. Go tohttp://www.innodb.com/hot-backup for more information.

Data Backup and Restore in MySQL Conclusion

As this lessons shows, MySQL supports several methods to protect data loss. By backing upyour data, you are recording changes made to your database offline. If you need to restoreyour database, you can use a backup file along with the applicable binary log files, to restoreyour system to its original state.

To continue to learn MySQL go to the top of this page and click on the next lesson in thisMySQL Tutorial's Table of Contents. mysql -u root -p --execute "CREATE DATABASEsakilaktsatfu;GRANT ALL ON sakilaktsatfu.* TO sakila_admin"mysql -u sakila_admin -psakila sakilaktsatfu mysql -u sakila_admin -psakila

21 / 21

Managing Backup and Recovery - MySQL...

Documents

Transcript of Managing Backup and Recovery - MySQL...