Mysql dba training session 10 backup and recovery in mysql

MySQL DBA Training Session 10. Backup and Recovery in MySQLRAM N SANGWAN

WWW.HOMETUTOR.NET. IN

HT TP://YOUTUBE.COM/USER/THESKILLPEDIA

Backup Principles

• Make backups regularly.

• Enable the binary log so that you have a record of changes made after a given

backup.

• Flush the logs when backing up so that the server will begin a new binary log

file that corresponds to the time of the backup.

• Store your data directory and your backups on different physical devices so

that a device failure cannot destroy both.

• Include your backups in your normal filesystem backup procedures so that you

can recover the backup if necessary.

Binary Versus Textual Backups

• A binary backup is a copy of the files in which database contents are stored.

• Restoration involves copying the files back to their original locations.

• Techniques for making binary backups include file copy commands, mysqlhotcopy, and InnoDB

Hot Backup.

• A text backup is a dump of database contents into text files.

• Restoration involves loading the file contents back into databases by processing them through

the server.

• Techniques for making text backups include the SELECT... INTO OUTFILE SQL statement and

mysqldump.

• The two backup formats have different strengths and weaknesses. The general tradeoff is

speed versus portability.

Binary Versus Textual Backups Contd..

• It's faster to make a binary backup. For a different architecture on target machine, the files must

be binary portable.

• It's slower to make a text backup.

• Text backups are portable.

• The procedure for making binary backups depends on which storage engine created the tables,

and generally can be used only for the local MySQL server.

• Text backup procedures are more general and can be used for tables created by any storage

engine.

Making Binary MyISAM Backups

• To make a binary backup of a MyISAM table, copy the .frm, .MYD, and .MYI files that MySQL

uses to represent the table.

• When you do this, the table must not be in use. If you leave the server running, use an

appropriate locking protocol to prevent server access to the table.

mysql> USE world;

mysql> LOCK TABLES Country READ;

mysql> FLUSH TABLES Country;

• Then (with the table still locked) use your operating system's file copy command to copy the

table files. After the copy operation completes, release the lock on the table:

mysql> UNLOCK TABLES;

Making Binary InnoDB Backups

1. Stop the server for the duration of the copy operation.

2. Make sure that the server shut down without error. Binary InnoDB backups require a clean

shutdown to be certain that the server has completed any pending transactions.

3. Make a copy of each of the following components :

◦ The .frm file for each InnoDB table.

◦ The tablespace files.

◦ The InnoDB log files.

◦ Any InnoDB configuration options, such as those stored in option files.

4. Restart the server.

Innodb Tablespace Restore

• Stop the server, replace all the components that you made copies of during the backup

procedure, and restart the server.

• Note that the necessity of copying the tablespace files as a group means that for recovery

operations you'll need to replace any existing tablespace files on the destination server.

• You cannot add one tablespace to another using a binary backup.

• An alternative to making a binary backup is to dump table contents in text format.

• This technique can be useful for copying individual InnoDB tables from one server to another or

if the conditions for binary portability are not satisfied.

• It can also be used to add tables from one tablespace to another:

◦ Run mysqldump to dump the tables into a text file, and then load the file into the destination server using

mysql.

Other Binary Backup Tools - mysqlhotcopy

• The mysqlhotcopy script copies tables to a backup directory. It is a Perl script and requires theDBI module to be installed.

• mysqlhotcopy works for MyISAM tables, not InnoDB tables.

• mysqlhotcopy connects to the local MySQL server, locks the tables so that the server will notchange them, flushes the tables to make sure that any pending changes are written to disk, andthen copies the table files.

• When it has finished the copy operation, it unlocks the tables.

• mysqlhotcopy must be run on the server host so that it can copy table files while the table locksare in place.

• Operation of mysqlhotcopy is fast because it copies table files directly rather than backing themup over the network. It's also more convenient than issuing statements to the server to lock andflush the tables, because it handles those operations for you.

• mysqlhotcopy has many options, which you can see by invoking it with the --help option

More on Binary Portability

• MyISAM tables and InnoDB tablespaces are binary portable from one host to another if :

◦ Both machines must use two's-complement integer arithmetic.

◦ Both machines must use IEEE floating-point format, or else the tables must contain no floating-point

columns (FLOAT or DOUBLE).

• A third condition is that you should use lowercase names for databases and

tables.

• To force the use of lowercase names, you can put the following lines in an option file:

[mysqld]

lower_case_table_names=1

More on Binary Portability

• If you configure InnoDB to use per-table tablespaces, the conditions for binary portability are

extended to include the .ibd files for InnoDB tables as well.

• If the conditions for binary portability are not satisfied, you can copy MyISAM or InnoDB tables

from one server to another by dumping them using some text format (for example, with

mysqldump) and reloading them into the destination server.

Making Text Backups - via SQL

• The SELECT... INTO OUTFILE statement writes the contents of an arbitrary result set to a disk

file on the server host. For backup purposes, it can be used in the following form to write a text

dump of an entire table:

SELECT * INTO OUTFILE 'file_name' FROM table_name;

• The resulting disk file is always created on the server host, however, because the server itself

writes the file.

• The output file must not already exist.

• The statement works for any storage engine.

• The statement requires the FILE privilege.

• The output format can be controlled by using statement options that specify column and line

delimiters, quote characters, and escape characters.

Text Backups with mysqldump

Characteristics:

It can dump all databases, specific databases, or specific tables.

• mysqldump can back up local or remote servers, although the destination for the dump files

depends on how you invoke it.

• For SQL-format dump files that contain CREATE TABLE and INSERT statements for re-

creating the tables, the server sends table contents to mysqldump, which writes the files on the

client host.

◦ It works for tables created by any storage engine.

◦ Output files are written in text format and are portable, so they can be used for transferring

database contents to another server.

Text Backups with mysqldump

• By default, mysqldump interprets its first non-option argument as a database name and dumps all the

tables in that database. If any other arguments follow the database name, mysqldump interprets them as

table names and dumps just those tables.

• The following command dumps the contents of all the tables in the world database into a file named

world.sql :

shell> mysqldump world > world.sql

• The following command names just the City and Country tables after the database name, so mysqldump

dumps just those tables to a file called city_country.sql :

shell> mysqldump world City Country > city_country.sql

• With the --databases (or -B) option, mysqldump interprets any non-option argument as a database name

and dumps all the tables in each of the named databases.

shell> mysqldump --databases world test > world_and_test.sql

• With the --all-databases (or -A) option, mysqldump dumps all tables in all databases.

shell> mysqldump --all-databases > alldb.sql

Text Backups with mysqldump

• mysqldump understands the standard connection parameter options, such as --host and --

user.

• You'll need to supply these options if the default connection parameters aren't appropriate.

• mysqldump also understands options that provide more specific control over the dump

operation.

• Invoke mysqldump with the --help option to see a list of available options.

Data Recovery

• The general recovery procedure follows these steps:

1. Make a copy of the data directory first, in case something goes wrong during recovery.

2. Recover your databases using your backup files. If you made a binary backup, this step

involves stopping the server and replacing the lost or damaged files with the copies.

3. Re-execute the changes in the binary log that were recorded after your backup was made.

Reloading mysqldump Output

• To reload an SQL-format dump file produced by mysqldump, process it with mysql.

shell> mysqldump world Country > dump.sql

• To reload the file later, use mysql :

shell> mysql world < dump.sql

• The mysql command for reloading mysqldump output should name the database if the dumpfile

itself does not.

• It is not necessary to name the database if you are reloading a dump file created by invoking

mysqldump with the --database or --all-databases option.

• In that case, the dump file contains appropriate USE db_name statements.

Reloading mysqldump Output

• To copy the Country table from the world database to the test database, use this command:

shell> mysqldump world Country | mysql test

• The following command uses a pipe to copy the Country table from the world database on the

local host to the world database on the remote host other.host.com:

shell> mysqldump world Country | mysql -h other.host.com world

• If a dump file contains very long INSERT statements, they might exceed the default size of the

communications buffer (1MB).

• You can increase the buffer size for both mysqldump and mysql with the --max-allowed-packet

option.

• For example, --max-allowed-packet=32M specifies a size of 32MB.

Processing Binary Log Contents

• After you have restored your binary backup files or reloaded your text backup files, you should

finish a recovery operation by reprocessing the data changes that are recorded in the server's

binary logs.

• To do this, determine which logs were written after you made your backup.

• Then convert their contents to text SQL statements with the mysqlbinlog program and process

the resulting statements with mysql.

• For example, if your log files were numbered 1 to 49 before the backup and logs 50 to 52 were

written after the backup, you'll need to process logs 50 to 52 after restoring the backup. If your

binary logs are named with a prefix of bin, the log processing command looks like this:

shell> mysqlbinlog bin.000050 bin.000051 bin.000052 | mysql

Reloading mysqldump Output

• All the binary log files that you want to process should be handled in a single mysqlbinlog

command.

• There may be inter-file dependencies that will not be satisfied if you process them separately.

• If a given binary log file was in the middle of being written during the backup, you must extract

from it only the part that was written after the backup, plus all log files written after that.

• To handle partial-file extraction, mysqlbinlog supports options that enable you to specify the

time or log position at which to begin extracting log contents:

◦ The --start-datetime.

◦ The --start-position option can be used to specify extraction beginning at a given log position.

◦ There are also corresponding --stop-datetime and --stop-position options for specifying the

point at which to stop extracting log contents.

Example

• To extract the contents of logs 50 to 52 beginning with events recorded at 2005-05-20 17:43:20,

modify the previous command as follows:

shell> mysqlbinlog --start-datetime="2005-05-20 17:43:20" bin.000050 bin.000051

bin.000052 | mysql

• If you're not sure about the timestamp or position in a log file that corresponds to the point at

which you want processing to begin, use mysqlbinlog without mysql to display the log contents

for examination.

• In this case, a pager program can be useful:

shell> mysqlbinlog file_name | more

Thank you