当前位置：网站首页>Use xtrabackup for MySQL database physical backup
Use xtrabackup for MySQL database physical backup
2022-07-06 10:09:00 【wx5caecf2ed0645】
0. xtrabackup The function of
Functions that can be realized ：
Non blocking backup innodb Wait for the transaction engine database 、
Backup myisam The watch will block ( Lock required )、
Support for all 、 Incremental backup 、 Compressed backup 、
Fast incremental backup (xtradb, The principle is similar to oracle：tracking Changes since the last backup page.)、
percona Support archiving redo log Backup of 、
percona5.6+ Support lightweight backup-lock Replace the original heavyweight FTWRL, At this point, even if the non transaction engine table is backed up, it will not block innodb Of DML Statement 、
Support encrypted backup 、 Stream backup ( Backup to remote machine )、 Parallel local backup 、 Parallel compression 、 Parallel encryption 、 Generated during parallel application backup redo journal 、 parallel copy-back
Support partial backup , Back up only one library , A table
Support partial recovery
Supports backing up a single table partition
Support backup speed limit , Refers to... Generated by backup IO Speed limit
Support point-in-time recovery
Support compat Backup , Even if the index data is not backed up , Index in prepare when --rebuild-indexs
Backup support buffer pool
Support single table export, import To other libraries
Support rsync To shorten the locking time of backing up non transaction engine tables
1. Permissions required for physical backup
Use innobackupex/xtrabackup Make a backup , Permissions must be configured first . The required permissions are divided into two parts ：
1> System level permissions ： perform innobackupex/xtrabackup Ordered Linux Users need to be aware of mysql datadir And the directory where the backup is saved have read-write permission , Of course, you need to have permission to execute these commands ;
2>mysqld Level of authority ：innobackupex/xtrabackup --user=bkpuser This user bkpuser Refer to mysql.user Users in the table , Not system level users ; You need some basic permissions to perform the backup process ：
The most basic permissions ：
create user 'bkpuser'@'localhost' identified by 'xxx';
grant reload,lock tables,replication client on *.* to 'bkpuser'@'localhost';
These permissions can only complete ： be completely ready , Incremental backup , recovery ;
Generally, if partial backup is required ,export surface ,import surface , It also needs to be ：grant create tablespace on *.* to 'bkpuser'@'localhost';
If you need to optimize locks during backup , Prevent blocking of all DML The situation of , It will take ：
grant process,super on *.* to 'bkpuser'@'localhost';
([email protected])[(none)]mysql>show grants for 'bkpuser'@'localhost'\G
*************************** 1. row ***************************
Grants for [email protected]: GRANT RELOAD, PROCESS, SUPER, LOCK TABLES, REPLICATION CLIENT, CREATE TABLESPACE ON *.* TO 'bkpuser'@'localhost' IDENTIFIED BY PASSWORD '*BDC62F68AF8F0B8BFAE27FF782C5D8CE9F4BAFCB'
1 row in set (0.00 sec)
2. innobackupex Command options ：
[[email protected] ~]# innobackupex --help
Open source backup tool for InnoDB and XtraDB
[... ...]
innobackupex - Non-blocking backup tool for InnoDB, XtraDB and HailDB databases
SYNOPOSIS( Usage method )
innobackupex [--compress] [--compress-threads=NUMBER-OF-THREADS] [--compress-chunk-size=CHUNK-SIZE]
[--encrypt=ENCRYPTION-ALGORITHM] [--encrypt-threads=NUMBER-OF-THREADS] [--encrypt-chunk-size=CHUNK-SIZE]
[--encrypt-key=LITERAL-ENCRYPTION-KEY] | [--encryption-key-file=MY.KEY]
[--include=REGEXP] [--user=NAME]
[--password=WORD] [--port=PORT] [--socket=SOCKET]
[--no-timestamp] [--ibbackup=IBBACKUP-BINARY]
[--slave-info] [--galera-info] [--stream=tar|xbstream]
[--defaults-file=MY.CNF] [--defaults-group=GROUP-NAME]
[--databases=LIST] [--no-lock]
[--tmpdir=DIRECTORY] [--tables-file=FILE]
[--history=NAME]
[--incremental] [--incremental-basedir]
[--incremental-dir] [--incremental-force-scan] [--incremental-lsn]
[--incremental-history-name=NAME] [--incremental-history-uuid=UUID]
[--close-files] [--compact]
BACKUP-ROOT-DIR
innobackupex --apply-log [--use-memory=B]
[--defaults-file=MY.CNF]
[--export] [--redo-only] [--ibbackup=IBBACKUP-BINARY]
BACKUP-DIR
innobackupex --copy-back [--defaults-file=MY.CNF] [--defaults-group=GROUP-NAME] BACKUP-DIR
innobackupex --move-back [--defaults-file=MY.CNF] [--defaults-group=GROUP-NAME] BACKUP-DIR
innobackupex [--decompress] [--decrypt=ENCRYPTION-ALGORITHM]
[--encrypt-key=LITERAL-ENCRYPTION-KEY] | [--encryption-key-file=MY.KEY]
[--parallel=NUMBER-OF-FORKS] BACKUP-DIR
DESCRIPTION
The first command line above makes a hot backup of a MySQL database.
By default it creates a backup directory (named by the current date
and time) in the given backup root directory. With the --no-timestamp
option it does not create a time-stamped backup directory, but it puts
the backup in the given directory (which must not exist). This
command makes a complete backup of all MyISAM and InnoDB tables and
indexes in all databases or in all of the databases specified with the
--databases option. The created backup contains .frm, .MRG, .MYD,
.MYI, .MAD, .MAI, .TRG, .TRN, .ARM, .ARZ, .CSM, CSV, .opt, .par, and
InnoDB data and log files. The MY.CNF options file defines the
location of the database. This command connects to the MySQL server
using the mysql client program, and runs xtrabackup as a child
process.
The --apply-log command prepares a backup for starting a MySQL
server on the backup. This command recovers InnoDB data files as specified
in BACKUP-DIR/backup-my.cnf using BACKUP-DIR/xtrabackup_logfile,
and creates new InnoDB log files as specified in BACKUP-DIR/backup-my.cnf.
The BACKUP-DIR should be the path to a backup directory created by
xtrabackup. This command runs xtrabackup as a child process, but it does not
connect to the database server.
The --copy-back command copies data, index, and log files
from the backup directory back to their original locations.
The MY.CNF options file defines the original location of the database.
The BACKUP-DIR is the path to a backup directory created by xtrabackup.
The --move-back command is similar to --copy-back with the only difference that
it moves files to their original locations rather than copies them. As this
option removes backup files, it must be used with caution. It may be useful in
cases when there is not enough free disk space to copy files.
The --decompress --decrypt command will decrypt and/or decompress a backup made
with the --compress and/or --encrypt options. When decrypting, the encryption
algorithm and key used when the backup was taken MUST be provided via the
specified options. --decrypt and --decompress may be used together at the same
time to completely normalize a previously compressed and encrypted backup. The
--parallel option will allow multiple files to be decrypted and/or decompressed
simultaneously. In order to decompress, the qpress utility MUST be installed
and accessable within the path. This process will remove the original
compressed/encrypted files and leave the results in the same location.
On success the exit code innobackupex is 0. A non-zero exit code
indicates an error.
Usage: [innobackupex [--defaults-file=#] --backup | innobackupex [--defaults-file=#] --prepare] [OPTIONS]
-v, --version print xtrabackup version information
-?, --help This option displays a help screen and exits.
--apply-log Prepare a backup in BACKUP-DIR by applying the
transaction log file named "xtrabackup_logfile" located
in the same directory. Also, create new transaction logs.
The InnoDB configuration is read from the file
"backup-my.cnf".
--redo-only This option should be used when preparing the base full
backup and when merging all incrementals except the last
one. This forces xtrabackup to skip the "rollback" phase
and do a "redo" only. This is necessary if the backup
will have incremental changes applied to it later. See
the xtrabackup documentation for details.
--copy-back Copy all the files in a previously made backup from the
backup directory to their original locations.
--move-back Move all the files in a previously made backup from the
backup directory to the actual datadir location. Use with
caution, as it removes backup files.
--galera-info This options creates the xtrabackup_galera_info file
which contains the local node state at the time of the
backup. Option should be used when performing the backup
of Percona-XtraDB-Cluster. Has no effect when backup
locks are used to create the backup.
--slave-info This option is useful when backing up a replication slave
server. It prints the binary log position and name of the
master server. It also writes this information to the
"xtrabackup_slave_info" file as a "CHANGE MASTER"
command. A new slave for this master can be set up by
starting a slave server on this backup and issuing a
"CHANGE MASTER" command with the binary log position
saved in the "xtrabackup_slave_info" file.
--incremental This option tells xtrabackup to create an incremental
backup, rather than a full one. It is passed to the
xtrabackup child process. When this option is specified,
either --incremental-lsn or --incremental-basedir can
also be given. If neither option is given, option
--incremental-basedir is passed to xtrabackup by default,
set to the first timestamped backup directory in the
backup base directory.
--no-lock Use this option to disable table lock with "FLUSH TABLES
WITH READ LOCK". Use it only if ALL your tables are
InnoDB and you DO NOT CARE about the binary log position
of the backup. This option shouldn't be used if there are
any DDL statements being executed or if any updates are
happening on non-InnoDB tables (this includes the system
MyISAM tables in the mysql database), otherwise it could
lead to an inconsistent backup. If you are considering to
use --no-lock because your backups are failing to acquire
the lock, this could be because of incoming replication
events preventing the lock from succeeding. Please try
using --safe-slave-backup to momentarily stop the
replication slave thread, this may help the backup to
succeed and you then don't need to resort to using this
option.
--safe-slave-backup Stop slave SQL thread and wait to start backup until
Slave_open_temp_tables in "SHOW STATUS" is zero. If there
are no open temporary tables, the backup will take place,
otherwise the SQL thread will be started and stopped
until there are no open temporary tables. The backup will
fail if Slave_open_temp_tables does not become zero after
--safe-slave-backup-timeout seconds. The slave SQL thread
will be restarted when the backup finishes.
--rsync Uses the rsync utility to optimize local file transfers.
When this option is specified, innobackupex uses rsync to
copy all non-InnoDB files instead of spawning a separate
cp for each file, which can be much faster for servers
with a large number of databases or tables. This option
cannot be used together with --stream.
--force-non-empty-directories
This option, when specified, makes --copy-back or
--move-back transfer files to non-empty directories. Note
that no existing files will be overwritten. If
--copy-back or --nove-back has to copy a file from the
backup directory which already exists in the destination
directory, it will still fail with an error.
--no-timestamp This option prevents creation of a time-stamped
subdirectory of the BACKUP-ROOT-DIR given on the command
line. When it is specified, the backup is done in
BACKUP-ROOT-DIR instead.
--no-version-check This option disables the version check which is enabled
by the --version-check option.
--no-backup-locks This option controls if backup locks should be used
instead of FLUSH TABLES WITH READ LOCK on the backup
stage. The option has no effect when backup locks are not
supported by the server. This option is enabled by
default, disable with --no-backup-locks.
--decompress Decompresses all files with the .qp extension in a backup
previously made with the --compress option.
--user=name This option specifies the MySQL username used when
connecting to the server, if that's not the current user.
The option accepts a string argument. See mysql --help
for details.
--host=name This option specifies the host to use when connecting to
the database server with TCP/IP. The option accepts a
string argument. See mysql --help for details.
--port=# This option specifies the port to use when connecting to
the database server with TCP/IP. The option accepts a
string argument. See mysql --help for details.
--password=name This option specifies the password to use when connecting
to the database. It accepts a string argument. See mysql
--help for details.
--socket=name This option specifies the socket to use when connecting
to the local database server with a UNIX domain socket.
The option accepts a string argument. See mysql --help
for details.
--incremental-history-name=name
This option specifies the name of the backup series
stored in the PERCONA_SCHEMA.xtrabackup_history history
record to base an incremental backup on. Xtrabackup will
search the history table looking for the most recent
(highest innodb_to_lsn), successful backup in the series
and take the to_lsn value to use as the starting lsn for
the incremental backup. This will be mutually exclusive
with --incremental-history-uuid, --incremental-basedir
and --incremental-lsn. If no valid lsn can be found (no
series by that name, no successful backups by that name)
xtrabackup will return with an error. It is used with the
--incremental option.
--incremental-history-uuid=name
This option specifies the UUID of the specific history
record stored in the PERCONA_SCHEMA.xtrabackup_history to
base an incremental backup on.
--incremental-history-name, --incremental-basedir and
--incremental-lsn. If no valid lsn can be found (no
success record with that uuid) xtrabackup will return
with an error. It is used with the --incremental option.
--decrypt=name Decrypts all files with the .xbcrypt extension in a
backup previously made with --encrypt option.
--ftwrl-wait-query-type=name
This option specifies which types of queries are allowed
to complete before innobackupex will issue the global
lock. Default is all.
--kill-long-query-type=name
This option specifies which types of queries should be
killed to unblock the global lock. Default is "all".
--history[=name] This option enables the tracking of backup history in the
PERCONA_SCHEMA.xtrabackup_history table. An optional
history series name may be specified that will be placed
with the history record for the current backup being
taken.
--include=name This option is a regular expression to be matched against
table names in databasename.tablename format. It is
passed directly to xtrabackup's --tables option. See the
xtrabackup documentation for details.
--databases=name This option specifies the list of databases that
innobackupex should back up. The option accepts a string
argument or path to file that contains the list of
databases to back up. The list is of the form
"databasename1[.table_name1] databasename2[.table_name2]
. . .". If this option is not specified, all databases
containing MyISAM and InnoDB tables will be backed up.
Please make sure that --databases contains all of the
InnoDB databases and tables, so that all of the
innodb.frm files are also backed up. In case the list is
very long, this can be specified in a file, and the full
path of the file can be specified instead of the list.
(See option --tables-file.)
--kill-long-queries-timeout=#
This option specifies the number of seconds innobackupex
waits between starting FLUSH TABLES WITH READ LOCK and
killing those queries that block it. Default is 0
seconds, which means innobackupex will not attempt to
kill any queries.
--ftwrl-wait-timeout=#
This option specifies time in seconds that innobackupex
should wait for queries that would block FTWRL before
running it. If there are still such queries when the
timeout expires, innobackupex terminates with an error.
Default is 0, in which case innobackupex does not wait
for queries to complete and starts FTWRL immediately.
--ftwrl-wait-threshold=#
This option specifies the query run time threshold which
is used by innobackupex to detect long-running queries
with a non-zero value of --ftwrl-wait-timeout. FTWRL is
not started until such long-running queries exist. This
option has no effect if --ftwrl-wait-timeout is 0.
Default value is 60 seconds.
--debug-sleep-before-unlock=#
This is a debug-only option used by the XtraBackup test
suite.
--safe-slave-backup-timeout=#
How many seconds --safe-slave-backup should wait for
Slave_open_temp_tables to become zero. (default 300)
--close-files Do not keep files opened. This option is passed directly
to xtrabackup. Use at your own risk.
--compact Create a compact backup with all secondary index pages
omitted. This option is passed directly to xtrabackup.
See xtrabackup documentation for details.
--compress[=name] This option instructs xtrabackup to compress backup
copies of InnoDB data files. It is passed directly to the
xtrabackup child process. Try 'xtrabackup --help' for
more details.
--compress-threads=#
This option specifies the number of worker threads that
will be used for parallel compression. It is passed
directly to the xtrabackup child process. Try 'xtrabackup
--help' for more details.
--compress-chunk-size=#
Size of working buffer(s) for compression threads in
bytes. The default value is 64K.
--encrypt=name This option instructs xtrabackup to encrypt backup copies
of InnoDB data files using the algorithm specified in the
ENCRYPTION-ALGORITHM. It is passed directly to the
xtrabackup child process. Try 'xtrabackup --help' for
more details.
--encrypt-key=name This option instructs xtrabackup to use the given
ENCRYPTION-KEY when using the --encrypt or --decrypt
options. During backup it is passed directly to the
xtrabackup child process. Try 'xtrabackup --help' for
more details.
--encrypt-key-file=name
This option instructs xtrabackup to use the encryption
key stored in the given ENCRYPTION-KEY-FILE when using
the --encrypt or --decrypt options.
--encrypt-threads=# This option specifies the number of worker threads that
will be used for parallel encryption. It is passed
directly to the xtrabackup child process. Try 'xtrabackup
--help' for more details.
--encrypt-chunk-size=#
This option specifies the size of the internal working
buffer for each encryption thread, measured in bytes. It
is passed directly to the xtrabackup child process. Try
'xtrabackup --help' for more details.
--export This option is passed directly to xtrabackup's --export
option. It enables exporting individual tables for import
into another server. See the xtrabackup documentation for
details.
--extra-lsndir=name This option specifies the directory in which to save an
extra copy of the "xtrabackup_checkpoints" file. The
option accepts a string argument. It is passed directly
to xtrabackup's --extra-lsndir option. See the xtrabackup
documentation for details.
--incremental-basedir=name
This option specifies the directory containing the full
backup that is the base dataset for the incremental
backup. The option accepts a string argument. It is used
with the --incremental option.
--incremental-dir=name
This option specifies the directory where the incremental
backup will be combined with the full backup to make a
new full backup. The option accepts a string argument.
It is used with the --incremental option.
--incremental-force-scan
This options tells xtrabackup to perform full scan of
data files for taking an incremental backup even if full
changed page bitmap data is available to enable the
backup without the full scan.
--log-copy-interval=#
This option specifies time interval between checks done
by log copying thread in milliseconds.
--incremental-lsn=name
This option specifies the log sequence number (LSN) to
use for the incremental backup. The option accepts a
string argument. It is used with the --incremental
option. It is used instead of specifying
--incremental-basedir. For databases created by MySQL and
Percona Server 5.0-series versions, specify the LSN as
two 32-bit integers in high:low format. For databases
created in 5.1 and later, specify the LSN as a single
64-bit integer.
--parallel=# On backup, this option specifies the number of threads
the xtrabackup child process should use to back up files
concurrently. The option accepts an integer argument. It
is passed directly to xtrabackup's --parallel option. See
the xtrabackup documentation for details.
--rebuild-indexes This option only has effect when used together with the
--apply-log option and is passed directly to xtrabackup.
When used, makes xtrabackup rebuild all secondary indexes
after applying the log. This option is normally used to
prepare compact backups. See the XtraBackup manual for
more information.
--rebuild-threads=# Use this number of threads to rebuild indexes in a
compact backup. Only has effect with --prepare and
--rebuild-indexes.
--stream=name This option specifies the format in which to do the
streamed backup. The option accepts a string argument.
The backup will be done to STDOUT in the specified
format. Currently, the only supported formats are tar and
xbstream. This option is passed directly to xtrabackup's
--stream option.
--tables-file=name This option specifies the file in which there are a list
of names of the form database. The option accepts a
string argument.table, one per line. The option is passed
directly to xtrabackup's --tables-file option.
--throttle=# This option specifies a number of I/O operations (pairs
of read+write) per second. It accepts an integer
argument. It is passed directly to xtrabackup's
--throttle option.
-t, --tmpdir=name This option specifies the location where a temporary
files will be stored. If the option is not specified, the
default is to use the value of tmpdir read from the
server configuration.
--use-memory=# This option accepts a string argument that specifies the
amount of memory in bytes for xtrabackup to use for crash
recovery while preparing a backup. Multiples are
supported providing the unit (e.g. 1MB, 1GB). It is used
only with the option --apply-log. It is passed directly
to xtrabackup's --use-memory option. See the xtrabackup
documentation for details.
[[email protected] ~]#
3. Use innobackupex Backup
3.1 be completely ready
( Here the system level uses root User backup ,msyql The layer uses bkpuser user ,root Need to be right datadir /var/lib/mysql, Backup directory /backup/xtrabackup/full Have read and write permissions to execute ;bkpuser It also needs to be in mysql There are relevant permissions in )
[ [email protected] ~]# innobackupex /backup/xtrabackup/full --user=bkpuser --password=digdeep
[[email protected] ~]# innobackupex /backup/xtrabackup/full --user=bkpuser --password=digdeep
151105 22:38:55 innobackupex: Starting the backup operation
IMPORTANT: Please check that the backup run completes successfully.
At the end of a successful backup run innobackupex
prints "completed OK!".
151105 22:38:55 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;mysql_socket=/tmp/mysql.sock' as 'bkpuser' (using password: YES).
151105 22:38:56 version_check Connected to MySQL server
151105 22:38:56 version_check Executing a version check against the server...
151105 22:38:56 version_check Done.
151105 22:38:56 Connecting to MySQL server host: localhost, user: bkpuser, password: set, port: 0, socket: /tmp/mysql.sock
Using server version 5.6.26-log
innobackupex version 2.3.2 based on MySQL server 5.6.24 Linux (i686) (revision id: 306a2e0)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: open files limit requested 0, set to 10240
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 50331648
151105 22:38:56 >> log scanned up to (731470240)
xtrabackup: Generating a list of tablespaces
151105 22:38:56 [01] Copying ./ibdata1 to /backup/xtrabackup/full/2015-11-05_22-38-55/ibdata1
151105 22:38:57 >> log scanned up to (731470240)
151105 22:38:58 >> log scanned up to (731470240)
151105 22:38:58 [01] ...done
151105 22:38:58 [01] Copying ./mysql/slave_master_info.ibd to /backup/xtrabackup/full/2015-11-05_22-38-55/mysql/slave_master_info.ibd
151105 22:38:58 [01] ...done
151105 22:38:58 [01] Copying ./mysql/innodb_index_stats.ibd to /backup/xtrabackup/full/2015-11-05_22-38-55/mysql/innodb_index_stats.ibd
151105 22:38:58 [01] ...done
[... ...]
151105 22:38:59 [01] Copying ./aazj/group_union.ibd to /backup/xtrabackup/full/2015-11-05_22-38-55/aazj/group_union.ibd
151105 22:38:59 [01] ...done
151105 22:38:59 [01] Copying ./aazj/SYS_PARAM.ibd to /backup/xtrabackup/full/2015-11-05_22-38-55/aazj/SYS_PARAM.ibd
151105 22:38:59 >> log scanned up to (731470240)
151105 22:38:59 [01] ...done
151105 22:38:59 [01] Copying ./aazj/GroupBlog.ibd to /backup/xtrabackup/full/2015-11-05_22-38-55/aazj/GroupBlog.ibd
151105 22:38:59 [01] ...done
[... ...]
151105 22:39:01 [01] Copying ./aazj/Accounting_paylog.ibd to /backup/xtrabackup/full/2015-11-05_22-38-55/aazj/Accounting_paylog.ibd
151105 22:39:01 [01] ...done
151105 22:39:01 [01] Copying ./aazj/Customer.ibd to /backup/xtrabackup/full/2015-11-05_22-38-55/aazj/Customer.ibd
151105 22:39:01 [01] ...done
151105 22:39:01 [01] Copying ./aazj/uuu.ibd to /backup/xtrabackup/full/2015-11-05_22-38-55/aazj/uuu.ibd
151105 22:39:02 >> log scanned up to (731634905)
151105 22:39:03 >> log scanned up to (731634905)
151105 22:39:04 >> log scanned up to (731634905)
151105 22:39:04 [01] ...done
151105 22:39:04 [01] Copying ./aazj/Members.ibd to /backup/xtrabackup/full/2015-11-05_22-38-55/aazj/Members.ibd
151105 22:39:05 [01] ...done
151105 22:39:05 [01] Copying ./aazj/tttt.ibd to /backup/xtrabackup/full/2015-11-05_22-38-55/aazj/tttt.ibd
151105 22:39:05 [01] ...done
151105 22:39:05 [01] Copying ./aazj/uu_test.ibd to /backup/xtrabackup/full/2015-11-05_22-38-55/aazj/uu_test.ibd
151105 22:39:05 >> log scanned up to (731634905)
151105 22:39:06 >> log scanned up to (731685874)
151105 22:39:07 >> log scanned up to (731686008)
151105 22:39:08 >> log scanned up to (731686008)
151105 22:39:08 [01] ...done
151105 22:39:08 [01] Copying ./aazj/Mess_Receive.ibd to /backup/xtrabackup/full/2015-11-05_22-38-55/aazj/Mess_Receive.ibd
151105 22:39:09 [01] ...done
[... ...]
151105 22:39:09 >> log scanned up to (731686008)
Executing FLUSH NO_WRITE_TO_BINLOG TABLES...
151105 22:39:09 Executing FLUSH TABLES WITH READ LOCK...
151105 22:39:09 Starting to backup non-InnoDB tables and files
151105 22:39:09 [01] Copying ./mysql/columns_priv.frm to /backup/xtrabackup/full/2015-11-05_22-38-55/mysql/columns_priv.frm
151105 22:39:09 [01] ...done
151105 22:39:09 [01] Copying ./mysql/user.MYI to /backup/xtrabackup/full/2015-11-05_22-38-55/mysql/user.MYI
151105 22:39:09 [01] ...done
[... ...]
151105 22:39:10 [01] Copying ./mysql/help_category.frm to /backup/xtrabackup/full/2015-11-05_22-38-55/mysql/help_category.frm
151105 22:39:10 [01] ...done
151105 22:39:10 >> log scanned up to (731686008)
151105 22:39:10 [01] Copying ./mysql/proc.MYD to /backup/xtrabackup/full/2015-11-05_22-38-55/mysql/proc.MYD
151105 22:39:10 [01] ...done
[... ...]
151105 22:39:10 [01] ...done
151105 22:39:10 [01] Copying ./mysql/proxies_priv.MYI to /backup/xtrabackup/full/2015-11-05_22-38-55/mysql/proxies_priv.MYI
151105 22:39:10 [01] ...done
151105 22:39:10 [01] Copying ./aazj/model_order.frm to /backup/xtrabackup/full/2015-11-05_22-38-55/aazj/model_order.frm
151105 22:39:10 [01] ...done
151105 22:39:10 [01] Copying ./aazj/Comment.frm to /backup/xtrabackup/full/2015-11-05_22-38-55/aazj/Comment.frm
151105 22:39:10 [01] ...done
[... ...]
151105 22:39:11 [01] Copying ./performance_schema/events_waits_summary_by_host_by_event_name.frm to /backup/xtrabackup/full/2015-11-05_22-38-55/performance_schema/events_waits_summary_by_host_by_event_name.frm
151105 22:39:11 [01] ...done
[... ...]
151105 22:39:11 [01] Copying ./performance_schema/events_statements_summary_by_account_by_event_name.frm to /backup/xtrabackup/full/2015-11-05_22-38-55/performance_schema/events_statements_summary_by_account_by_event_name.frm
151105 22:39:11 [01] ...done
151105 22:39:11 [01] Copying ./t/city.frm to /backup/xtrabackup/full/2015-11-05_22-38-55/t/city.frm
151105 22:39:11 [01] ...done
151105 22:39:11 [01] Copying ./t/db.opt to /backup/xtrabackup/full/2015-11-05_22-38-55/t/db.opt
151105 22:39:11 [01] ...done
151105 22:39:11 [01] Copying ./t/t.frm to /backup/xtrabackup/full/2015-11-05_22-38-55/t/t.frm
151105 22:39:11 [01] ...done
151105 22:39:11 Finished backing up non-InnoDB tables and files
151105 22:39:11 [00] Writing xtrabackup_binlog_info
151105 22:39:11 [00] ...done
151105 22:39:11 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '731686008'
xtrabackup: Stopping log copying thread.
.151105 22:39:11 >> log scanned up to (731686008)
151105 22:39:11 Executing UNLOCK TABLES
151105 22:39:11 All tables unlocked
151105 22:39:11 Backup created in directory '/backup/xtrabackup/full/2015-11-05_22-38-55'
MySQL binlog position: filename 'mysql-bin.000015', position '117940'
151105 22:39:11 [00] Writing backup-my.cnf
151105 22:39:11 [00] ...done
151105 22:39:11 [00] Writing xtrabackup_info
151105 22:39:11 [00] ...done
xtrabackup: Transaction log of lsn (731470240) to (731686008) was copied.
151105 22:39:11 completed OK!
3.2 recovery
1> First step prepare( two prepare, Generated during the first application backup redo log, Roll forward and rollback ：replay stay redo log Committed transactions in ,rollback Uncommitted transactions )
Pay attention to the path here , Must include the last one timestamp Catalog , Otherwise, the following mistakes will be made ：
[[email protected] ~]# innobackupex --apply-log /backup/xtrabackup/full/ --user=bkpuser --password=digdeep
151106 10:41:48 innobackupex: Starting the apply-log operation
IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex
prints "completed OK!".
innobackupex version 2.3.2 based on MySQL server 5.6.24 Linux (i686) (revision id: 306a2e0)
xtrabackup: cd to /backup/xtrabackup/full
xtrabackup: Error: cannot open ./xtrabackup_checkpoints
xtrabackup: error: xtrabackup_read_metadata()
xtrabackup: This target seems not to have correct metadata...
2015-11-06 10:41:48 b771e6d0 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
xtrabackup: Warning: cannot open ./xtrabackup_logfile. will try to find.
2015-11-06 10:41:48 b771e6d0 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
xtrabackup: Fatal error: cannot find ./xtrabackup_logfile.
xtrabackup: Error: xtrabackup_init_temp_log() failed.
--apply-log Would call xtrabackup --prepare two , First roll forward and rollback , Second generation iblogfile[0|1]
[ [email protected] ~]# innobackupex --apply-log /backup/xtrabackup/full/2015-11-05_22-38-55/ --user=bkpuser --password=digdeep
[[email protected] ~]# innobackupex --apply-log /backup/xtrabackup/full/2015-11-05_22-38-55/ --user=bkpuser --password=digdeep
151106 10:43:32 innobackupex: Starting the apply-log operation
IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex
prints "completed OK!".
innobackupex version 2.3.2 based on MySQL server 5.6.24 Linux (i686) (revision id: 306a2e0)
xtrabackup: cd to /backup/xtrabackup/full/2015-11-05_22-38-55/
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(731470240)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Not using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 731470240
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages
InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 731686008 (11%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: 128 rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.6.24 started; log sequence number 731686008
xtrabackup: Last MySQL binlog file position 117940, file name mysql-bin.000015 ()
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 731724574
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 50331648
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Not using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Setting log file ./ib_logfile101 size to 48 MB
InnoDB: Setting log file ./ib_logfile1 size to 48 MB
InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
InnoDB: New log files created, LSN=731724574
InnoDB: Highest supported file format is Barracuda.
InnoDB: 128 rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.6.24 started; log sequence number 731724812
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 731724822
151106 10:43:40 completed OK!
[[email protected] ~]#
3.3 recovery --copy-back
Put it directly above prepare OK, all the documents , Copied to the mysqld Of datadir Catalog ( Will read my.cnf Configuration information in ).
--copy--back Precautions for ：
1> datadir It has to be empty , Or use --force-non-empty-directories Options ;
2> mysqld Must close , If it is --import Partial recovery , Cannot close ;
3> --copy-back When it's done , Need modification datadir Directory file permissions ： chown -R mysql:mysql /var/lib/mysql
[ [email protected] ~]# mysqladmin -uroot -pxxx shutdown ( close mysqld)
[ [email protected] ~]# cd /var/lib/mysql
[ [email protected] mysql]# ls
aazj ib_logfile1 mysql-bin.000003 mysql-bin.000008 mysql-bin.000013 performance_schema
auto.cnf localhost-slow.log mysql-bin.000004 mysql-bin.000009 mysql-bin.000014 t
general.log mysql mysql-bin.000005 mysql-bin.000010 mysql-bin.000015 xtrabackup_binlog_pos_innodb
ibdata1 mysql-bin.000001 mysql-bin.000006 mysql-bin.000011 mysql-bin.000016 xtrabackup_info
ib_logfile0 mysql-bin.000002 mysql-bin.000007 mysql-bin.000012 mysql-bin.index
[ [email protected] mysql]# mv * /backup/xtrabackup/ ( To empty )
[ [email protected] mysql]# ls
[ [email protected] mysql]# innobackupex --copy-back /backup/xtrabackup/full/2015-11-05_22-38-55/ --user=bkpuser --password=digdeep
[[email protected] mysql]# innobackupex --copy-back /backup/xtrabackup/full/2015-11-05_22-38-55/ --user=bkpuser --password=digdeep
151106 11:07:38 innobackupex: Starting the copy-back operation
IMPORTANT: Please check that the copy-back run completes successfully.
At the end of a successful copy-back run innobackupex
prints "completed OK!".
innobackupex version 2.3.2 based on MySQL server 5.6.24 Linux (i686) (revision id: 306a2e0)
151106 11:07:38 [01] Copying ib_logfile0 to /var/lib/mysql/ib_logfile0
151106 11:07:40 [01] ...done
151106 11:07:40 [01] Copying ib_logfile1 to /var/lib/mysql/ib_logfile1
151106 11:07:41 [01] ...done
151106 11:07:41 [01] Copying ibdata1 to /var/lib/mysql/ibdata1
151106 11:07:45 [01] ...done
151106 11:07:45 [01] Copying ./xtrabackup_info to /var/lib/mysql/xtrabackup_info
151106 11:07:45 [01] ...done
151106 11:07:45 [01] Copying ./mysql/slave_master_info.ibd to /var/lib/mysql/mysql/slave_master_info.ibd
151106 11:07:45 [01] ...done
[... ...]
151106 11:07:57 [01] Copying ./t/db.opt to /var/lib/mysql/t/db.opt
151106 11:07:57 [01] ...done
151106 11:07:57 [01] Copying ./t/t.frm to /var/lib/mysql/t/t.frm
151106 11:07:57 [01] ...done
151106 11:07:57 completed OK!
[[email protected] mysql]# pwd
/var/lib/mysql
[[email protected] mysql]# ls
aazj ibdata1 ib_logfile0 ib_logfile1 mysql performance_schema t xtrabackup_binlog_pos_innodb xtrabackup_info
You can see that after recovery , No, binlog Document box index file
start-up myqld You need to modify permissions before ：
[[email protected] mysql]# ls -l
total 176164
drwx------ 2 root root 4096 Nov 6 11:07 aazj
-rw-rw---- 1 mysql mysql 543 Nov 6 11:13 general.log
-rw-r----- 1 root root 79691776 Nov 6 11:07 ibdata1
-rw-r----- 1 root root 50331648 Nov 6 11:07 ib_logfile0
-rw-r----- 1 root root 50331648 Nov 6 11:07 ib_logfile1
-rw-rw---- 1 mysql mysql 543 Nov 6 11:13 localhost-slow.log
drwx------ 2 root root 4096 Nov 6 11:07 mysql
-rw-rw---- 1 mysql mysql 0 Nov 6 11:12 mysql-bin.index
drwx------ 2 root root 4096 Nov 6 11:07 performance_schema
drwx------ 2 root root 4096 Nov 6 11:07 t
-rw-r----- 1 root root 24 Nov 6 11:07 xtrabackup_binlog_pos_innodb
-rw-r----- 1 root root 487 Nov 6 11:07 xtrabackup_info
[[email protected] mysql]# chown -R mysql:mysql /var/lib/mysql
[[email protected] mysql]# ls -l
total 176164
drwx------ 2 mysql mysql 4096 Nov 6 11:07 aazj
-rw-rw---- 1 mysql mysql 543 Nov 6 11:13 general.log
-rw-r----- 1 mysql mysql 79691776 Nov 6 11:07 ibdata1
-rw-r----- 1 mysql mysql 50331648 Nov 6 11:07 ib_logfile0
-rw-r----- 1 mysql mysql 50331648 Nov 6 11:07 ib_logfile1
-rw-rw---- 1 mysql mysql 543 Nov 6 11:13 localhost-slow.log
drwx------ 2 mysql mysql 4096 Nov 6 11:07 mysql
-rw-rw---- 1 mysql mysql 0 Nov 6 11:12 mysql-bin.index
drwx------ 2 mysql mysql 4096 Nov 6 11:07 performance_schema
drwx------ 2 mysql mysql 4096 Nov 6 11:07 t
-rw-r----- 1 mysql mysql 24 Nov 6 11:07 xtrabackup_binlog_pos_innodb
-rw-r----- 1 mysql mysql 487 Nov 6 11:07 xtrabackup_info
Otherwise, the startup will be in error.log Error reported in ：
2015-11-06 11:13:55 3542 [ERROR] InnoDB: ./ibdata1 can't be opened in read-write mode
2015-11-06 11:13:55 3542 [ERROR] InnoDB: The system tablespace must be writable!
2015-11-06 11:13:55 3542 [ERROR] Plugin 'InnoDB' init function returned error.
2015-11-06 11:13:55 3542 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2015-11-06 11:13:55 3542 [ERROR] Unknown/unsupported storage engine: InnoDB
2015-11-06 11:13:55 3542 [ERROR] Aborting
After successful startup ,datadir Various files in the directory have been generated ：
[ [email protected] mysql]# pwd
/var/lib/mysql
[ [email protected] mysql]# ls
aazj general.log ib_logfile0 localhost-slow.log mysql-bin.000001 performance_schema xtrabackup_binlog_pos_innodb
auto.cnf ibdata1 ib_logfile1 mysql mysql-bin.index t xtrabackup_info
3.4 innobackupex Incremental backup
Before incremental backup , A full backup system must be established , The first incremental backup is based on full backup , The second incremental backup is based on the first incremental backup , One analogy
be completely ready ：
[ [email protected] mysql]# innobackupex --user=bkpuser --password=digdeep /backup/xtrabackup/full
[[email protected] mysql]# innobackupex --user=bkpuser --password=digdeep /backup/xtrabackup/full
First incremental backup :
--incremental /backup/xtrabackup/incr1/ Specify the location of the incremental backup ;
--incremental-basedir= Specify the last full backup or incremental backup ：
[[email protected] mysql]# innobackupex --incremental /backup/xtrabackup/incr1/ --incremental-basedir=/backup/xtrabackup/full/2015-11-06_11-29-51/ --user=bkpuser --password=digdeep
151106 11:33:16 innobackupex: Starting the backup operation
IMPORTANT: Please check that the backup run completes successfully.
At the end of a successful backup run innobackupex
prints "completed OK!".
151106 11:33:16 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;mysql_socket=/tmp/mysql.sock' as 'bkpuser' (using password: YES).
151106 11:33:16 version_check Connected to MySQL server
151106 11:33:16 version_check Executing a version check against the server...
151106 11:33:16 version_check Done.
151106 11:33:16 Connecting to MySQL server host: localhost, user: bkpuser, password: set, port: 0, socket: /tmp/mysql.sock
Using server version 5.6.26-log
innobackupex version 2.3.2 based on MySQL server 5.6.24 Linux (i686) (revision id: 306a2e0)
incremental backup from 731724832 is enabled.
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: open files limit requested 0, set to 10240
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 50331648
151106 11:33:16 >> log scanned up to (732153217)
xtrabackup: Generating a list of tablespaces
xtrabackup: using the full scan for incremental backup
151106 11:33:17 [01] Copying ./ibdata1 to /backup/xtrabackup/incr1//2015-11-06_11-33-16/ibdata1.delta
151106 11:33:17 >> log scanned up to (732153217)
151106 11:33:18 [01] ...done
151106 11:33:18 >> log scanned up to (732153217)
151106 11:33:18 [01] Copying ./mysql/slave_master_info.ibd to /backup/xtrabackup/incr1//2015-11-06_11-33-16/mysql/slave_master_info.ibd.delta
151106 11:33:18 [01] ...done
151106 11:33:19 >> log scanned up to (732153217)
[... ...]
151106 11:33:30 [01] Copying ./aazj/Configuration.ibd to /backup/xtrabackup/incr1//2015-11-06_11-33-16/aazj/Configuration.ibd.delta
151106 11:33:30 [01] ...done
151106 11:33:31 [01] Copying ./aazj/lx_test.ibd to /backup/xtrabackup/incr1//2015-11-06_11-33-16/aazj/lx_test.ibd.delta
151106 11:33:31 >> log scanned up to (732231774)
151106 11:33:32 [01] ...done
151106 11:33:32 >> log scanned up to (732231774)
151106 11:33:32 [01] Copying ./aazj/Users.ibd to /backup/xtrabackup/incr1//2015-11-06_11-33-16/aazj/Users.ibd.delta
151106 11:33:32 [01] ...done
[... ...]
151106 11:33:42 [01] Copying ./aazj/tttt.ibd to /backup/xtrabackup/incr1//2015-11-06_11-33-16/aazj/tttt.ibd.delta
151106 11:33:42 [01] ...done
151106 11:33:42 >> log scanned up to (732501432)
151106 11:33:42 [01] Copying ./aazj/uu_test.ibd to /backup/xtrabackup/incr1//2015-11-06_11-33-16/aazj/uu_test.ibd.delta
[... ...]
151106 11:33:47 [01] Copying ./t/t.ibd to /backup/xtrabackup/incr1//2015-11-06_11-33-16/t/t.ibd.delta
151106 11:33:48 [01] ...done
151106 11:33:48 >> log scanned up to (732501432)
Executing FLUSH NO_WRITE_TO_BINLOG TABLES...
151106 11:33:48 Executing FLUSH TABLES WITH READ LOCK...
151106 11:33:48 Starting to backup non-InnoDB tables and files
151106 11:33:48 [01] Copying ./mysql/columns_priv.frm to /backup/xtrabackup/incr1//2015-11-06_11-33-16/mysql/columns_priv.frm
151106 11:33:48 [01] ...done
[... ...]
151106 11:33:51 [01] Copying ./t/t.frm to /backup/xtrabackup/incr1//2015-11-06_11-33-16/t/t.frm
151106 11:33:51 [01] ...done
151106 11:33:51 Finished backing up non-InnoDB tables and files
151106 11:33:51 [00] Writing xtrabackup_binlog_info
151106 11:33:51 [00] ...done
151106 11:33:51 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '732501432'
xtrabackup: Stopping log copying thread.
.151106 11:33:51 >> log scanned up to (732501432)
151106 11:33:51 Executing UNLOCK TABLES
151106 11:33:51 All tables unlocked
151106 11:33:51 Backup created in directory '/backup/xtrabackup/incr1//2015-11-06_11-33-16'
MySQL binlog position: filename 'mysql-bin.000001', position '157893'
151106 11:33:51 [00] Writing backup-my.cnf
151106 11:33:51 [00] ...done
151106 11:33:51 [00] Writing xtrabackup_info
151106 11:33:51 [00] ...done
xtrabackup: Transaction log of lsn (732153217) to (732501432) was copied.
151106 11:33:51 completed OK!
[[email protected] mysql]#
Second incremental backup :
[ [email protected] mysql]# innobackupex --incremental /backup/xtrabackup/incr2 --incremental-basedir=/backup/xtrabackup/incr1/2015-11-06_11-33-16/ --user=bkpuser --password=digdeep
[[email protected] mysql]# innobackupex --incremental /backup/xtrabackup/incr2 --incremental-basedir=/backup/xtrabackup/incr1/2015-11-06_11-33-16/ --user=bkpuser --password=digdeep
151106 11:43:22 innobackupex: Starting the backup operation
IMPORTANT: Please check that the backup run completes successfully.
At the end of a successful backup run innobackupex
prints "completed OK!".
151106 11:43:22 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;mysql_socket=/tmp/mysql.sock' as 'bkpuser' (using password: YES).
151106 11:43:22 version_check Connected to MySQL server
151106 11:43:22 version_check Executing a version check against the server...
151106 11:43:22 version_check Done.
151106 11:43:22 Connecting to MySQL server host: localhost, user: bkpuser, password: set, port: 0, socket: /tmp/mysql.sock
Using server version 5.6.26-log
innobackupex version 2.3.2 based on MySQL server 5.6.24 Linux (i686) (revision id: 306a2e0)
incremental backup from 732501432 is enabled.
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: open files limit requested 0, set to 10240
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 50331648
151106 11:43:23 >> log scanned up to (732501432)
xtrabackup: Generating a list of tablespaces
151106 11:43:23 [01] Copying ./ibdata1 to /backup/xtrabackup/incr2/2015-11-06_11-43-22/ibdata1.delta
151106 11:43:23 [01] ...done
151106 11:43:24 >> log scanned up to (732552856)
151106 11:43:24 [01] Copying ./mysql/slave_master_info.ibd to /backup/xtrabackup/incr2/2015-11-06_11-43-22/mysql/slave_master_info.ibd.delta
151106 11:43:24 [01] ...done
151106 11:43:25 >> log scanned up to (732552974)
151106 11:43:25 [01] Copying ./mysql/innodb_index_stats.ibd to /backup/xtrabackup/incr2/2015-11-06_11-43-22/mysql/innodb_index_stats.ibd.delta
151106 11:43:25 [01] ...done
151106 11:43:25 [01] Copying ./mysql/slave_relay_log_info.ibd to /backup/xtrabackup/incr2/2015-11-06_11-43-22/mysql/slave_relay_log_info.ibd.delta
151106 11:43:25 [01] ...done
151106 11:43:26 >> log scanned up to (732552974)
151106 11:43:26 [01] Copying ./mysql/slave_worker_info.ibd to /backup/xtrabackup/incr2/2015-11-06_11-43-22/mysql/slave_worker_info.ibd.delta
151106 11:43:26 [01] ...done
151106 11:43:26 [01] Copying ./mysql/innodb_table_stats.ibd to /backup/xtrabackup/incr2/2015-11-06_11-43-22/mysql/innodb_table_stats.ibd.delta
151106 11:43:26 [01] ...done
151106 11:43:27 >> log scanned up to (732716925)
151106 11:43:27 [01] Copying ./aazj/u_test.ibd to /backup/xtrabackup/incr2/2015-11-06_11-43-22/aazj/u_test.ibd.delta
151106 11:43:27 [01] ...done
[... ...]
151106 11:43:50 [01] Copying ./t/t.frm to /backup/xtrabackup/incr2/2015-11-06_11-43-22/t/t.frm
151106 11:43:50 [01] ...done
151106 11:43:50 Finished backing up non-InnoDB tables and files
151106 11:43:50 [00] Writing xtrabackup_binlog_info
151106 11:43:50 [00] ...done
151106 11:43:50 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '732777035'
xtrabackup: Stopping log copying thread.
.151106 11:43:50 >> log scanned up to (732777035)
151106 11:43:50 Executing UNLOCK TABLES
151106 11:43:50 All tables unlocked
151106 11:43:50 Backup created in directory '/backup/xtrabackup/incr2/2015-11-06_11-43-22'
MySQL binlog position: filename 'mysql-bin.000001', position '254400'
151106 11:43:50 [00] Writing backup-my.cnf
151106 11:43:50 [00] ...done
151106 11:43:50 [00] Writing xtrabackup_info
151106 11:43:50 [00] ...done
xtrabackup: Transaction log of lsn (732501432) to (732777035) was copied.
151106 11:43:50 completed OK!
[[email protected] mysql]#
3.5 innobackupex Incremental backup recovery
1> Apply full redo log:
[ [email protected] ~]# innobackupex --apply-log --redo-only /backup/xtrabackup/full/2015-11-06_11-29-51/ --user=bkpuser --password=digdeep
[[email protected] ~]# innobackupex --apply-log --redo-only /backup/xtrabackup/full/2015-11-06_11-29-51/ --user=bkpuser --password=digdeep
151106 14:48:26 innobackupex: Starting the apply-log operation
IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex
prints "completed OK!".
innobackupex version 2.3.2 based on MySQL server 5.6.24 Linux (i686) (revision id: 306a2e0)
xtrabackup: cd to /backup/xtrabackup/full/2015-11-06_11-29-51/
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(731724832)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Not using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Highest supported file format is Barracuda.
InnoDB: The log sequence numbers 731724822 and 731724822 in ibdata files do not match the log sequence number 731724832 in the ib_logfiles!
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages
InnoDB: from the doublewrite buffer...
xtrabackup: Last MySQL binlog file position 117940, file name mysql-bin.000015
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 731724832
151106 14:48:28 completed OK!
2> Apply the first incremental backup redo log:
[ [email protected] ~]# innobackupex --apply-log --redo-only /backup/xtrabackup/full/2015-11-06_11-29-51/ --incremental-dir=/backup/xtrabackup/incr1/2015-11-06_11-33-16/ --user=bkpuser --password=digdeep
[[email protected] ~]# innobackupex --apply-log --redo-only /backup/xtrabackup/full/2015-11-06_11-29-51/ --incremental-dir=/backup/xtrabackup/incr1/2015-11-06_11-33-16/ --user=bkpuser --password=digdeep
151106 14:51:08 innobackupex: Starting the apply-log operation
IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex
prints "completed OK!".
innobackupex version 2.3.2 based on MySQL server 5.6.24 Linux (i686) (revision id: 306a2e0)
incremental backup from 731724832 is enabled.
xtrabackup: cd to /backup/xtrabackup/full/2015-11-06_11-29-51/
xtrabackup: This target seems to be already prepared with --apply-log-only.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(732153217)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = /backup/xtrabackup/incr1/2015-11-06_11-33-16/
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: Generating a list of tablespaces
xtrabackup: page size for /backup/xtrabackup/incr1/2015-11-06_11-33-16//ibdata1.delta is 16384 bytes
Applying /backup/xtrabackup/incr1/2015-11-06_11-33-16//ibdata1.delta to ./ibdata1...
xtrabackup: page size for /backup/xtrabackup/incr1/2015-11-06_11-33-16//mysql/innodb_index_stats.ibd.delta is 16384 bytes
[... ...]
xtrabackup: page size for /backup/xtrabackup/incr1/2015-11-06_11-33-16//aazj/tttt.ibd.delta is 16384 bytes
Applying /backup/xtrabackup/incr1/2015-11-06_11-33-16//aazj/tttt.ibd.delta to ./aazj/tttt.ibd...
xtrabackup: page size for /backup/xtrabackup/incr1/2015-11-06_11-33-16//aazj/Users.ibd.delta is 16384 bytes
Applying /backup/xtrabackup/incr1/2015-11-06_11-33-16//aazj/Users.ibd.delta to ./aazj/Users.ibd...
xtrabackup: page size for /backup/xtrabackup/incr1/2015-11-06_11-33-16//aazj/Gis.ibd.delta is 16384 bytes
Applying /backup/xtrabackup/incr1/2015-11-06_11-33-16//aazj/Gis.ibd.delta to ./aazj/Gis.ibd...
[... ...]
xtrabackup: page size for /backup/xtrabackup/incr1/2015-11-06_11-33-16//t/t.ibd.delta is 16384 bytes
Applying /backup/xtrabackup/incr1/2015-11-06_11-33-16//t/t.ibd.delta to ./t/t.ibd...
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = /backup/xtrabackup/incr1/2015-11-06_11-33-16/
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Not using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 732153217
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages
InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 732501432 (18%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 8 6 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
xtrabackup: Last MySQL binlog file position 157893, file name mysql-bin.000001
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 732501432
151106 14:51:12 [01] Copying /backup/xtrabackup/incr1/2015-11-06_11-33-16/mysql/columns_priv.frm to ./mysql/columns_priv.frm
151106 14:51:12 [01] ...done
151106 14:51:12 [01] Copying /backup/xtrabackup/incr1/2015-11-06_11-33-16/mysql/user.MYI to ./mysql/user.MYI
151106 14:51:12 [01] ...done
151106 14:51:12 [01] Copying /backup/xtrabackup/incr1/2015-11-06_11-33-16/mysql/general_log.frm to ./mysql/general_log.frm
151106 14:51:12 [01] ...done
[... ...]
151106 14:51:14 [01] Copying /backup/xtrabackup/incr1/2015-11-06_11-33-16/t/city.frm to ./t/city.frm
151106 14:51:14 [01] ...done
151106 14:51:14 [01] Copying /backup/xtrabackup/incr1/2015-11-06_11-33-16/t/db.opt to ./t/db.opt
151106 14:51:14 [01] ...done
151106 14:51:14 [01] Copying /backup/xtrabackup/incr1/2015-11-06_11-33-16/t/t.frm to ./t/t.frm
151106 14:51:14 [01] ...done
151106 14:51:14 completed OK!
3> Apply the second ( The last time ) Incremental backup redo log, And rollback the crash recovery process ( No, --redo-only Options ):
[ [email protected] ~]# innobackupex --apply-log /backup/xtrabackup/full/2015-11-06_11-29-51/ --incremental-dir=/backup/xtrabackup/incr2/2015-1 1-06_11-43-22/ --user=bkpuser --password=digdeep
[[email protected] ~]# innobackupex --apply-log /backup/xtrabackup/full/2015-11-06_11-29-51/ --incremental-dir=/backup/xtrabackup/incr2/2015-1 1-06_11-43-22/ --user=bkpuser --password=digdeep
151106 14:55:43 innobackupex: Starting the apply-log operation
IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex
prints "completed OK!".
innobackupex version 2.3.2 based on MySQL server 5.6.24 Linux (i686) (revision id: 306a2e0)
incremental backup from 732501432 is enabled.
xtrabackup: cd to /backup/xtrabackup/full/2015-11-06_11-29-51/
xtrabackup: This target seems to be already prepared with --apply-log-only.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(732501432)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = /backup/xtrabackup/incr2/2015-11-06_11-43-22/
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: Generating a list of tablespaces
xtrabackup: page size for /backup/xtrabackup/incr2/2015-11-06_11-43-22//ibdata1.delta is 16384 bytes
Applying /backup/xtrabackup/incr2/2015-11-06_11-43-22//ibdata1.delta to ./ibdata1...
xtrabackup: page size for /backup/xtrabackup/incr2/2015-11-06_11-43-22//mysql/innodb_index_stats.ibd.delta is 16384 bytes
Applying /backup/xtrabackup/incr2/2015-11-06_11-43-22//mysql/innodb_index_stats.ibd.delta to ./mysql/innodb_index_stats.ibd...
[... ...]
Applying /backup/xtrabackup/incr2/2015-11-06_11-43-22//t/city.ibd.delta to ./t/city.ibd...
xtrabackup: page size for /backup/xtrabackup/incr2/2015-11-06_11-43-22//t/t.ibd.delta is 16384 bytes
Applying /backup/xtrabackup/incr2/2015-11-06_11-43-22//t/t.ibd.delta to ./t/t.ibd...
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = /backup/xtrabackup/incr2/2015-11-06_11-43-22/
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Not using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 732501432
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages
InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 732777035 (14%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 8 6 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: 128 rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.6.24 started; log sequence number 732777035
xtrabackup: Last MySQL binlog file position 254400, file name mysql-bin.000001
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 732817046
151106 14:55:47 [01] Copying /backup/xtrabackup/incr2/2015-11-06_11-43-22/mysql/columns_priv.frm to ./mysql/columns_priv.frm
151106 14:55:47 [01] ...done
151106 14:55:47 [01] Copying /backup/xtrabackup/incr2/2015-11-06_11-43-22/mysql/user.MYI to ./mysql/user.MYI
151106 14:55:47 [01] ...done
[... ...]
151106 14:55:50 [01] Copying /backup/xtrabackup/incr2/2015-11-06_11-43-22/t/db.opt to ./t/db.opt
151106 14:55:50 [01] ...done
151106 14:55:50 [01] Copying /backup/xtrabackup/incr2/2015-11-06_11-43-22/t/t.frm to ./t/t.frm
151106 14:55:50 [01] ...done
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = /backup/xtrabackup/incr2/2015-11-06_11-43-22/
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 50331648
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Not using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Setting log file /backup/xtrabackup/incr2/2015-11-06_11-43-22/ib_logfile101 size to 48 MB
InnoDB: Setting log file /backup/xtrabackup/incr2/2015-11-06_11-43-22/ib_logfile1 size to 48 MB
InnoDB: Renaming log file /backup/xtrabackup/incr2/2015-11-06_11-43-22/ib_logfile101 to /backup/xtrabackup/incr2/2015-11-06_11-43-22/ib_logfile0
InnoDB: New log files created, LSN=732817046
InnoDB: Highest supported file format is Barracuda.
InnoDB: 128 rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.6.24 started; log sequence number 732817420
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 732817430
151106 14:55:54 completed OK!
[ [email protected] ~]#
then --copy-back:
Shut down first mysqld: mysqladmin -uroot -pxxx shutdown
[ [email protected] mysql]# innobackupex --copy-back /backup/xtrabackup/full/2015-11-06_11-29-51/ --user=bkpuser --password=digdeep
[[email protected] mysql]# innobackupex --copy-back /backup/xtrabackup/full/2015-11-06_11-29-51/ --user=bkpuser --password=digdeep
151106 15:10:23 innobackupex: Starting the copy-back operation
IMPORTANT: Please check that the copy-back run completes successfully.
At the end of a successful copy-back run innobackupex
prints "completed OK!".
innobackupex version 2.3.2 based on MySQL server 5.6.24 Linux (i686) (revision id: 306a2e0)
151106 15:10:23 [01] Copying ibdata1 to /var/lib/mysql/ibdata1
151106 15:10:28 [01] ...done
151106 15:10:28 [01] Copying ./xtrabackup_info to /var/lib/mysql/xtrabackup_info
151106 15:10:28 [01] ...done
[... ...]
151106 15:10:41 [01] ...done
151106 15:10:41 [01] Copying ./t/db.opt to /var/lib/mysql/t/db.opt
151106 15:10:41 [01] ...done
151106 15:10:41 [01] Copying ./t/t.frm to /var/lib/mysql/t/t.frm
151106 15:10:41 [01] ...done
151106 15:10:42 completed OK!
Modify the permissions ：
chown -R mysql:mysql /var/lib/mysql
start-up ：mysqld_safe --user=mysql &
Finally, verify that the restore is successful .
4. Partial backup
You need to enable innodb_file_per_table,5.6 Enabled by default . In addition, when restoring ,prepare after , Not directly --copy-back, And only one table, one table import To restore .
[ [email protected] xtrabackup]# innobackupex --databases t /backup/xtrabackup/ --user=bkpuser --password=digdeep
[[email protected] xtrabackup]# innobackupex --databases t /backup/xtrabackup/ --user=bkpuser --password=digdeep
151106 15:39:34 innobackupex: Starting the backup operation
IMPORTANT: Please check that the backup run completes successfully.
At the end of a successful backup run innobackupex
prints "completed OK!".
151106 15:39:35 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;mysql_socket=/tmp/mysql. sock' as 'bkpuser' (using password: YES).
151106 15:39:35 version_check Connected to MySQL server
151106 15:39:35 version_check Executing a version check against the server...
151106 15:39:35 version_check Done.
151106 15:39:35 Connecting to MySQL server host: localhost, user: bkpuser, password: set, port: 0, socket: /tmp/mysql.sock
Using server version 5.6.26-log
innobackupex version 2.3.2 based on MySQL server 5.6.24 Linux (i686) (revision id: 306a2e0)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: open files limit requested 0, set to 10240
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 50331648
151106 15:39:35 >> log scanned up to (732817942)
xtrabackup: Generating a list of tablespaces
151106 15:39:35 [01] Copying ./ibdata1 to /backup/xtrabackup//2015-11-06_15-39-34/ibdata1
151106 15:39:36 >> log scanned up to (732817942)
151106 15:39:37 >> log scanned up to (732817942)
151106 15:39:38 [01] ...done
151106 15:39:38 [01] Copying ./t/city.ibd to /backup/xtrabackup//2015-11-06_15-39-34/t/city.ibd
151106 15:39:38 [01] ...done
151106 15:39:38 [01] Copying ./t/t.ibd to /backup/xtrabackup//2015-11-06_15-39-34/t/t.ibd
151106 15:39:38 [01] ...done
151106 15:39:38 >> log scanned up to (732817942)
Executing FLUSH NO_WRITE_TO_BINLOG TABLES...
151106 15:39:38 Executing FLUSH TABLES WITH READ LOCK...
151106 15:39:38 Starting to backup non-InnoDB tables and files
151106 15:39:38 [01] Skipping ./mysql/slave_master_info.ibd.
151106 15:39:38 [01] Skipping ./mysql/columns_priv.frm.
[... ...]
151106 15:39:38 [01] Skipping ./aazj/model_buyers_credit.ibd.
151106 15:39:38 [01] Skipping ./aazj/Users.frm.
151106 15:39:38 [01] Skipping ./aazj/model_recruiting_program.ibd.
151106 15:39:38 [01] Skipping ./aazj/model_model.ibd.
151106 15:39:38 [01] Skipping ./aazj/Customer.frm.
151106 15:39:38 [01] Skipping ./performance_schema/events_waits_summary_by_host_by_event_name.frm.
[... ...]
151106 15:39:38 [01] Skipping ./performance_schema/events_statements_summary_by_account_by_event_name.frm.
151106 15:39:38 [01] Copying ./t/city.frm to /backup/xtrabackup//2015-11-06_15-39-34/t/city.frm
151106 15:39:38 [01] ...done
151106 15:39:38 [01] Copying ./t/db.opt to /backup/xtrabackup//2015-11-06_15-39-34/t/db.opt
151106 15:39:38 [01] ...done
151106 15:39:38 [01] Copying ./t/t.frm to /backup/xtrabackup//2015-11-06_15-39-34/t/t.frm
151106 15:39:38 [01] ...done
151106 15:39:38 Finished backing up non-InnoDB tables and files
151106 15:39:38 [00] Writing xtrabackup_binlog_info
151106 15:39:38 [00] ...done
151106 15:39:38 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '732817942'
xtrabackup: Stopping log copying thread.
.151106 15:39:38 >> log scanned up to (732817942)
151106 15:39:39 Executing UNLOCK TABLES
151106 15:39:39 All tables unlocked
151106 15:39:39 Backup created in directory '/backup/xtrabackup//2015-11-06_15-39-34'
MySQL binlog position: filename 'mysql-bin.000001', position '120'
151106 15:39:39 [00] Writing backup-my.cnf
151106 15:39:39 [00] ...done
151106 15:39:39 [00] Writing xtrabackup_info
151106 15:39:39 [00] ...done
xtrabackup: Transaction log of lsn (732817942) to (732817942) was copied.
151106 15:39:39 completed OK!
database t There are only two tables in ：city, t All backed up .
Let's look at how to restore ：
4.1 part prepare:
[ [email protected] xtrabackup]# innobackupex --apply-log --export /backup/xtrabackup/2015-11-06_15-39-34/ --user=bkpuser --password=digdeep
[[email protected] xtrabackup]# innobackupex --apply-log --export /backup/xtrabackup/2015-11-06_15-39-34/ --user=bkpuser --password=digdeep
151106 15:49:43 innobackupex: Starting the apply-log operation
IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex
prints "completed OK!".
innobackupex version 2.3.2 based on MySQL server 5.6.24 Linux (i686) (revision id: 306a2e0)
xtrabackup: auto-enabling --innodb-file-per-table due to the --export option
xtrabackup: cd to /backup/xtrabackup/2015-11-06_15-39-34/
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(732817942)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Not using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Highest supported file format is Barracuda.
InnoDB: The log sequence numbers 732817430 and 732817430 in ibdata files do not match the log sequence number 732817942 in the ib_logfiles!
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages
InnoDB: from the doublewrite buffer...
InnoDB: Table aazj/Accounting_journal in the InnoDB data dictionary has tablespace id 117, but tablespace with that id or name does not exi st. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL auto matically removed, but the table still exists in the InnoDB internal data dictionary.
InnoDB: It will be removed from the data dictionary.
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
[... ...]
InnoDB: Table mysql/slave_relay_log_info in the InnoDB data dictionary has tablespace id 3, but tablespace with that id or name does not ex ist. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL aut omatically removed, but the table still exists in the InnoDB internal data dictionary.
InnoDB: It will be removed from the data dictionary.
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
InnoDB: Table mysql/slave_worker_info in the InnoDB data dictionary has tablespace id 5, but tablespace with that id or name does not exist . Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automa tically removed, but the table still exists in the InnoDB internal data dictionary.
InnoDB: It will be removed from the data dictionary.
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
InnoDB: 128 rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.6.24 started; log sequence number 732817942
xtrabackup: export option is specified.
xtrabackup: export metadata of table 't/city' to file `./t/city.exp` (2 indexes)
xtrabackup: name=PRIMARY, id.low=267, page=3
xtrabackup: name=PK_CITY, id.low=268, page=4
xtrabackup: export metadata of table 't/t' to file `./t/t.exp` (1 indexes)
xtrabackup: name=GEN_CLUST_INDEX, id.low=131, page=3
xtrabackup: Last MySQL binlog file position 254400, file name mysql-bin.000001
xtrabackup: starting shutdown with innodb_fast_shutdown = 0
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 732957307
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 50331648
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Not using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Setting log file ./ib_logfile101 size to 48 MB
InnoDB: Setting log file ./ib_logfile1 size to 48 MB
InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
InnoDB: New log files created, LSN=732957307
InnoDB: Highest supported file format is Barracuda.
InnoDB: 128 rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.6.24 started; log sequence number 732957708
xtrabackup: starting shutdown with innodb_fast_shutdown = 0
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 732957718
151106 15:49:49 completed OK!
4.2 Let's take a look at it import Into a new database ：
( [email protected])[t]mysql>create database partial;
( [email protected])[t]mysql>use partial;
Database changed
( [email protected])[partial]mysql>create table city like t.city;
( [email protected])[partial]mysql>alter table partial.city discard tablespace;
And then city.exp and city.ibd copy to /var/lib/mysql/partial/ Under the table of contents , And modify the authority ：
[ [email protected] t]# cp city.exp city.ibd /var/lib/mysql/partial/
[ [email protected] partial]# chown -R mysql:mysql /var/lib/mysql
then
( [email protected])[aazj]mysql>alter table partial.city import tablespace;
Query OK, 0 rows affected, 1 warning (0.11 sec)
( [email protected])[aazj]mysql>select count(*) from partial.city;
+----------+
| count(*) |
+----------+
| 3285 |
+----------+
1 row in set (0.01 sec)
You can see import succeed . Partial recovery succeeded .
lower than t Just do the same for the table .
( [email protected])[partial]mysql>select count(*) from t;
+----------+
| count(*) |
+----------+
| 11 |
+----------+
1 row in set (0.00 sec)
You can see , This partial backup / recovery , It's more difficult to operate , There are many steps , You also need to process one table by one . The processing of a few tables is OK , If a lot of watches , No more .
4.3 Partial backup recovery / Restore one or more databases ：
1） Backup ：
[[email protected] mysql]# innobackupex --database="aazj t mysql information_schema performance_schema" /backup/xtrabackup/partial/ --user=pkpuser --password=digdeep
Note that there --database = "aazj t mysql performance_schema" Represents the database for the specified backup ; You can also add other databases , But you must use quotation marks .
2） recovery prepare：
[[email protected] partial]# innobackupex --apply-log /backup/xtrabackup/partial/2015-11-11_15-22-56 --user=bkpuser --password=digdeep
then close mysqld, Empty datadir :
[[email protected] mysql]# pwd
/var/lib/mysql
[[email protected] mysql]# rm -rf *
3）copy-back:
[[email protected] partial]# innobackupex --copy-back /backup/xtrabackup/partial/2015-11-11_15-22-56 --user=bkpuser --password=digdeep
And then modify the permissions ：chown -R mysql:mysql /var/lib/mysql
Then start mysqld, Discovery database t Recovered . You can also back up multiple databases at one time , But be sure to bring mysql database , Otherwise, when you recover , Without a data dictionary ,select Unable to read data ：
Restoring Partial Backups：
Restoring should be done by restoring individual tables in the partial backup to the server.
It can also be done by copying back the prepared backup to a clean datadir (in that case, make sure to include the mysql database). System database can be created with: $ sudo mysql_install_db --user=mysql ( Excerpt from xtrabackup file )
Partial recovery generally requires export, then import. More trouble , But we can also be in an empty datadir Directory directly --copy-back, In this case , Then you must bring it with you when backing up mysql database , Of course, it's best to bring all the system databases , otherwise , Command required ：mysql_install_db --user=mysql --basedir=... Rebuild those system databases . That's why you brought it with you during a partial backup ：mysql performance_schema(information_schema Is the system view , You don't need to bring , Of course, you can take it with you )
4） If you don't want to take performance_schema(mysql You must take it with you ), Then you have to use ： mysql_install_db --user=mysql --basedir=/usr/local/mysql To regenerate the system database mysql and performance_schema. So now --copy-back Before , You must first delete the and We want to --copy-back Duplicate files ：
[[email protected] mysql]# rm ibdata1 ib_logfile0 ib_logfile1
[[email protected] mysql]# rm -rf mysql
in addition --copy-back Take the parameters with you ： --force-non-empty-directories
innobackupex --copy-back --force-non-empty-directories /backup/xtrabackup/partial/2015-11-11_16-17-11/ --user=pkpuser --password=digdeep
because datadir directory not empty , So you need to bring this parameter ：
--force-non-empty-directories
This option, when specified, makes --copy-back or
--move-back transfer files to non-empty directories. Note
that no existing files will be overwritten. If
--copy-back or --nove-back has to copy a file from the
backup directory which already exists in the destination
directory, it will still fail with an error.
Even with this parameter , If there are files with the same name , It still reports an error , You need to delete datadir Duplicate name file in .
5. point-in-time recovery
Make use of all the equipment 、 The incremental backup can only be restored to the moment when the full backup is completed , Or the data at the moment when the incremental backup is completed . Data generated after backup , We need to combine binlog, To restore . We can binlog gain innobackupex At the end of the last backup position, All after it sql, Finished application , these sql, You can restore the database to the latest state , Or the state we want at some time .
1> Let's start with a full ：
[ [email protected] xtrabackup]# innobackupex /backup/xtrabackup/full --user=bkpuser --password=digdeep
2> Another increment ：
take t Delete a row from the table data ：delete from t where i=11;
[ [email protected] xtrabackup]# innobackupex --incremental /backup/xtrabackup/incr1/ --incremental-basedir=/backup/xtrabackup/full/2015-11-06_16-26-08 --user=bkpuser --password=digdeep
3> Another increment ：
take t Delete a row from the table data ：delete from t where i=10;
[ [email protected] xtrabackup]# innobackupex --incremental /backup/xtrabackup/incr2/ --incremental-basedir=/backup/xtrabackup/incr1/2015-11-06_16-31-13/ --user=bkpuser --password=digdeep
4> After the backup is complete , Let's do it again t surface ：
( [email protected])[t]mysql>delete from t where i>3;
Status at this time ：
( [email protected])[t]mysql>show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 927 |
| mysql-bin.000002 | 688 |
+------------------+-----------+
2 rows in set (0.00 sec)
( [email protected])[t]mysql>show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000002 | 688 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
Suppose that the disk where the database table data is located fails , however binlog The document is good . So at this time , We can use all the above 、 Incremental backup 、 also binlog Files together to restore the database to the latest state at the moment of disk failure .
5> First of all, from the fully equipped 、 Incremental backup obtains the data when the last backup is completed ：
1） Apply full redo log:
[ [email protected] xtrabackup]# innobackupex --apply-log --redo-only /backup/xtrabackup/full/2015-11-06_16-26-08 --user=bkpuser --password=digdeep
2） Apply the first incremental backup redo log:
[ [email protected] xtrabackup]# innobackupex --apply-log --redo-only /backup/xtrabackup/full/2015-11-06_16-26-08 --incremental-dir=/backup/xtr abackup/incr1/2015-11-06_16-31-13/ --user=bkpuser --password=digdeep
3） To apply the second incremental backup redo log, And rollback only ( Get rid of --redo-only Options )：
[ [email protected] xtrabackup]# innobackupex --apply-log /backup/xtrabackup/full/2015-11-06_16-26-08 --incremental-dir=/backup/xtrabackup/incr2/2015-11-06_16-33-57/ --user=bkpuser --password=digdeep
At this time, it has been restored to the state when the last backup was completed .
Let's take a look at the last incremental backup xtrabackup_binlog_info file information ：
[ [email protected] xtrabackup]# cat incr2/2015-11-06_16-33-57/xtrabackup_binlog_info
mysql-bin.000002 482
You can see the corresponding binlog postion by ：mysql-bin.000002 482
And the moment of collapse binlog postion by ： mysql-bin.000002 688
So we need to apply mysql-bin.000002 Of documents 482 To 688 Between sql：
4） First --copy-back
[ [email protected] mysql]# innobackupex --copy-back /backup/xtrabackup/full/2015-11-06_16-26-08 --user=bkpuser --password=digdeep
Modify the permissions ：
[ [email protected] ~]# chown -R mysql:mysql /var/lib/mysql
start-up msyqld: mysqld_safe --user=mysql &
And then verify ,t The data table , Should have i<10 & i>3 The data of ：
( [email protected])[t]mysql>select * from t;
+------+
| i |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 7 |
| 8 |
| 9 |
+------+
9 rows in set (0.00 sec)
As we expected . Explain that at this time , The previous operation is completely correct .
5） application mysql-bin.000002 Of documents 482 To 688 Between sql
[ [email protected] mysql]# mysqlbinlog /backup/xtrabackup/mysql-bin.000002 --start-position=482 > bin.sql
( [email protected])[(none)]mysql>source /var/lib/mysql/bin.sql
Then I'm looking at t Table data ：
( [email protected])[t]mysql>select * from t;
+------+
| i |
+------+
| 1 |
| 2 |
| 3 |
+------+
3 rows in set (0.00 sec)
Everything is perfect , The database has been restored to the latest state by us .
6. innobackupex Option optimization / Best practices
6.1 Optimize FTWRL lock ：
In backup non innodb Database time , Will use ：flush tables with read lock Global lock locks the entire database . If there is a long query running in the database , that FTWRL You can't get , Will be blocked , Then block all DML operation . At this time, even if we kill fall FTWRL Global locks cannot be recovered from blocking . In addition, we have successfully obtained FTWRL After the global lock , stay copy In the process of non transactional files , The entire database is also locked . So we should let FTWRL The process should be as short as possible .( stay copy Non transaction engine data files , It will block innodb Transaction engine . Of course, it will also block all other non transaction engines .)
1> To prevent blocking ：
innobackupex Several options are provided to avoid blocking ：
--ftwrl-wait-timeout=# Replace --lock-wait-timeout
This option specifies time in seconds that innobackupex
should wait for queries that would block FTWRL before
running it. If there are still such queries when the
timeout expires, innobackupex terminates with an error.
Default is 0, in which case innobackupex does not wait
for queries to complete and starts FTWRL immediately.
--ftwrl-wait-threshold=# Replace --lock-wait-threshold
This option specifies the query run time threshold which
is used by innobackupex to detect long-running queries
with a non-zero value of --ftwrl-wait-timeout. FTWRL is
not started until such long-running queries exist. This
option has no effect if --ftwrl-wait-timeout is 0.
Default value is 60 seconds.
--lock-wait-timeout=60 This option represents ： We are FTWRL when , If there is a long query , Then we can wait at most 60S Time for , If 60 The long query is completed in seconds , We can successfully execute FTWRL 了 , If 60 Not finished in seconds , Then directly report an error and exit , give up . The default value is 0
--lock-wait-threshold=10 This option indicates how long it has been running sql As a long query ; For long queries, wait at most --lock-wait-timeout second .
--kill-long-queries-timeout=10 This option indicates that FTWRL after , Wait a few more seconds , If there is a long query , Then put it kill fall . The default is 0,not to kill.
--kill-long-query-type={all|select} This option means that we only kill select sentence , still kill All other types of long sql sentence .
These options , We don't have to all have , Generally only use --lock-wait-timeout=60 That's it .
Be careful --lock-* and --kill-* Different options , One is to wait for many hours and seconds before executing FTWRL, If it still cannot be executed successfully, an error will be reported and you will exit ; One is that it has been implemented FTWRL, When the timeout expires kill.
2> To shorten the FTWRL Time of global lock ：
--rsync Use this option to reduce the locking time of backup non transaction engine tables , If a large number of databases and tables need to be backed up , Can speed up .
--rsync Uses the rsync utility to optimize local file transfers.
When this option is specified, innobackupex uses rsync to
copy all non-InnoDB files instead of spawning a separate
cp for each file, which can be much faster for servers
with a large number of databases or tables. This option
cannot be used together with --stream.
3> Parallel optimization ：
--parallel=# During the backup phase , Compress / Decompression phase , encryption / Decryption phase ,--apply-log,--copy-back All phases can be in parallel
On backup, this option specifies the number of threads
the xtrabackup child process should use to back up files
concurrently. The option accepts an integer argument. It
is passed directly to xtrabackup's --parallel option. See
the xtrabackup documentation for details.
4> Memory optimization ：
--use-memory=# stay crash recovery Stage , That is to say --apply-log Use this option at this stage
This option accepts a string argument that specifies the
amount of memory in bytes for xtrabackup to use for crash
recovery while preparing a backup. Multiples are
supported providing the unit (e.g. 1MB, 1GB). It is used
only with the option --apply-log. It is passed directly
to xtrabackup's --use-memory option. See the xtrabackup
documentation for details.
3> Backup slave:
--safe-slave-backup
Stop slave SQL thread and wait to start backup until
Slave_open_temp_tables in "SHOW STATUS" is zero. If there
are no open temporary tables, the backup will take place,
otherwise the SQL thread will be started and stopped
until there are no open temporary tables. The backup will
fail if Slave_open_temp_tables does not become zero after
--safe-slave-backup-timeout seconds. The slave SQL thread
will be restarted when the backup finishes.
--safe-slave-backup-timeout=#
How many seconds --safe-slave-backup should wait for
Slave_open_temp_tables to become zero. (default 300)
--slave-info This option is useful when backing up a replication slave
server. It prints the binary log position and name of the
master server. It also writes this information to the
"xtrabackup_slave_info" file as a "CHANGE MASTER"
command. A new slave for this master can be set up by
starting a slave server on this backup and issuing a
"CHANGE MASTER" command with the binary log position
saved in the "xtrabackup_slave_info" file.
7. Backup principle ：
1）innobackupex yes perl Write the script , It calls xtrabackup To backup innodb database . and xtrabackup yes C Program written in language , It calls for innodb Function library and mysql Client function library .innodb The function library provides applications to data files redo log The function of , and mysql The client function library provides the function of parsing command line parameters .innobackupex Backup innodb Database functionality , All by calling xtrabackup --backup and xtrabackup --prepare To complete . We don't have to use it directly xtrabackup To backup , adopt innobackupex More convenient .xtrabakup By jumping to datadir Catalog , Then the backup process is completed through two threads ：
1> log-copy thread: When backup starts , The background thread always monitors redo log( Per second check once redo log), take redo log Copy your changes to the file after backup xtrabackup_logfile in . If redo log Generate very fast , There may be log-copy Threads can't keep up with redo log The production speed of , So in redo log When overwriting by file switching ,xtrabakcup Will report a mistake .
2> data-file-copy thread: There is a copy before and after data file The thread of , Note that this is not a simple copy , It's called innodb function library , image innodb Open a data file like a database , To read , Then copy one at a time page, Then on page To verify , If the validation error , Will repeat up to ten times .
When the data file is copied ,xtrabackup stop it log-copy Threads , And create a file xtrabackup_checkpoints Record the type of backup , At the beginning lsn And at the end of lsn Etc .
And the backup generates xtrabackup_binlog_info File means the corresponding... When the backup is completed binlog Of position Information , Be similar to ：mysql-bin.000002 120
Record... At the beginning of the backup LSN, Then a thread copies the data file , A thread monitor redo log, Copy the new data generated during the backup process redo log. Although our data files are obviously not consistent , But the use of innodb Of crash-recovery function , Generated during application backup redo log file , You can get the consistent data at the moment when the backup is completed .
Note that copying data files is divided into two processes ：
One is copying innodb Transaction engine data file , You don't need to hold a lock ; The other is to copy the data files and files of non transaction engines table The definition file for .frm, When copying these files , Yes, you need to pass FTWRL, Then in the process of replication , Therefore, the whole database will be blocked .
Incremental backup , By scanning the table in full , Compare LSN, If it's time to page Of LSN Greater than the last time LSN, Then it's time to page Copied to the table_name.ibd.delta In file . Reply time .delta Hui He redo log Apply to all data files .
Incremental backup on restore , Except for the last incremental backup file , Other incremental backups are applied , Only roll forward , Cannot perform rollback operation , Because there are no committed transactions , It may have been committed in the next incremental backup , If you rolled back during the last incremental backup , Then the next incremental backup application , Obviously, it's wrong , Because he can't commit the transaction , The transaction was rolled back .
8. summary ：
1） jurisdiction ：
Backup requires two levels of permissions ,Linux Level of authority ,mysql Level of authority .
2） Full backup and recovery
be completely ready ：innobackupex /backup/xtrabackup/full --user=bkpuser --password=digdeep
Apply logs for prepare: innobackupex --apply-log /backup/xtrabackup/full/2015-11-05_22-38-55/ --user=bkpuser --password=digdeep
close mysqld:
copy-back: innobackupex --copy-back /backup/xtrabackup/full/2015-11-05_22-38-55/ --user=bkpuser --password=digdeep
Modify the permissions ：chown -R mysql:mysql /var/lib/mysql
3） Incremental backup and recovery ：
be completely ready ：
innobackupex --user=bkpuser --password=digdeep /backup/xtrabackup/full
First incremental backup ：
innobackupex --incremental /backup/xtrabackup/incr1/ --incremental-basedir=/backup/xtrabackup/full/2015-11-06_11-29-51/
--user=bkpuser --password=digdeep
Second incremental backup ：
innobackupex --incremental /backup/xtrabackup/incr2 --incremental-basedir=/backup/xtrabackup/incr1/2015-11-06_11-33-16/
--user=bkpuser --password=digdeep
recovery ：
The application is fully equipped redo log:
innobackupex --apply-log --redo-only /backup/xtrabackup/full/2015-11-06_11-29-51/ --user=bkpuser --password=digdeep
Apply the first incremental backup redo log:
innobackupex --apply-log --redo-only /backup/xtrabackup/full/2015-11-06_11-29-51/ --incremental-dir=/backup/xtrabackup/incr1/2015-11-06_11-33-16/
--user=bkpuser --password=digdeep
Apply the second ( The last time ) Incremental backup redo log:
innobackupex --apply-log /backup/xtrabackup/full/2015-11-06_11-29-51/ --incremental-dir=/backup/xtrabackup/incr2/2015-11-06_11-43-22/
--user=bkpuser --password=digdeep
close mysqld,
innobackupex --copy-back /backup/xtrabackup/full/2015-11-06_11-29-51/ --user=bkpuser --password=digdeep
4） Partial backup
innobackupex --databases t /backup/xtrabackup/ --user=bkpuser --password=digdeep
innobackupex --apply-log --export /backup/xtrabackup/2015-11-06_15-39-34/ --user=bkpuser --password=digdeep
New table structure ：create table city like t.city;
alter table partial.city discard tablespace;
And then city.exp and city.ibd copy to /var/lib/mysql/partial/ Under the table of contents , And modify the authority ：chown -R mysql:mysql /var/lib/mysql
alter table partial.city import tablespace;
5）point-in-time recovery
stay --copy-back after , quote binlog file
mysqlbinlog /backup/xtrabackup/mysql-bin.000002 --start-position=482 > bin.sql
( [email protected])[(none)]mysql>source bin.sql
6） innobackupex Option optimization / Best practices
--ftwrl-wait-timeout=60 Prevent blocking
--rsync Reduce FTWRL Time Reduce locking time for backing up non transaction engine tables
--parallel=4 Open parallel
--use-memory=4G crash recovery Used during
边栏推荐
- MySQL实战优化高手04 借着更新语句在InnoDB存储引擎中的执行流程，聊聊binlog是什么？
- Which is the better prospect for mechanical engineer or Electrical Engineer?
- Contrôle de l'exécution du module d'essai par panneau dans Canoe (primaire)
- Teach you how to write the first MCU program hand in hand
- Canoe CAPL file operation directory collection
- MySQL實戰優化高手08 生產經驗：在數據庫的壓測過程中，如何360度無死角觀察機器性能？
- Day 5 of MySQL learning
- oracle sys_ Context() function
- 好博客好资料记录链接
- CAPL 脚本对.ini 配置文件的高阶操作
猜你喜欢
MySQL Real Time Optimization Master 04 discute de ce qu'est binlog en mettant à jour le processus d'exécution des déclarations dans le moteur de stockage InnoDB.
Control the operation of the test module through the panel in canoe (Advanced)
Installation de la pagode et déploiement du projet flask
CAPL script pair High level operation of INI configuration file
Hugo blog graphical writing tool -- QT practice
Listen to my advice and learn according to this embedded curriculum content and curriculum system
Programmation défensive en langage C dans le développement intégré
Teach you how to write the first MCU program hand in hand
The programming ranking list came out in February. Is the result as you expected?
Defensive C language programming in embedded development
随机推荐
软件测试工程师必备之软技能：结构化思维
Vh6501 Learning Series
如何让shell脚本变成可执行文件
安装OpenCV时遇到的几种错误
四川云教和双师模式
解决在window中远程连接Linux下的MySQL
Cooperative development in embedded -- function pointer
Why can't TN-C use 2p circuit breaker?
AI的路线和资源
South China Technology stack cnn+bilstm+attention
If a university wants to choose to study automation, what books can it read in advance?
History of object recognition
在CANoe中通过Panel面板控制Test Module 运行（初级）
Safety notes
[untitled]
Random notes
Redis集群方案应该怎么做？都有哪些方案？
The appearance is popular. Two JSON visualization tools are recommended for use with swagger. It's really fragrant
Control the operation of the test module through the panel in canoe (Advanced)
软件测试工程师必备之软技能：结构化思维