mysql的xtrabackup備份恢復基本操作
阿新 • • 發佈：2019-01-26
演示環境：
作業系統：Linux-x86-64
資料庫版本：5.7.19
本次演示包括：xtrabackup軟體的安裝， 全量備份，增量備份，恢復 操作
附：官方軟體及文件下載地址：https://www.percona.com/software/mysql-database/percona-xtrabackup
1、安裝xtrabackup軟體
--檢視軟體
[[email protected] oracle_setup]# ll *xtrabackup*
-rw-r--r-- 1 root root 7745224 Mar 19 21:21 percona-xtrabackup-24-2.4.10-1.el7.x86_64.rpm
--安裝報錯 一些依賴包沒有
[ 2、基本設定
--建立備份使用者
mysql> CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 'S3cret2233$';
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'bkpuser'@'localhost';
Query OK, 0 rows affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
--設定備份路徑
[[email protected] xtrabackup_dir]# mkdir -p /mysql/xtrabackup_dir/
[[email protected] xtrabackup_dir]# chown mysql:mysql /mysql/xtrabackup_dir/
[[email protected] ~]# vi /etc/my.cnf
--新增引數
[xtrabackup]
target_dir = /mysql/xtrabackup_dir/
3、xtrabackup全量備份
--xtrabackup 全量備份
[[email protected] ~]# xtrabackup --backup --user=bkpuser --password=S3cret2233$
180416 17:38:44 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup' as 'bkpuser' (using password: YES).
180416 17:38:44 version_check Connected to MySQL server
180416 17:38:44 version_check Executing a version check against the server...
180416 17:38:44 version_check Done.
180416 17:38:44 Connecting to MySQL server host: localhost, user: bkpuser, password: set, port: not set, socket: not set
Using server version 5.7.19-log
xtrabackup version 2.4.10 based on MySQL server 5.7.19 Linux (x86_64) (revision id: 3198bce)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: open files limit requested 0, set to 1024
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
InnoDB: Number of pools: 1
180416 17:38:44 >> log scanned up to (2777824)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 54 for flydb/t_list#P#p0, old maximum was 0
180416 17:38:44 [01] Copying ./ibdata1 to /mysql/xtrabackup_dir/ibdata1
180416 17:38:44 [01] ...done
......
180416 17:38:44 [01] Copying ./mysql/slave_worker_info.ibd to /mysql/xtrabackup_dir/mysql/slave_worker_info.ibd
180416 17:38:44 [01] ...done
180416 17:38:45 >> log scanned up to (2777824)
180416 17:38:45 Executing FLUSH NO_WRITE_TO_BINLOG TABLES...
180416 17:38:45 Executing FLUSH TABLES WITH READ LOCK...
180416 17:38:45 Starting to backup non-InnoDB tables and files
180416 17:38:45 [01] Copying ./flydb/t_list.frm to /mysql/xtrabackup_dir/flydb/t_list.frm
180416 17:38:45 [01] ...done
......
180416 17:38:47 [01] Copying ./mysql/help_relation.frm to /mysql/xtrabackup_dir/mysql/help_relation.frm
180416 17:38:47 [01] ...done
180416 17:38:47 Finished backing up non-InnoDB tables and files
180416 17:38:47 [00] Writing /mysql/xtrabackup_dir/xtrabackup_binlog_info
180416 17:38:47 [00] ...done
180416 17:38:47 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '2777815'
xtrabackup: Stopping log copying thread.
.180416 17:38:47 >> log scanned up to (2777824)
180416 17:38:47 Executing UNLOCK TABLES
180416 17:38:47 All tables unlocked
180416 17:38:47 [00] Copying ib_buffer_pool to /mysql/xtrabackup_dir/ib_buffer_pool
180416 17:38:47 [00] ...done
180416 17:38:47 Backup created in directory '/mysql/xtrabackup_dir/'
MySQL binlog position: filename 'my-bin.000043', position '800'
180416 17:38:47 [00] Writing /mysql/xtrabackup_dir/backup-my.cnf
180416 17:38:47 [00] ...done
180416 17:38:47 [00] Writing /mysql/xtrabackup_dir/xtrabackup_info
180416 17:38:47 [00] ...done
xtrabackup: Transaction log of lsn (2777815) to (2777824) was copied.
180416 17:38:48 completed OK!
--檢視備份檔案
[[email protected] xtrabackup_dir]# cd /mysql/xtrabackup_dir/
[[email protected] xtrabackup_dir]# ll
total 12336
-rw-r----- 1 root root 426 Apr 16 17:38 backup-my.cnf
drwxr-x--- 2 root root 4096 Apr 16 17:38 flydb
-rw-r----- 1 root root 315 Apr 16 17:38 ib_buffer_pool
-rw-r----- 1 root root 12582912 Apr 16 17:38 ibdata1
drwxr-x--- 2 root root 4096 Apr 16 17:38 mysql
drwxr-x--- 2 root root 4096 Apr 16 17:38 performance_schema
drwxr-x--- 2 root root 12288 Apr 16 17:38 sys
-rw-r----- 1 root root 18 Apr 16 17:38 xtrabackup_binlog_info
-rw-r----- 1 root root 113 Apr 16 17:38 xtrabackup_checkpoints
-rw-r----- 1 root root 464 Apr 16 17:38 xtrabackup_info
-rw-r----- 1 root root 2560 Apr 16 17:38 xtrabackup_logfile4、innobackupex全量備份
--innobackupex 全量備份
--defaults-file=/etc/my.cnf //my.cnf檔案
--user=bkpuser //user使用者
--password //password密碼
/mysql/innobackupex_dir/ //備份路徑
[[email protected] ~]# innobackupex --defaults-file=/etc/my.cnf --user=bkpuser --password=S3cret2233$ /mysql/innobackupex_dir/
180416 19:56:45 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!".
180416 19:56:45 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup' as 'bkpuser' (using password: YES).
180416 19:56:45 version_check Connected to MySQL server
180416 19:56:45 version_check Executing a version check against the server...
180416 19:56:45 version_check Done.
180416 19:56:45 Connecting to MySQL server host: localhost, user: bkpuser, password: set, port: not set, socket: not set
Using server version 5.7.19-log
innobackupex version 2.4.10 based on MySQL server 5.7.19 Linux (x86_64) (revision id: 3198bce)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: open files limit requested 0, set to 1024
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
InnoDB: Number of pools: 1
180416 19:56:45 >> log scanned up to (2777824)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 54 for flydb/t_list#P#p0, old maximum was 0
180416 19:56:46 [01] Copying ./ibdata1 to /mysql/innobackupex_dir/2018-04-16_19-56-45/ibdata1
180416 19:56:46 [01] ...done
......
180416 19:56:46 [01] Copying ./mysql/slave_worker_info.ibd to /mysql/innobackupex_dir/2018-04-16_19-56-45/mysql/slave_worker_info.ibd
180416 19:56:46 [01] ...done
180416 19:56:46 >> log scanned up to (2777824)
180416 19:56:47 Executing FLUSH NO_WRITE_TO_BINLOG TABLES...
180416 19:56:47 Executing FLUSH TABLES WITH READ LOCK...
180416 19:56:47 Starting to backup non-InnoDB tables and files
180416 19:56:47 [01] Copying ./flydb/t_list.frm to /mysql/innobackupex_dir/2018-04-16_19-56-45/flydb/t_list.frm
180416 19:56:47 [01] ...done
......
180416 19:56:49 [01] Copying ./mysql/help_relation.frm to /mysql/innobackupex_dir/2018-04-16_19-56-45/mysql/help_relation.frm
180416 19:56:49 [01] ...done
180416 19:56:49 Finished backing up non-InnoDB tables and files
180416 19:56:49 [00] Writing /mysql/innobackupex_dir/2018-04-16_19-56-45/xtrabackup_binlog_info
180416 19:56:49 [00] ...done
180416 19:56:49 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '2777815'
xtrabackup: Stopping log copying thread.
.180416 19:56:49 >> log scanned up to (2777824)
180416 19:56:49 Executing UNLOCK TABLES
180416 19:56:49 All tables unlocked
180416 19:56:49 [00] Copying ib_buffer_pool to /mysql/innobackupex_dir/2018-04-16_19-56-45/ib_buffer_pool
180416 19:56:49 [00] ...done
180416 19:56:49 Backup created in directory '/mysql/innobackupex_dir/2018-04-16_19-56-45/'
MySQL binlog position: filename 'my-bin.000043', position '800'
180416 19:56:49 [00] Writing /mysql/innobackupex_dir/2018-04-16_19-56-45/backup-my.cnf
180416 19:56:49 [00] ...done
180416 19:56:49 [00] Writing /mysql/innobackupex_dir/2018-04-16_19-56-45/xtrabackup_info
180416 19:56:49 [00] ...done
xtrabackup: Transaction log of lsn (2777815) to (2777824) was copied.
180416 19:56:50 completed OK!
--檢視備份檔案
[[email protected] innobackupex_dir]# cd /mysql/innobackupex_dir/2018-04-16_19-56-45/
[[email protected] 2018-04-16_19-56-45]# ll
total 12336
-rw-r----- 1 root root 426 Apr 16 19:56 backup-my.cnf
drwxr-x--- 2 root root 4096 Apr 16 19:56 flydb
-rw-r----- 1 root root 315 Apr 16 19:56 ib_buffer_pool
-rw-r----- 1 root root 12582912 Apr 16 19:56 ibdata1
drwxr-x--- 2 root root 4096 Apr 16 19:56 mysql
drwxr-x--- 2 root root 4096 Apr 16 19:56 performance_schema
drwxr-x--- 2 root root 12288 Apr 16 19:56 sys
-rw-r----- 1 root root 18 Apr 16 19:56 xtrabackup_binlog_info
-rw-r----- 1 root root 113 Apr 16 19:56 xtrabackup_checkpoints
-rw-r----- 1 root root 510 Apr 16 19:56 xtrabackup_info
-rw-r----- 1 root root 2560 Apr 16 19:56 xtrabackup_logfile
5、innobackupex增量備份
--innobackupex 增量備份
只有innodb 可以， 有lsn號(相當oracle的scn)，可以增量備份； 其他的myisam都是全量再備份一份； memory的只備份了表結構， 資料備份不了。
--備份前新增表 並寫入資料
mysql> use flydb
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> create table please_recovery_me_t(a int);
Query OK, 0 rows affected (0.02 sec)
mysql> insert into please_recovery_me_t values (1);
Query OK, 1 row affected (0.00 sec)
mysql> insert into please_recovery_me_t values (2);
Query OK, 1 row affected (0.00 sec)
mysql> select * from please_recovery_me_t;
+------+
| a |
+------+
| 1 |
| 2 |
+------+
2 rows in set (0.00 sec)
--增量備份
--defaults-file=/etc/my.cnf //my.cnf檔案
--user=bkpuser //user使用者
--password //password密碼
--incremental //增量備份標示
/mysql/innobackupex_dir/ //增量備份路徑
--incremental-basedir //基於的全量備份路徑
[[email protected] 2018-04-16_19-56-45]# innobackupex --defaults-file=/etc/my.cnf --user=bkpuser --password=S3cret2233$ --incremental /mysql/innobackupex_dir/ --incremental-basedir=/mysql/innobackupex_dir/2018-04-16_19-56-45/
180416 20:38:06 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!".
180416 20:38:06 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup' as 'bkpuser' (using password: YES).
180416 20:38:06 version_check Connected to MySQL server
180416 20:38:06 version_check Executing a version check against the server...
180416 20:38:06 version_check Done.
180416 20:38:06 Connecting to MySQL server host: localhost, user: bkpuser, password: set, port: not set, socket: not set
Using server version 5.7.19-log
innobackupex version 2.4.10 based on MySQL server 5.7.19 Linux (x86_64) (revision id: 3198bce)
incremental backup from 2777815 is enabled.
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: open files limit requested 0, set to 1024
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
InnoDB: Number of pools: 1
180416 20:38:06 >> log scanned up to (2784824)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 54 for flydb/t_list#P#p0, old maximum was 0
xtrabackup: using the full scan for incremental backup
180416 20:38:07 [01] Copying ./ibdata1 to /mysql/innobackupex_dir/2018-04-16_20-38-06/ibdata1.delta
180416 20:38:07 [01] ...done
......
180416 20:38:11 [01] Copying ./mysql/slave_worker_info.ibd to /mysql/innobackupex_dir/2018-04-16_20-38-06/mysql/slave_worker_info.ibd.delta
180416 20:38:11 [01] ...done
180416 20:38:11 >> log scanned up to (2784824)
180416 20:38:12 Executing FLUSH NO_WRITE_TO_BINLOG TABLES...
180416 20:38:12 Executing FLUSH TABLES WITH READ LOCK...
180416 20:38:12 Starting to backup non-InnoDB tables and files
180416 20:38:12 [01] Copying ./flydb/t_list.frm to /mysql/innobackupex_dir/2018-04-16_20-38-06/flydb/t_list.frm
180416 20:38:12 [01] ...done
......
180416 20:38:14 [01] Copying ./mysql/help_relation.frm to /mysql/innobackupex_dir/2018-04-16_20-38-06/mysql/help_relation.frm
180416 20:38:14 [01] ...done
180416 20:38:14 Finished backing up non-InnoDB tables and files
180416 20:38:14 [00] Writing /mysql/innobackupex_dir/2018-04-16_20-38-06/xtrabackup_binlog_info
180416 20:38:14 [00] ...done
180416 20:38:14 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '2784815'
xtrabackup: Stopping log copying thread.
.180416 20:38:14 >> log scanned up to (2784824)
180416 20:38:15 Executing UNLOCK TABLES
180416 20:38:15 All tables unlocked
180416 20:38:15 [00] Copying ib_buffer_pool to /mysql/innobackupex_dir/2018-04-16_20-38-06/ib_buffer_pool
180416 20:38:15 [00] ...done
180416 20:38:15 Backup created in directory '/mysql/innobackupex_dir/2018-04-16_20-38-06/'
MySQL binlog position: filename 'my-bin.000043', position '1527'
180416 20:38:15 [00] Writing /mysql/innobackupex_dir/2018-04-16_20-38-06/backup-my.cnf
180416 20:38:15 [00] ...done
180416 20:38:15 [00] Writing /mysql/innobackupex_dir/2018-04-16_20-38-06/xtrabackup_info
180416 20:38:15 [00] ...done
xtrabackup: Transaction log of lsn (2784815) to (2784824) was copied.
180416 20:38:15 completed OK!
--檢視增量備份檔案
[[email protected] 2018-04-16_20-38-06]# cd /mysql/innobackupex_dir/2018-04-16_20-38-06
[[email protected] 2018-04-16_20-38-06]# ll
total 596
-rw-r----- 1 root root 426 Apr 16 20:38 backup-my.cnf
drwxr-x--- 2 root root 4096 Apr 16 20:38 flydb
-rw-r----- 1 root root 315 Apr 16 20:38 ib_buffer_pool
-rw-r----- 1 root root 557056 Apr 16 20:38 ibdata1.delta
-rw-r----- 1 root root 44 Apr 16 20:38 ibdata1.meta
drwxr-x--- 2 root root 4096 Apr 16 20:38 mysql
drwxr-x--- 2 root root 4096 Apr 16 20:38 performance_schema
drwxr-x--- 2 root root 12288 Apr 16 20:38 sys
-rw-r----- 1 root root 19 Apr 16 20:38 xtrabackup_binlog_info
-rw-r----- 1 root root 117 Apr 16 20:38 xtrabackup_checkpoints
-rw-r----- 1 root root 598 Apr 16 20:38 xtrabackup_info
-rw-r----- 1 root root 2560 Apr 16 20:38 xtrabackup_logfile6、innobackupex全量恢復
--刪除flydb 資料庫
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| backup |
| flydb |
| mysql |
| performance_schema |
| sys |
+--------------------+
6 rows in set (0.00 sec)
mysql> drop database flydb;
Query OK, 8 rows affected (0.12 sec)
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| backup |
| mysql |
| performance_schema |
| sys |
+--------------------+
5 rows in set (0.00 sec)
關閉資料庫
[[email protected] ~]# service mysqld stop
Stopping mysqld (via systemctl): [ OK ]
修改資料庫目錄
[[email protected] lib]# mv mysql mysqlbak
--準備恢復(全備份)
--apply-log //恢復準備工作
--redo-only should be used when merging all incrementals except the last one. That’s why the previous
line doesn’t contain the --redo-only option. Even if the --redo-only was used on the last step, backup would
still be consistent but in that case server would perform the rollback phase.
/mysql/innobackupex_dir/2018-04-16_19-56-45/ //全量備份路徑
--準備恢復(全備份)
[[email protected] ~]# innobackupex --apply-log --redo-only /mysql/innobackupex_dir/2018-04-16_19-56-45/
180416 21:33:44 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.4.10 based on MySQL server 5.7.19 Linux (x86_64) (revision id: 3198bce)
xtrabackup: cd to /mysql/innobackupex_dir/2018-04-16_19-56-45/
xtrabackup: This target seems to be not prepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=8388608, start_lsn=(2777815)
xtrabackup: using the following InnoDB configuration for recovery:
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 = 1
xtrabackup: innodb_log_file_size = 8388608
xtrabackup: using the following InnoDB configuration for recovery:
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 = 1
xtrabackup: innodb_log_file_size = 8388608
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.7
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 2777815
InnoDB: Doing recovery: scanned up to log sequence number 2777824 (0%)
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: xtrabackup: Last MySQL binlog file position 2492, file name my-bin.000027
InnoDB: xtrabackup: Last MySQL binlog file position 2492, file name my-bin.000027
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 2777833
InnoDB: Number of pools: 1
180416 21:33:45 completed OK!
--準備恢復(增量備份)
[[email protected] ~]# innobackupex --apply-log /mysql/innobackupex_dir/2018-04-16_19-56-45/ --incremental-dir=/mysql/innobackupex_dir/2018-04-16_20-38-06/
180416 21:39:13 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.4.10 based on MySQL server 5.7.19 Linux (x86_64) (revision id: 3198bce)
incremental backup from 2777815 is enabled.
xtrabackup: cd to /mysql/innobackupex_dir/2018-04-16_19-56-45/
xtrabackup: This target seems to be already prepared with --apply-log-only.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=8388608, start_lsn=(2784815)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup: innodb_log_group_home_dir = /mysql/innobackupex_dir/2018-04-16_20-38-06/
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 8388608
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 54 for flydb/t_list#P#p0, old maximum was 0
xtrabackup: page size for /mysql/innobackupex_dir/2018-04-16_20-38-06//ibdata1.delta is 16384 bytes
Applying /mysql/innobackupex_dir/2018-04-16_20-38-06//ibdata1.delta to ./ibdata1...
......
xtrabackup: page size for /mysql/innobackupex_dir/2018-04-16_20-38-06//mysql/slave_master_info.ibd.delta is 16384 bytes
Applying /mysql/innobackupex_dir/2018-04-16_20-38-06//mysql/slave_master_info.ibd.delta to ./mysql/slave_master_info.ibd...
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup: innodb_log_group_home_dir = /mysql/innobackupex_dir/2018-04-16_20-38-06/
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 8388608
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.7
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 2784815
InnoDB: Doing recovery: scanned up to log sequence number 2784824 (0%)
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: xtrabackup: Last MySQL binlog file position 1527, file name my-bin.000043
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.
InnoDB: 32 non-redo rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.7.19 started; log sequence number 2784824
InnoDB: xtrabackup: Last MySQL binlog file position 1527, file name my-bin.000043
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 2786657
InnoDB: Number of pools: 1
180416 21:39:15 [01] Copying /mysql/innobackupex_dir/2018-04-16_20-38-06/flydb/t_list.frm to ./flydb/t_list.frm
180416 21:39:15 [01] ...done
......
180416 21:39:17 [00] Copying /mysql/innobackupex_dir/2018-04-16_20-38-06//xtrabackup_info to ./xtrabackup_info
180416 21:39:17 [00] ...done
xtrabackup: using the following InnoDB configuration for recovery:
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
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.7
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
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=2786657
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 2786828
InnoDB: Doing recovery: scanned up to log sequence number 2786837 (0%)
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: xtrabackup: Last MySQL binlog file position 1527, file name my-bin.000043
InnoDB: Removed temporary tablespace data file: "ibtmp1"
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.
InnoDB: 32 non-redo rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.7.19 started; log sequence number 2786837
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 2786856
180416 21:39:19 completed OK!
--全量恢復
[[email protected] lib]# innobackupex --defaults-file=/etc/my.cnf --copy-back /mysql/innobackupex_dir/2018-04-16_19-56-45
180416 21:49:39 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.4.10 based on MySQL server 5.7.19 Linux (x86_64) (revision id: 3198bce)
180416 21:49:39 [01] Copying ib_logfile0 to /var/lib/mysql/ib_logfile0
......
180416 21:49:41 [01] Copying ./xtrabackup_info to /var/lib/mysql/xtrabackup_info
180416 21:49:41 [01] ...done
180416 21:49:41 completed OK!
--開啟mysql
[[email protected] ~]# service mysqld start
Starting mysqld (via systemctl): [ OK ]
--登入mysql
[[email protected] ~]# mysql -uroot -p'Root123$'
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.7.19-log MySQL Community Server (GPL)
Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
--檢視flydb存在，全量備份恢復成功
mysql> use flydb
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
--檢視全量備份後，增量備份前的資料在，增量備份恢復成功
mysql> select * from please_recovery_me_t;
+------+
| a |
+------+
| 1 |
| 2 |
+------+
2 rows in set (0.00 sec)
--啟動庫遇到的問題
[[email protected] mysql]# chown -R mysql:mysql mysql/
[[email protected] mysql]# ln -s /tmp/mysql.sock /var/lib/mysql/mysql.sock
[[email protected] mysql]# mkdir -p /var/run/mysqld
[[email protected] mysql]# chown mysql:mysql /var/run/mysqld
[[email protected] mysql]# rm /tmp/mysql.sock
rm: remove regular empty file ‘/tmp/mysql.sock’? yes
7、其他的引數設定選項
The --use-memory option
The preparing process can be speed up by using more memory in it. It depends on the free or available RAM on your
system, it defaults to 100MB. In general, the more memory available to the process, the better. The amount of memory
used in the process can be specified by multiples of bytes:
$ innobackupex --apply-log --use-memory=4G /path/to/BACKUP-DIR
Using the --include option
The regular expression provided to this will be matched against the fully qualified table name, including the database
name, in the form databasename.tablename.
For example,
$ innobackupex --include='^mydatabase[.]mytable' /path/to/backup
Using the --tables-file option
The text file provided (the path) to this option can containmultiple table names, one per line, in the databasename.
tablename format.
For example,
$ echo "mydatabase.mytable" > /tmp/tables.txt
$ innobackupex --tables-file=/tmp/tables.txt /path/to/backup
Using the --databases option
This option accepts either a space-separated list of the databases and tables to backup - in the databasename[.
tablename] form - or a file containing the list at one element per line.
For example,
$ innobackupex --databases="mydatabase.mytable mysql" /path/to/backup
Using the --encrypt-key option
Example of the innobackupex command using the --encrypt-key should look like this
$ innobackupex --encrypt=AES256 --encrypt-key="GCHFLrDFVx6UAsRb88uLVbAVWbK+Yzfs" /data/backups
Streaming and Compressing Backups
Streaming mode, supported by Percona XtraBackup, sends backup to STDOUT in special tar or xbstream format
instead of copying files to the backup directory.
This allows you to use other programs to filter the output of the backup, providing greater flexibility for storage of the
backup. For example, compression is achieved by piping the output to a compression utility. One of the benefits of
streaming backups and using Unix pipes is that the backups can be automatically encrypted.
To use the streaming feature, you must use the --stream, providing the format of the stream (tar or xbstream )
and where to store the temporary files:
$ innobackupex --stream=tar /tmp
innobackupex starts xtrabackup in --log-stream mode in a child process, and redirects its log to a tem-porary file. It then uses xbstream to stream all of the data files to STDOUT, in a special xbstream format. See The
xbstream binary for details. After it finishes streaming all of the data files to STDOUT, it stops xtrabackup and streams
the saved log file too.
When compression is enabled, xtrabackup compresses all output data, except themeta and non-InnoDBfiles which
are not compressed, using the specified compression algorithm. The only currently supported algorithm is quicklz.
The resulting files have the qpress archive format, i.e. every *.qp file produced by xtrabackup is essentially a one-file
qpress archive and can be extracted and uncompressed by the qpress file archiver which is available from Percona
Software repositories.
Using xbstream as a stream option, backups can be copied and compressed in parallel which can significantly speed
up the backup process. In case backups were both compressed and encrypted, they’ll need to decrypted first in order
to be uncompressed.
Examples using xbstream
Store the complete backup directly to a single file:
$ innobackupex --stream=xbstream /root/backup/ > /root/backup/backup.xbstream
To stream and compress the backup:
$ innobackupex --stream=xbstream --compress /root/backup/ > /root/backup/backup.xbstream
To unpack the backup to the /root/backup/ directory:
$ xbstream -x < backup.xbstream -C /root/backup/
To send the compressed backup to another host and unpack it:
$ innobackupex --compress --stream=xbstream /root/backup/ | ssh [email protected]"xbstream -x -C /root/backup/"
Examples using tar
Store the complete backup directly to a tar archive:
$ innobackupex --stream=tar /root/backup/ > /root/backup/out.tar
To send the tar archive to another host:
$ innobackupex --stream=tar ./ | ssh [email protected] \ "cat - > /data/backups/backup.tar"
Warning: To extract Percona XtraBackup‘s archive you must use tar with -i option:
$ tar -xizf backup.tar.gz
Compress with your preferred compression tool:
$ innobackupex --stream=tar ./ | gzip - > backup.tar.gz
$ innobackupex --stream=tar ./ | bzip2 - > backup.tar.bz2
Note that the streamed backup will need to be prepared before restoration. Streaming mode does not prepare the
backup.
Accelerating with --parallel copy and –compress-threads
To use this feature, simply add the option to a local backup, for example:
$ innobackupex --parallel=4 /path/to/backup
To use this feature, simply add the option to a local backup, for example
$ innobackupex --stream=xbstream --compress --compress-threads=4 ./ > backup.xbstream
相關推薦
mysql的xtrabackup備份恢復基本操作
演示環境：作業系統：Linux-x86-64資料庫版本：5.7.19本次演示包括：xtrabackup軟體的安裝， 全量備份，增量備份，恢復 操作附：官方軟體及文件下載地址：https://www.percona.com/software/mysql-database/per
Oracle運維基本操作，倒庫、備份、恢復與優化。
Oracle Linux Centos 系統 運維 Oracle基本操作創建表空間CREATE TABLESPACE test //這裏我們創建的表空間名稱叫做test，名字可以自定義 LOGGING DATAFILE ‘/data/ora01/app/oracle/oradat
基本文件管理，針對Centos7的XFS文件系統備份恢復
centos7的xfs文件系統備份恢復1.1 Linux系統目錄結構，相對/絕對路徑。1.2 創建/復制/刪除文件，rm -rf / 意外事故1.3 查看文件內容1.4 xfs文件系統的備份和恢復在Linux當中一切都是文件1.1.1 linux系統目錄結構[root@centos7 /]# lltot
xtrabackup全備操作和誤刪備份恢復操作
href strong -h 正常 backup 如果 x86 dir 一致性 1.安裝percona源rpm -Uhv http://www.percona.com/downloads/percona-release/percona-release-0.0-1.x86_6
gitlab的基本操作--上傳、下載、庫的遷移／備份及回收／重命名
git gitlab git倉庫遷移 git倉庫備份 git的上傳和下載 gitlab的基本操作--上傳、下載、庫的遷移／備份及回收／重命名 gitlab基本概念GitLab是一個基於 Web 的 Git 倉庫管理工具，且具有wiki 和 issue 跟蹤功能。GitLab 由 GitL
MySQL常用操作（2）MySQL用戶管理、常用sql語句、 MySQL數據庫備份恢復
MySQL用戶管理 MySQL用戶管理創建一個普通用戶並且授權1.grant all on *.* to 'user1' identified by 'passwd';grant all on *.* to 'user1' iden
MongoDB基本操作、備份還原及用戶管理
score 不同 文件的 進程命令 favicon 再次 ESS for 服務器 今日趁周末得空，將近日在學習的MongoDB數據庫常用命令作以下整理，方便工作中查看 MongoDB的邏輯結構主要由文檔、集合和數據庫三部分組成。其中文檔是MongoDB的核心概念，它是Mo
Centos7.5-文件的基本管理和XFS文件系統備份恢復
centos7.2 相對 blog chan 當前 無權限 文件系統 eve 2.3 本節所講內容： 4.1 Linux系統目錄結構和相對/絕對路徑。 4.2 創建/復制/刪除文件，rm -rf / 意外事故 4.3 查看文件內容的命令 4.4 實戰：xfs文件系
Xtrabackup備份、還原、恢復Mysql操作大全
環境：CentOS 6.7 + Mysql 5.7.19 + Xtraback 2.4.8 innobackupex常用引數： --user=USER 指定備份使用者，不指定的話為當前系統使用者 --password=PASSWD
MySQL資料庫基礎操作：安裝+登入+SQL操作語句+資料庫授權、備份、恢復+其他操作
Mysql最流行的RDBMS（關係型資料庫系統），特別是在WEB應用方面：特點 資料以表格的形式出現 每行為各種記錄名稱 每列為記錄名稱所對應的資料域 許多的行和列組成一張表單 若干的表單組成的database RDBMS的一些術語 資料庫、資料表、列、行、外
SQL-基本學習III-資料庫備份恢復
目錄 1備份 核心思想 C++程式碼實現 將資料庫拷貝至其他主機 2恢復 核心思想 C++程式碼實現---採用第一種方法的原理 最近在一
HBase-常用Shell操作及資料備份恢復
1、常用的 Shell 操作 1) satus 例如：顯示伺服器狀態： 2) whoami 例如，顯示 HBase 當前使用者： 3) list 顯示當前所有的表： 4) count 例如，統計指定表的記錄數： 5) describe 展示表
文件的基本管理和XFS文件系統備份恢復
虛擬機 res idt 區號 cpu pts pro 不支持 通過 4.1 Linux系統目錄結構和相對/絕對路徑 4.1.1系統目錄結構 在WIN系統中，查看文件先進入相應的盤符，然後進入文件目錄 在WIN中，它是多根 c:\ d:\ e:\ Linux只
Linux Tar打包 備份 恢復 克隆到新的硬碟 操作流程方法
概述 1.當我們配置系統和環境後，要備份或則克隆到其他硬碟上，該怎麼做呢？下面介紹一下tar方法。我們都知道的Linux系統是萬物皆檔案。那麼系統當然也可以把它當檔案打包,tar是linux下的一個打包工具，下面用的ubuntu系統做示例，看看怎麼操作吧。 一，系
SQL Server 2005的備份、還原及分離、附加基本操作
1.備份 連線好資料庫引擎後，我本地有2個例項，分別是sqlserver、sqltest，如圖（1-1）。 （圖1-1） 以備份sqlserver為例，右擊->任務->備份，如圖（1-2）
Pycharm 的基本操作
har span .com 分享 setting 9.png 單擊 安裝 大小 下載：https://www.jetbrains.com/pycharm/ 安裝：隨意安裝在那個目錄都可以 註冊：可以采用 激活碼 或者激活服務器，並對應在選項下面填入激活碼或者激活服務器URL
萬網中備份數據操作
content ftp工具 nload 放置 生成 enter fcm filezilla 才幹 這段時間跟一哥們搞了一個教程類站點http://www.freeitjc.com。主要是放置精品課程。實現資源的免費共享。然後把這個掛到萬網上去了。用的阿裏雲s
創建RMAN備份 恢復目錄數據庫
efault 只讀表空間 table oracl files 最好 本地 let rac 這是前段時間給客戶做的RMAN備份策略，今天有時間整理出來，希望對大家有些幫助，如有不對的地方歡迎大家給予指點，謝謝！ 創建成恢復目錄數據庫 如果不是在本地配置RMAN 恢復目錄，
目錄基本操作之mkdir命令
用戶 信息 version 上下文 mkdirmkdir命令主要用來創建目錄。語法 mkdir (選項) (參數)選項-Z 設置安全上下文，僅開啟SElinux時有效 -m <目標屬性>或--mode<目標屬性>建立目錄的同時設置目錄的權限 -p或--pa
vue.js的基本操作
操作 copy custom events patch erb one lte methods 1.{{message}}輸出data數據中的message。 2.v-for="todo in todos"輸出data數據中的dotos數組 3.v-on:click="aa