Inno db datafiles backup and retore

Index:
A. The INNODB Storage Engine
B. Backing Up and Recovering an InnoDBDatabase
C. How Checkpoint Processing Works
D. Moving or Copying InnoDB Tables to Another Machine
E. MySQL 5.5 supported storage engines

(A)The InnoDB Storage Engine:
InnoDB is a high-reliability and high-performance storage engine for MySQL.
Starting with MySQL 5.5, it is the default MySQL storage engine. Key advantages
of InnoDB include:
Its design follows the ACID model, with transactions featuring commit,
rollback, and crash-recovery capabilities to protect user data.
Row-level locking and Oracle-style consistent reads increase multi-user
concurrency and performance.
InnoDB tables arrange your data on disk to optimize common queries based
on primary keys. Each InnoDB table has a primary key index called the
clustered index that organizes the data to minimize I/O for primary key
lookups.
To maintain data integrity, InnoDB also supports FOREIGN KEY referential-
integrity constraints.
You can freely mix InnoDB tables with tables from other MySQL storage
engines, even within the same statement. For example, you can use a join
operation to combine data from InnoDB and MEMORY tables in a single
query.
To determine whether your server supports InnoDB use the SHOW ENGINES
statement.

(B)Backing Up and Recovering an InnoDBDatabase :
(1) The InnoDB Recovery Process
(2) Forcing InnoDB Recovery
(3) InnoDB Checkpoints
The key to safe database management is making regular backups. Depending on
your data volume, number of MySQL servers, and database workload, you can use
these techniques, alone or in combination:
 Hot backupwith MySQL Enterprise Backup;
 Cold backup by copying files while the MySQL server is shut down;
 physical backup for fast operation (especially for restore);
 logical backup with mysqldumpfor smaller data volumes or to record the
structure of schema objects.
Hot Backups :
The mysqlbackup command, part of the MySQL Enterprise Backup component,
lets you back up a running MySQL instance, including InnoDB and MyISAM tables,
with minimal disruption to operations while producing a consistent snapshot of
the database. When mysqlbackup is copying InnoDB tables, reads and writes to
both InnoDB and MyISAM tables can continue. During the copying of MyISAM
tables, reads (but not writes) to those tables are permitted. MySQL Enterprise
Backup can also create compressed backup files, and back up subsets of tables
and databases. In conjunction with MySQL’s binary log, users can perform point-
in-time recovery. MySQL Enterprise Backup is part of the MySQL Enterprise
subscription. For more details, (see “MySQL Enterprise Backup”)
Cold Backups :
If you can shut down your MySQL server, you can make a binary backup that
consists of all files used by InnoDBto manage its tables. Use the following
procedure:
 Do a slow shutdown of the MySQL server and make sure that it stops
without errors.
 Copy all InnoDB data files (ibdata files and .ibd files) into a safe place.
 Copy all the .frm files for InnoDBtables to a safe place.
 Copy all InnoDB log files (ib_logfile files) to a safe place.

 Copy your my.cnf configuration file or files to a safe place.
Alternative Backup Types :
In addition to making binary backups as just described, regularly make dumps of
your tables with mysqldump. A binary file might be corrupted without you
noticing it. Dumped tables are stored into text files that are human-readable, so
spotting table corruption becomes easier. Also, because the format is simpler, the
chance for serious data corruption is smaller. mysqldump also has a --single-
transaction option for making a consistent snapshot without locking out other
clients. (See Section 7.3.1, “Establishing a Backup Policy”)
Replication works with InnoDB tables, so you can use MySQL replication
capabilities to keep a copy of your database at database sites requiring high
availability.
Performing Recovery :
To recover your InnoDB database to the present from the time at which the
binary backup was made, you must run your MySQL server with binary logging
turned on, even before taking the backup. To achieve point-in-time recovery after
restoring a backup, you can apply changes from the binary log that occurred after
the backup was made. See (Section 7.5, “Point-in-Time (Incremental) Recovery
Using the Binary Log”)To recover from a crash of your MySQL server, the only
requirement is to restart it. InnoDB automatically checks the logs and performs a
roll-forward of the database to the present. InnoDB automatically rolls back
uncommitted transactions that were present at the time of the crash. During
recovery, mysqld displays output something like this:
InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 13674004
InnoDB: Doing recovery: scanned up to log sequence number 0 13739520

InnoDB: 1 uncommitted transaction(s) which must be rolled back
InnoDB: Starting rollback of uncommitted transactions
InnoDB: Rolling back trx no 16745
InnoDB: Rolling back of trx no 16745 completed
InnoDB: Rollback of uncommitted transactions completed
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Apply batch completed
InnoDB: Started
mysqld: ready for connections
If your database becomes corrupted or disk failure occurs, you must perform the
recovery using a backup. In the case of corruption, first find a backup that is not
corrupted. After restoring the base backup, do a point-in-time recovery from the
binary log files using mysqlbinlog and mysql to restore the changes that occurred
after the backup was made.
In some cases of database corruption it is enough just to dump, drop, and re-
create one or a few corrupt tables. You can use the CHECK TABLESQL statement
to check whether a table is corrupt, although CHECK TABLE naturally cannot
detect every possible kind of corruption. You can use the Table space Monitor to
check the integrity of the file space management inside the table space files. In
some cases, apparent database page corruption is actually due to the operating
system corrupting its own file cache, and the data on disk may be okay. It is best
first to try restarting your computer. Doing so may eliminate errors that appeared
to be database page corruption.
(1) The InnoDB Recovery Process
InnoDB crash recovery consists of several steps. The first step, redo log
application, is performed during the initialization, before accepting any
connections. If all changes were flushed from the buffer pool to the tablespaces
(ibdata* and *.ibd files) at the time of the shutdown or crash, the redo log
application can be skipped. If the redo log files are missing at startup, InnoDB
skips the redo log application. The remaining steps after redo log application do
not depend on the redo log (other than for logging the writes) and are performed
in parallel with normal processing.
These include:
Rolling back incomplete transactions: Any transactions that were active at
the time of crash or fast shutdown.

Insert buffer merge: Applying changes from the insert buffer tree (from the
shared tablespace) to leaf pages of secondary indexes as the index pages
are read to the buffer pool.
Purge: Deleting delete-marked records that are no longer visible for any
active transaction.
Of these, only rollback of incomplete transactions is special to crash recovery. The
insert buffer merge and the purge are performed during normal processing.
(2) Forcing InnoDBRecovery :
If there is database page corruption, you may want to dump your tables from the
database with SELECT ... INTO OUTFILE. Usually, most of the data obtained in this
way is intact. However, it is possible that the corruption might cause SELECT *
FROM tbl_name statements or InnoDB background operations to crash or assert,
or even cause InnoDB roll-forward recovery to crash. In such cases, you can use
the innodb_force_recovery option to force the InnoDB storage engine to start up
while preventing background operations from running, so that you can dump your
tables. For example, you can add the following line to the [mysqld] section of your
option file before restarting the server:
[mysqld]
innodb_force_recovery = 4
innodb_force_recovery is 0 by default (normal startup without forced recovery).
The permissible nonzero values for innodb_force_recovery follow. A larger
number includes all precautions of smaller numbers. If you can dump your tables
with an option value of at most 4, then you are relatively safe that only some data
on corrupt individual pages is lost.
A value of 6 is more drastic because database pages are left in an obsolete state,
which in turn may 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_name jump over corrupt index records and pages, which helps in
dumping tables.
2 (SRV_FORCE_NO_BACKGROUND)
Prevent the master threadfrom running. If a crash would occur during the
purgeoperation, this recovery value prevents it.

3 (SRV_FORCE_NO_TRX_UNDO)
Do not run transaction rollbacks aftercrash recovery.
4 (SRV_FORCE_NO_IBUF_MERGE)
Prevent insert buffer merge operations. If they would cause a crash, do not
do them. Do not calculate table statistics.
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
Do not look at undo logs when starting the database: InnoDB treats even
incomplete transactions as committed.
6 (SRV_FORCE_NO_LOG_REDO)
Do not do the redo logroll-forward in connection with recovery. With this
value, you might not be able to do queries other than a basic SELECT *
FROM t, with no WHERE, ORDER BY, or other clauses. More complex
queries could encounter corrupted data structures and fail.
If corruption within the table data prevents you from dumping the entire
table contents, a query with an ORDER BY primary_key DESC clause might
be able to dump the portion of the table after the corrupted part.
The database must not otherwise be used with any nonzero value of
innodb_force_recoveryAs a safety measure, InnoDB prevents users from
performing INSERT, UPDATE, or DELETE operations when innodb_force_recovery
is greater than 0.
You can SELECT from tables to dump them, or DROP or CREATE tables even if
forced recovery 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 mysqld process and set
innodb_force_recovery to 3 to bring the database up without the rollback,
thenDROP the table that is causing the runaway rollback.
(3) InnoDBCheckpoints :
Making your log files very large may reduce disk I/O during checkpointing. It often
makes sense to set the total size of the log files as large as the buffer pool or even
larger. Although in the past large log files could make crash recovery take
excessive time, starting with MySQL 5.5, performance enhancements to crash
recovery make it possible to use large log files with fast startup after a crash.
(Strictly speaking, this performance improvement is available for MySQL 5.1 with
the InnoDB Plugin 1.0.7 and higher. It is with MySQL 5.5 and InnoDB 1.1 that this
improvement is available in the default InnoDB storage engine.)

(C)How Checkpoint Processing Works
InnoDB implements a checkpoint mechanism known as “fuzzy”checkpointing.
InnoDB flushes modified database pages from the buffer pool in small batches.
There is no need to flush the buffer pool in one single batch, which would in
practice stop processing of user SQL statements during the checkpointing process.
During crash recovery, InnoDB looks for a checkpoint label written to the log files.
It knows that all modifications to the database before the label are present in the
disk image of the database. Then InnoDB scans the log files forward from the
checkpoint, applying the logged modifications to the database.
InnoDB writes to its log files on a rotating basis. It also writes checkpoint
information to the first log file at each checkpoint. All committed modifications
that make the database pages in the buffer pool different from the images on disk
must be available in the log files in case InnoDB has to do a recovery. This means
that when InnoDB starts to reuse a log file, it has to make sure that the database
page images on disk contain the modifications logged in the log file that InnoDB is
going to reuse. In other words, InnoDB must create a checkpoint and this often
involves flushing of modified database pages to disk.
(D)Moving or Copying InnoDB Tables to Another Machine :
The various techniques for moving or copying some or all InnoDB tables to a
different server.
For example,
You might move an entire MySQL instance to a larger, faster server; you might
clone an entire MySQL instance to a new replication slave server; you might copy
individual tables to another server to development and test an application, or to a
data warehouse server to produce reports.
On Windows, InnoDB always stores database and table names internally in
lowercase. To move databases in a binary format from Unix to Windows or from
Windows to Unix, create all databases and tables using lowercase names. A
convenient way to accomplish this is to add the following line to the [mysqld]
section of your my.cnf or my.ini file before creating any databases or tables:
[mysqld]
lower_case_table_names=1

Like MyISAM data files, InnoDB data and log files are binary-compatible on all
platforms having the same floating-point number format. You can move an
InnoDB database simply by copying all the relevant files listed in (See“Backing Up
and Recovering an InnoDB Database” ).
If the floating-point formats differ but you have not used FLOATorDOUBLE data
types in your tables, then the procedure is the same: simply copy the relevant
files. If you use mysqldump to dump your tables on one machine and then import
the dump files on the other machine, it does not matter whether the formats
differ or your tables contain floating-point data.
One way to increase performance is to switch off autocommit mode when
importing data, assuming that the tablespace has enough space for the big
rollback segment that the import transactions generate. Do the commit only after
importing a whole table or a segment of a table.
InnoDB installation path:

Inno db datafiles backup and retore

mysql>help show binary logs
Name: 'SHOW BINARY LOGS'
Description:
Syntax:
SHOW BINARY LOGS
SHOW MASTER LOGS
Lists the binary log files on the server. This statement is used as part of the
procedure described in [purge-binary-logs], that shows how
to determine which logs can be purged.
mysql> SHOW BINARY LOGS;
+---------------+-----------+
| Log_name | File_size |
+---------------+-----------+
| binlog.000015 | 724935 |
| binlog.000016 | 733481 |
+---------------+-----------+

SET sql_log_binSyntax :
SET sql_log_bin = {0|1}
The sql_log_bin variable controls whether logging to the binary log is done. The
default value is 1 (do logging). To change logging for the current session, change
the session value of this variable. The session user must have the SUPER privilege
to set this variable.
(E)MySQL 5.5 supported storage engines:
InnoDB: A transaction-safe (ACID compliant) storage engine for MySQL that
has commit, rollback, and crash-recovery capabilities to protect user data.
InnoDB row-level locking (without escalation to coarser granularity locks)
and Oracle-style consistent nonlocking reads increase multi-user
concurrency and performance. InnoDB stores user data in clustered indexes
to reduce I/O for common queries based on primary keys. To maintain data
integrity, InnoDB also supports FOREIGN KEY referential-integrity
constraints. InnoDB is the default storage engine as of MySQL 5.5.5.
MyISAM: The MySQL storage engine that is used the most in Web, data
warehousing, and other application environments. MyISAM is supported in
all MySQL configurations, and is the default storage engine prior to MySQL
5.5.5.
Memory: Stores all data in RAM for extremely fast access in environments
that require quick lookups of reference and other like data. This engine was
formerly known as the HEAP engine.

Merge: Enables a MySQL DBA or developer to logically group a series of
identical MyISAM tables and reference them as one object. Good for VLDB
environments such as data warehousing.
Archive: Provides the perfect solution for storing and retrieving large
amounts of seldom-referenced historical, archived, or security audit
information.
Federated: Offers the ability to link separate MySQL servers to create one
logical database from many physical servers. Very good for distributed or
data mart environments.
NDB (also known as NDBCLUSTER)—This clustered database engine is
particularly suited for applications that require the highest possible degree
of uptime and availability.

Inno db datafiles backup and retore

More Related Content

What's hot (16)

Viewers also liked (8)

Similar to Inno db datafiles backup and retore (20)

Recently uploaded (20)

Inno db datafiles backup and retore