mysql之 xtrabackup原理、备份日志分析、备份信息获取

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介:

一、 xtrabackup备份恢复工作原理:

 

                                            extrabackup备份简要步骤

InnoDB引擎很大程度上与Oracle类似,使用redo,undo机制,XtraBackup在备份的时候,以read-write模式打开innodb的数据文件,然后对其进行复制。与此同时,XtraBackup还有另外一个线程监视着transactions log,一旦log发生变化,就把变化过的log pages复制走,直到全部innoDB数据文件复制完成之后,停止监控log buffer及日志复制。如果log buffer没有及时写出将被日志的循环写特性覆盖。xtrabackup在启动时会记住log sequence number(LSN),然后一页一页地复制InnoDB的数据。

xtrabackup在恢复期间对提交的事务前滚,未提交或失败的事务进行回滚,从而保证数据的一致性。因此对于InnoDB表在备份期间不会锁表。由于XtraBackup其内置的InnoDB库打开文件的时候是rw的,所以运行XtraBackup的用户,必须对InnoDB的数据文件具有读写权限。

补充:
1.
在备份innodb page的过程中,XtraBackup每次读写1MB的数据,1MB/16KB=64个page。这个不可配置。读1MB数据之 后,XtraBackup一页一页地遍历这1MB数据,使用innodb的buf_page_is_corrupted()函数检查此页的数据是否正常, 如果数据不正常,就重新读取这一页,最多重新读取10次,如果还是失败,备份就失败了,退出。在复制transactions log的时候,每次读写512KB的数据。同样不可以配置。

2. 如果要使用一个最小权限的用户进行备份,则可基于如下命令创建此类用户:
mysql> CREATE USER 'bkuser'@'localhost' IDENTIFIED BY 'secret';
mysql> REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'bkuser';
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'bkuser'@'localhost';
mysql> FLUSH PRIVILEGES;

二、 完全备份演示及日志分析:
[root@mysql01 full]# innobackupex --user=root --password=oracle /xtrabackup/full/
170602 20:24:02 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!".

170602 20:24:02 Connecting to MySQL server host: localhost, user: root, password: set, port: 3306, socket: not set
Using server version 5.6.25-log
innobackupex version 2.4.7 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 6f7a799)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql/
xtrabackup: open files limit requested 0, set to 1024
## 从配置文件获取有关innodb的配置信息 
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
## 扫描innodb日志lsn并复制inndodb系统表空间
170602 20:24:02 >> log scanned up to (1626057)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 1 for mysql/innodb_table_stats, old maximum was 0
170602 20:24:02 [01] Copying ./ibdata1 to /xtrabackup/full/2017-06-02_20-24-02/ibdata1
170602 20:24:02 [01] ...done
170602 20:24:03 [01] Copying ./mysql/innodb_table_stats.ibd to /xtrabackup/full/2017-06-02_20-24-02/mysql/innodb_table_stats.ibd
。。。。
170602 20:24:03 [01] ...done
170602 20:24:03 [01] Copying ./mysql/slave_master_info.ibd to /xtrabackup/full/2017-06-02_20-24-02/mysql/slave_master_info.ibd
170602 20:24:03 [01] ...done
170602 20:24:03 >> log scanned up to (1626057)
## 缓冲写出到数据文件并锁表
170602 20:24:03 Executing FLUSH NO_WRITE_TO_BINLOG TABLES...
170602 20:24:03 Executing FLUSH TABLES WITH READ LOCK...
## 开始复制非innodb表及相关文件 
170602 20:24:03 Starting to backup non-InnoDB tables and files
170602 20:24:03 [01] Copying ./mysql/help_category.MYI to /xtrabackup/full/2017-06-02_20-24-02/mysql/help_category.MYI
170602 20:24:03 [01] ...done
170602 20:24:03 [01] Copying ./mysql/plugin.frm to /xtrabackup/full/2017-06-02_20-24-02/mysql/plugin.frm
170602 20:24:03 [01] ...done
170602 20:24:03 [01] Copying ./mysql/plugin.MYD to /xtrabackup/full/2017-06-02_20-24-02/mysql/plugin.MYD
。。。。
170602 20:24:05 [01] Copying ./performance_schema/events_stages_history_long.frm to /xtrabackup/full/2017-06-02_20-24-02/performance_schema/events_stages_history_long.frm
170602 20:24:05 [01] ...done
## 结束复制非innodb表及相关文件 
170602 20:24:05 Finished backing up non-InnoDB tables and files
170602 20:24:05 [00] Writing xtrabackup_binlog_info
170602 20:24:05 [00] ...done
## 强制将commit log刷新到redo,保证事务是完整的
170602 20:24:05 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
## 获取最新的lsn
xtrabackup: The latest check point (for incremental): '1626057'
xtrabackup: Stopping log copying thread.
.170602 20:24:05 >> log scanned up to (1626057)
## 释放锁
170602 20:24:05 Executing UNLOCK TABLES
170602 20:24:05 All tables unlocked
## 列出备份位置
170602 20:24:05 Backup created in directory '/xtrabackup/full/2017-06-02_20-24-02/'
## 列出binlog的位置
MySQL binlog position: filename 'binlog.000001', position '120'
170602 20:24:05 [00] Writing backup-my.cnf
170602 20:24:05 [00] ...done
170602 20:24:05 [00] Writing xtrabackup_info
170602 20:24:05 [00] ...done
xtrabackup: Transaction log of lsn (1626057) to (1626057) was copied.
170602 20:24:05 completed OK!

三、获取备份的相关信息
1. 查看备份期间生成的文件
[root@mysql01 full]# ls /xtrabackup/full/2017-06-02_20-24-02/
backup-my.cnf performance_schema xtrabackup_checkpoints
ibdata1 test xtrabackup_info
mysql xtrabackup_binlog_info xtrabackup_logfile
说明:

2. 查看备份有关的总体信息 
[root@mysql01 full]# more /xtrabackup/full/2017-06-02_20-24-02/xtrabackup_info
uuid = 5e8841af-478e-11e7-a0d7-000c2944297a
name = 
tool_name = innobackupex
tool_command = --user=root --password=... /xtrabackup/full/
tool_version = 2.4.7
ibbackup_version = 2.4.7
server_version = 5.6.25-log
start_time = 2017-06-02 20:24:02
end_time = 2017-06-02 20:24:05
lock_time = 0
binlog_pos = filename 'binlog.000001', position '120'
innodb_from_lsn = 0
innodb_to_lsn = 1626057
partial = N
说明>xtrabackup_info 记录: 整个备份信息的概要
3. 查看备份检查点的相关信息 
[root@mysql01 full]# more /xtrabackup/full/2017-06-02_20-24-02/xtrabackup_checkpoints 
backup_type = full-backuped
from_lsn = 0
to_lsn = 1626057
last_lsn = 1626057
compact = 0
recover_binlog_info = 0
说明>xtrabackup_checkpoints 记录:备份类型(如完全或增量)、备份状态(如是否已经为prepared状态)和LSN(日志序列号)范围信息; 
4. 查看备份binlog有关的信息 
[root@mysql01 full]# more /xtrabackup/full/2017-06-02_20-24-02/xtrabackup_binlog_info 
binlog.000001 120
说明>xtrabackup_binlog_info记录: mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。
5. 查看备份命令的配置选项信息
[root@mysql01 full]# more /xtrabackup/full/2017-06-02_20-24-02/backup-my.cnf 
# This MySQL options file was generated by innobackupex.
# The MySQL server
[mysqld]
innodb_checksum_algorithm=innodb
innodb_log_checksum_algorithm=innodb
innodb_data_file_path=ibdata1:12M:autoextend
innodb_log_files_in_group=2
innodb_log_file_size=50331648
innodb_fast_checksum=false
innodb_page_size=16384
innodb_log_block_size=512
innodb_undo_directory=.
innodb_undo_tablespaces=0

文章可以转载,必须以链接形式标明出处。



本文转自 张冲andy 博客园博客,原文链接: http://www.cnblogs.com/andy6/p/6932788.html   ,如需转载请自行联系原作者
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
1天前
|
存储 关系型数据库 MySQL
利用Cron表达式实现MySQL数据库的定时备份
以上就是如何使用Cron表达式和mysqldump命令实现MySQL数据库的定时备份。这种方法的优点是简单易用,而且可以根据需要定制备份的时间和频率。但是,它也有一些限制,例如,它不能备份MySQL服务器的配置文件和用户账户信息,也不能实现增量备份。如果需要更复杂的备份策略,可能需要使用专门的备份工具或服务。
29 15
|
6天前
|
关系型数据库 MySQL Linux
在Linux环境下备份Docker中的MySQL数据并传输到其他服务器以实现数据级别的容灾
以上就是在Linux环境下备份Docker中的MySQL数据并传输到其他服务器以实现数据级别的容灾的步骤。这个过程就像是一场接力赛,数据从MySQL数据库中接力棒一样传递到备份文件,再从备份文件传递到其他服务器,最后再传递回MySQL数据库。这样,即使在灾难发生时,我们也可以快速恢复数据,保证业务的正常运行。
64 28
|
13天前
|
SQL 运维 关系型数据库
MySQL Binlog 日志查看方法及查看内容解析
本文介绍了 MySQL 的 Binlog(二进制日志)功能及其使用方法。Binlog 记录了数据库的所有数据变更操作,如 INSERT、UPDATE 和 DELETE,对数据恢复、主从复制和审计至关重要。文章详细说明了如何开启 Binlog 功能、查看当前日志文件及内容,并解析了常见的事件类型,包括 Format_desc、Query、Table_map、Write_rows、Update_rows 和 Delete_rows 等,帮助用户掌握数据库变化历史,提升维护和排障能力。
|
13天前
|
存储 监控 API
【Azure App Service】分享使用Python Code获取App Service的服务器日志记录管理配置信息
本文介绍了如何通过Python代码获取App Service中“Web服务器日志记录”的配置状态。借助`azure-mgmt-web` SDK,可通过初始化`WebSiteManagementClient`对象、调用`get_configuration`方法来查看`http_logging_enabled`的值,从而判断日志记录是否启用及存储方式(关闭、存储或文件系统)。示例代码详细展示了实现步骤,并附有执行结果与官方文档参考链接,帮助开发者快速定位和解决问题。
63 22
|
21天前
|
关系型数据库 MySQL Shell
MySQL 备份 Shell 脚本:支持远程同步与阿里云 OSS 备份
一款自动化 MySQL 备份 Shell 脚本,支持本地存储、远程服务器同步(SSH+rsync)、阿里云 OSS 备份,并自动清理过期备份。适用于数据库管理员和开发者,帮助确保数据安全。
|
1月前
|
SQL 缓存
【YashanDB知识库】YashanDB run.log中有slow log queue is full信息
【YashanDB知识库】YashanDB run.log中有slow log queue is full信息
|
1月前
|
SQL 存储 关系型数据库
简单聊聊MySQL的三大日志(Redo Log、Binlog和Undo Log)各有什么区别
在MySQL数据库管理中,理解Redo Log(重做日志)、Binlog(二进制日志)和Undo Log(回滚日志)至关重要。Redo Log确保数据持久性和崩溃恢复;Binlog用于主从复制和数据恢复,记录逻辑操作;Undo Log支持事务的原子性和隔离性,实现回滚与MVCC。三者协同工作,保障事务ACID特性。文章还详细解析了日志写入流程及可能的异常情况,帮助深入理解数据库日志机制。
114 0
|
1月前
|
数据可视化 关系型数据库 MySQL
ELK实现nginx、mysql、http的日志可视化实验
通过本文的步骤,你可以成功配置ELK(Elasticsearch, Logstash, Kibana)来实现nginx、mysql和http日志的可视化。通过Kibana,你可以直观地查看和分析日志数据,从而更好地监控和管理系统。希望这些步骤能帮助你在实际项目中有效地利用ELK来处理日志数据。
248 90
|
1月前
|
自然语言处理 搜索推荐 关系型数据库
MySQL实现文档全文搜索,分词匹配多段落重排展示,知识库搜索原理分享
本文介绍了在文档管理系统中实现高效全文搜索的方案。为解决原有ES搜索引擎私有化部署复杂、运维成本高的问题,我们转而使用MySQL实现搜索功能。通过对用户输入预处理、数据库模糊匹配、结果分段与关键字标红等步骤,实现了精准且高效的搜索效果。目前方案适用于中小企业,未来将根据需求优化并可能重新引入专业搜索引擎以提升性能。
118 5
|
2月前
|
关系型数据库 MySQL 数据库
MySQL日志
本文介绍了MySQL中三个重要的日志:binlog、redolog和undolog。binlog记录数据库更改操作,支持数据恢复、复制和审计;redolog保证事务的原子性和持久性,实现crash-safe;undolog用于事务回滚及MVCC的实现。每个日志都有其独特的作用和应用场景,确保数据库的稳定性和数据一致性。

热门文章

最新文章