济南网站建设公司推荐,树莓派做网站服务器,网站logo大全,百度手机app下载并安装在这篇博文中#xff0c;我们将描述 Percona XtraBackup 8.0.33-28 的改进#xff0c;这显著减少了备份准备所需的时间#xff0c;以便进行恢复操作。 Percona XtraBackup 中的这一改进显着缩短了新节点加入 Percona XtraDB 集群#xff08;PXC#xff09; 所需的时间。
…在这篇博文中我们将描述 Percona XtraBackup 8.0.33-28 的改进这显著减少了备份准备所需的时间以便进行恢复操作。 Percona XtraBackup 中的这一改进显着缩短了新节点加入 Percona XtraDB 集群PXC 所需的时间。
Percona XtraDB Cluster 使用 Percona XtraBackup 在节点之间执行 SST状态快照传输。当一个新节点加入集群时会从 DONOR 到 JOINER 执行 SST。 JOINER 使用 PXB 从 DONOR 流式传输数据目录。 JOINER 必须在使用它之前准备备份。 观察到当 DONOR 拥有大量表空间一百万个时JOINER 一侧的 XtraBackup 无法完成数据准备阶段xtrabackup -prepare。
Prepare 阶段
Percona XtraBackup 复制 InnoDB 数据文件。数据在服务器并发修改数据文件时内部不一致因为服务器并发地修改数据文件。 Percona XtraBackup 对文件执行崩溃恢复以再次创建一致的可用数据库。 这称为 Prepare 操作xtrabackup -prepare。
XtraBackup Prepare 操作分两个阶段进行
Redo Log 应用Undo Log 应用
Redo Log 应用阶段
将 Redo Log 文件修改的更改应用于页面。 此阶段没有行或事务的概念。Redo 应用阶段不会使数据库与事务一致。服务器可以刷新或写入未提交事务的更改到 Redo Log 中。 XtraBackup 仍应用记录在 Redo Log 中的修改并且 Redo Log 应用阶段不会撤消这些更改。为此我们必须使用 Undo Log。
Undo Log 应用阶段
Undo Log 应用阶段也称为回滚阶段将读取 Undo Log 页面中的更改以撤消事务。然后它们再次应用于页面例如再次写入旧值并写入磁盘。在此阶段之后备份过程中所有未提交的事务都会被回滚。
Undo Log 记录有两种类型INSERT Undo Log 记录和 UPDATE Undo Log 记录。 删除记录标记被视为 UPDATE UNDO Log 记录的子类型。
格式如下所示 当服务器写入这些记录时它不会与每个记录一起写入索引/表信息。它只将“table_id”写入作为 UNDO LOG 记录的一部分。 table_id 用于获取表架构。 从 Undo Log 记录中获取表架构和关键字段用于创建索引搜索元组Key。 此搜索元组Key用于查找要执行撤消操作的记录。
所以给定一个 table_id你如何获取表架构/定义?
在服务器上初始化“数据字典”DD引擎和 DD 缓存后存储引擎可以请求表定义。例如InnoDB 根据也称为“se_private_id”的 table_id 请求表定义。
与服务器不同Percona XtraBackup 无法访问“数据字典”DD。初始化 DD 引擎和缓存会增加复杂性和其他服务器依赖项。XtraBackup 不会简单地像服务器一样访问表对象。
为何 Percona XtraBackup 受到数以千计的企业信赖
Percona XtraBackup 初始化 InnoDB 引擎并需要所有目的回滚、导出等的“InnoDB 表对象”也称为 dict_table_t。XtraBackup 依靠序列化字典信息SDI。 这是表的 JSON 表示形式。 对于 InnoDB 表空间该信息存储在表空间内。从 8.0 开始IBD 文件是“自描述的”例如表架构在 IBD 文件中可用。 让我们看一个示例表。
CREATE TABLE test.t1(a INT PRIMARY KEY, b INT);CREATE TABLE 语句在 test 目录中创建一个名为 t1.ibd 的文件。例如mysql datadir/test/t1.ibd。 因此 t1.ibd 包含有关表结构列、它们的类型、索引数量、索引中的列、外键等的信息作为 SDI。 使用名为“ibd2sdi”的工具从 IBD 文件中提取 SDI。
ibd2sdi data/test/t1.ibd t1.sdi如您所见表名在“dd_object:name”字段中列信息存储在“dd_object:columns”数组中。 以往的设计8.0.33-28 之前 XtraBackup 从每个 IBD 读取 SDI 并将 每个 IBD 中的所有表加载到缓存中作为不可驱逐的。本质上通过将表加载为不可驱逐来禁用 LRU 缓存。 每个表保留在内存中直到 XtraBackup 退出。
这种方法的问题
加载不需要回滚的表。从读取表的 SDI 页面进行不必要的 IO 操作。加载不必要的表会增加准备所需的时间。占用内存可能导致 OOM。如果备份目录包含大量 表/IBD 文件则会导致 XtraBackup Prepare 操作崩溃。加入 PXC 集群的节点需要更多内存并花费很长时间加入集群。
为什么 XtraBackup 会将表加载为“不可驱逐”我们可以只是将它们加载为可驱逐来解决问题吗假设一个表被驱逐必须再次加载它。XtraBackup 将如何知道包含被驱逐表的表空间IBD它必须再次扫描每个 IBD 才能找到被驱逐的表。
新的设计8.0.33-28 开始)
为了将表加载为可驱逐的必须建立 table_id 和包含表的表空间 space_id 之间的关系。它是通过扫描数据字典表 mysql.indexes 和 mysql.index_partitions 的 B 树页面完成的。
建立此 table_id→space_id 关系后它将在事务回滚期间使用。在这种新设计中只有在它们上面有事务回滚时才会加载用户表。
新设计如下 当达到缓存大小限制或由后台主线程时缓存中的表将被逐出。
新设计的好处xtrabackup -prepare
使用更少的内存使用更少的 IO更快的准备即使有大量表也能成功完成节点更快地完成 SST 过程并快速加入 PXC 集群节点需要更少的内存才能加入 PXC 集群
压测 在其他大小的备份目录上对 xtrabackup -prepare 进行基准测试如 10K、50K、100K 和 250K 表。性能改进如下 结论
正如您所见从 Percona XtraBackup 8.0.33-28 开始具有字典缓存的 xtrabackup -prepare 更快、更高效。 改进将取决于备份目录中的表空间文件IBD数量。 新节点加入 PXC 集群所需的时间也大大减少因为 SST 过程将更快完成。
更多技术文章请访问https://opensource.actionsky.com/
关于 SQLE
爱可生开源社区的 SQLE 是一款面向数据库使用者和管理者支持多场景审核支持标准化上线流程原生支持 MySQL 审核且数据库类型可扩展的 SQL 审核工具。
SQLE 获取
类型地址版本库https://github.com/actiontech/sqle文档https://actiontech.github.io/sqle-docs/发布信息https://github.com/actiontech/sqle/releases数据审核插件开发文档https://actiontech.github.io/sqle-docs/docs/dev-manual/plugins/howtouse
