Date post: | 16-Apr-2017 |
Category: |
Education |
Upload: | ram-n-sangwan |
View: | 104 times |
Download: | 10 times |
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