【TiDB原理与实战详解】5、BR 物理备份恢复与Binlog 数据同步~学不会? 不存在的!

本文涉及的产品
云原生内存数据库 Tair,内存型 2GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: BR(Backup & Restore)是 TiDB 分布式备份恢复的命令行工具,适用于大数据量场景,支持常规备份恢复及大规模数据迁移。BR 通过向各 TiKV 节点下发命令执行备份或恢复操作,生成 SST 文件存储数据信息与 `backupmeta` 文件存储元信息。推荐部署配置包括在 PD 节点部署 BR 工具,使用万兆网卡等。本文介绍 BR 的工作原理、部署配置、使用限制及多种备份恢复方式,如全量备份、单库/单表备份、过滤备份及增量备份等。

BR 物理备份恢复

BR 全称为 Backup & Restore,是 TiDB 分布式备份恢复的命令行工具,用于对 TiDB 集群进行数据备份和恢复。

相比 dumpling,BR 更适合大数据量的场景。

BR 除了可以用来进行常规备份恢复外,也可以在保证兼容性前提下用来做大规模的数据迁移。

本文介绍了 BR 的工作原理、推荐部署配置、使用限制以及几种使用方式。

1、工作原理

BR 将备份或恢复操作命令下发到各个 TiKV 节点。TiKV 收到命令后执行相应的备份或恢复操作。

在一次备份或恢复中,各个 TiKV 节点都会有一个对应的备份路径,TiKV 备份时产生的备份文件将会保存在该路径下,恢复时也会从该路径读取相应的备份文件。

image.png

2、备份文件类型

备份路径下会生成以下两种类型文件:

  • SST 文件:存储 TiKV 备份下来的数据信息
  • backupmeta 文件:存储本次备份的元信息,包括备份文件数、备份文件的 Key 区间、备份文件大小和备份文件 Hash (sha256) 值
  • backup.lock 文件:用于防止多次备份到同一目录

SST 文件命名格式

SST 文件以 storeID_regionID_regionEpoch_keyHash_cf 的格式命名。格式名的解释如下:

  • storeID:TiKV 节点编号
  • regionID:Region 编号
  • regionEpoch:Region 版本号
  • keyHash:Range startKey 的 Hash (sha256) 值,确保唯一性
  • cf:RocksDB 的 ColumnFamily(默认为 defaultwrite**

3、部署BR工具

推荐部署配置

将BR工具部署在PD节点,然后在tikv节点挂载远程目录,使用万兆网卡,减少带宽瓶颈。

恢复数据时需要关闭TiCDC同步。

使用BR 5.3.0以上版本

备份和恢复 mysql 系统库下的表数据(实验特性)

备份系统表但是不能完全恢复到系统表中

BR最低配置

CPU 内存 硬盘类型 网络
1 核 4 GB HDD 千兆网卡

一般场景下(备份恢复的表少于 1000 张),BR 在运行期间的 CPU 消耗不会超过 200%,内存消耗不会超过 4 GB。但在备份和恢复大量数据表时,BR 的内存消耗可能会上升到 4 GB 以上。在实际测试中,备份 24000 张表大概需要消耗 2.7 GB 内存,CPU 消耗维持在 100% 以下。

pd节点 下载BR工具

wget https://download.pingcap.org/tidb-toolkit-v5.3.0-linux-amd64.tar.gz
tar  xf tidb-toolkit-v5.3.0-linux-amd64.tar.gz
cd /root/tidb-toolkit-v5.3.0-linux-amd64/bin

命令和子命令

BR 由多层命令组成。目前,BR 包含 `backup`、`restore` 和 `version` 三个子命令:

br backup  用于备份 TiDB 集群
br restore 用于恢复 TiDB 集群

以上三个子命令可能还包含这些子命令:

full: 可用于备份或恢复全部数据。
db:   可用于备份或恢复集群中的指定数据库。
table:可用于备份或恢复集群指定数据库中的单张表。

常用选项

--pd:  用于连接的选项,表示 PD 服务地址,例如 "${PDIP}:2379"。
-h/--help: 获取所有命令和子命令的使用帮助。例如 br backup --help。
-V(或 --version): 检查 BR 版本。
--ca:  指定 PEM 格式的受信任 CA 的证书文件路径。
--cert:指定 PEM 格式的 SSL 证书文件路径。
--key: 指定 PEM 格式的 SSL 证书密钥文件路径。
--status-addr:BR 向 Prometheus 提供统计数据的监听地址。
--ratelimit:线程数,越大速度越快,但是对生产环境影响越大。

4、全量备份恢复

备份

# 创建备份路径
mkdir  -p /data01/backup/
# 授权备份路径
chown -R tidb:tidb  /data01/backup
# 开始备份
/root/tidb-toolkit-v5.3.0-linux-amd64/bin/br backup full \
    --pd "10.10.8.107:2379" \
    --storage "local:///data01/backup" \
    --ratelimit 128 \  # 线程数
    --log-file backupfull.log

恢复

/root/tidb-toolkit-v5.3.0-linux-amd64/bin/br restore full \
    --pd "10.10.8.107:2379" \
    --storage "local:///data01/backup" \
    --ratelimit 128 \
    --log-file restorefull.log

5、单库备份恢复

备份

# 创建备份路径
mkdir  -p /data01/backup/a
# 授权备份路径
chown -R tidb:tidb  /data01/backup/a
# 开始备份    
/root/tidb-toolkit-v5.3.0-linux-amd64/bin/br backup db \
    --pd "10.10.8.107:2379" \
    --db a \
    --storage "local:///data01/backup/a" \
    --ratelimit 128 \
    --log-file backuptable.log

恢复

/root/tidb-toolkit-v5.3.0-linux-amd64/bin/br restore db \
    --pd "10.10.8.107:2379" \
    --db "a" \
    --ratelimit 128 \
    --storage "local:///data01/backup/a" \
    --log-file restorefull.log

6、单表备份恢复

备份

# 创建备份路径
mkdir  -p /data01/backup/a/t1
# 授权备份路径
chown -R tidb:tidb  /data01/backup/a/t1
# 开始备份  
/root/tidb-toolkit-v5.3.0-linux-amd64/bin/br backup table \
    --pd "10.10.8.107:2379" \
    --db a \
    --table t1 \
    --storage "local:///data01/backup/a/t1" \
    --ratelimit 128 \
    --log-file backuptable.log

恢复

/root/tidb-toolkit-v5.3.0-linux-amd64/bin/br  restore table \
    --pd "10.10.8.107:2379" \
    --db  "a" \
    --table "t1" \
    --ratelimit 128 \
    --storage "local:///data01/backup/a/t1" \
    --log-file restorefull.log

7、过滤备份恢复

正则过滤库表恢复

/root/tidb-toolkit-v5.3.0-linux-amd64/bin/br restore full \
    --pd "10.10.8.107:2379" \
    --filter 'a*.t*' \
    --storage "local:///data01/backup/a" \
    --log-file restorefull.log

指定过滤库表恢复 --filter指定多个表

/root/tidb-toolkit-v5.3.0-linux-amd64/bin/br restore full \
    --pd "10.10.8.107:2379" \
    --filter 'a.t1' \
    --filter 'a.t2' \  
    --storage "local:///data01/backup/a" \
    --log-file restorefull.log

8、增量备份恢复

可以进行做一个全量备份,多个增量备份。

如果需要多次增量备份需要调整tikv_gc_life_time参数,调整后需要先进行全备在进行增备,因为在你修改参数之前tikv可能已经GC过了,这会清理掉之前的数据版本信息,导致备份失败

修改tikv_gc_life_time参数默认时间(当你将tikv_gc_life_time参数修改为24小时后,如果你超过24小时没有进行增量备份将需要重新进行全量备份)

UPDATE mysql.tidb SET VARIABLE_VALUE = '24h' WHERE VARIABLE_NAME = 'tikv_gc_life_time';

先进行全量备份

# 创建备份路径
mkdir  -p /data01/backup/all
# 授权备份路径
chown -R tidb:tidb  /data01/backup/all
# 开始备份
/root/tidb-toolkit-v5.3.0-linux-amd64/bin/br backup full \
    --pd "10.10.8.107:2379" \
    --storage "local:///data01/backup/all" \
    --ratelimit 128 \
    --log-file backupfull.log

获取时间戳

/root/tidb-toolkit-v5.3.0-linux-amd64/bin/br  validate decode --field="end-version" -s "local:///data01/backup/all" | tail -n1

Detail BR log in /tmp/br.log.2022-02-14T12.03.02+0800 
431177486559608836  # 就是这个

指定时间戳进行增量备份

# 创建备份路径
mkdir  -p /data01/backup/inc0
# 授权备份路径
chown -R tidb:tidb  /data01/backup/inc0

/root/tidb-toolkit-v5.3.0-linux-amd64/bin/br backup full\
    --pd 10.10.8.107:2379 \
    --ratelimit 128 \
    -s "local:///data01/backup/inc0" \
    --lastbackupts 431177486559608836

必须按照备份的顺序进行增量的恢复

先指定全量备份路径进行恢复

/root/tidb-toolkit-v5.3.0-linux-amd64/bin/br restore full \
    --pd "10.10.8.107:2379" \
    --storage "local:///data01/backup/all" \
    --ratelimit 128 \
    --log-file restorefull.log

在指定增量备份路径进行恢复

/root/tidb-toolkit-v5.3.0-linux-amd64/bin/br restore full \
    --pd "10.10.8.107:2379" \
    --storage "local:///data01/backup/inc0" \
    --ratelimit 128 \
    --log-file restorefull.log

TiDB Binlog 数据同步工具

TiDB Binlog 是一个用于收集 TiDB 的 binlog,并提供准实时备份和同步功能的商业工具。

  • 数据同步:同步 TiDB 集群数据到其他数据库
  • 实时备份和恢复:备份 TiDB 集群数据,同时可以用于 TiDB 集群故障时恢复

image.png

1、tiup安装binlogctl工具

tiup ctl:v5.2.0 binlog

2、配置

查看是否开启binlog

show variables like "log_bin";# 0 代表关闭,1 代表开启

开启binlog

# 编辑配置文件
tiup cluster edit-config test

# server_configs标签添加如下内容
server_configs:
  tidb:
    log.slow-threshold: 300
    binlog.enable: true
    binlog.ignore-error: true

重载配置

# 查看集群节点信息
tiup  cluster display test

# 重载tidb节点
tiup cluster reload test -N 10.10.8.107:4000

查看是否开启binlog

show variables like "log_bin";# 0 代表关闭,1 代表开启
相关文章
|
18天前
|
关系型数据库 MySQL 调度
【TiDB原理与实战详解】4、DM 迁移和TiCDC数据同步~学不会? 不存在的!
TiDB Data Migration (DM) 和 TiCDC 是两款用于数据库迁移和同步的强大工具。DM 支持将兼容 MySQL 协议的数据库(如 MySQL、MariaDB)的数据异步迁移到 TiDB 中,具备全量和增量数据传输能力,并能合并分库分表的数据。TiCDC 则专注于 TiDB 的增量同步,利用 TiKV 日志实现高可用性和水平扩展,支持多种下游系统和输出格式。两者均可通过 TiUP 工具进行部署与管理,简化了集群的安装、配置及任务管理过程。
|
1月前
|
SQL canal 关系型数据库
(二十四)全解MySQL之主从篇:死磕主从复制中数据同步原理与优化
兜兜转转,经过《全解MySQL专栏》前面二十多篇的内容讲解后,基本对MySQL单机模式下的各方面进阶知识做了详细阐述,同时在前面的《分库分表概念篇》、《分库分表隐患篇》两章中也首次提到了数据库的一些高可用方案,但前两章大多属于方法论,并未涵盖真正的实操过程。接下来的内容,会以目前这章作为分割点,开启MySQL高可用方案的落地实践分享的新章程!
592 1
|
30天前
|
canal 关系型数据库 MySQL
"揭秘阿里数据同步黑科技Canal:从原理到实战,手把手教你玩转MySQL数据秒级同步,让你的数据处理能力瞬间飙升,成为技术界的新晋网红!"
【8月更文挑战第18天】Canal是一款由阿里巴巴开源的高性能数据同步系统,它通过解析MySQL的增量日志(Binlog),提供低延迟、可靠的数据订阅和消费功能。Canal模拟MySQL Slave与Master间的交互协议来接收并解析Binary Log,支持数据的增量同步。配置简单直观,包括Server和Instance两层配置。在实战中,Canal可用于数据库镜像、实时备份等多种场景,通过集成Canal Client可实现数据的消费和处理,如更新缓存或写入消息队列。
233 0
|
29天前
|
SQL DataWorks 关系型数据库
DataWorks操作报错合集之如何处理数据同步时(mysql->hive)报:Render instance failed
DataWorks是阿里云提供的一站式大数据开发与治理平台,支持数据集成、数据开发、数据服务、数据质量管理、数据安全管理等全流程数据处理。在使用DataWorks过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
|
16天前
|
canal 消息中间件 关系型数据库
Canal作为一款高效、可靠的数据同步工具,凭借其基于MySQL binlog的增量同步机制,在数据同步领域展现了强大的应用价值
【9月更文挑战第1天】Canal作为一款高效、可靠的数据同步工具,凭借其基于MySQL binlog的增量同步机制,在数据同步领域展现了强大的应用价值
104 4
|
28天前
|
关系型数据库 MySQL 数据库
【MySQL】手把手教你MySQL数据同步
【MySQL】手把手教你MySQL数据同步
|
1月前
|
SQL 关系型数据库 MySQL
“震撼揭秘!Flink CDC如何轻松实现SQL Server到MySQL的实时数据同步?一招在手,数据无忧!”
【8月更文挑战第7天】随着大数据技术的发展,实时数据同步变得至关重要。Apache Flink作为高性能流处理框架,在实时数据处理领域扮演着核心角色。Flink CDC(Change Data Capture)组件的加入,使得数据同步更为高效。本文介绍如何使用Flink CDC实现从SQL Server到MySQL的实时数据同步,并提供示例代码。首先确保SQL Server启用了CDC功能,接着在Flink环境中引入相关连接器。通过定义源表与目标表,并执行简单的`INSERT INTO SELECT`语句,即可完成数据同步。
100 1
|
2月前
|
分布式计算 关系型数据库 MySQL
MySQL超时参数优化与DataX高效数据同步实践
通过合理设置MySQL的超时参数,可以有效地提升数据库的稳定性和性能。而DataX作为一种高效的数据同步工具,可以帮助企业轻松实现不同数据源之间的数据迁移。无论是优化MySQL参数还是使用DataX进行数据同步,都需要根据具体的应用场景来进行细致的配置和测试,以达到最佳效果。
|
2月前
|
分布式计算 关系型数据库 MySQL
MaxCompute产品使用合集之用flink mysql的数据同步到mc的Transaction Table2.0,时间会比mysql的时间多8小时,是什么导致的
MaxCompute作为一款全面的大数据处理平台,广泛应用于各类大数据分析、数据挖掘、BI及机器学习场景。掌握其核心功能、熟练操作流程、遵循最佳实践,可以帮助用户高效、安全地管理和利用海量数据。以下是一个关于MaxCompute产品使用的合集,涵盖了其核心功能、应用场景、操作流程以及最佳实践等内容。
|
4月前
|
SQL Kubernetes 关系型数据库
实时计算 Flink版产品使用合集之如何实现MySQL单表数据同步到多个表
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStreamAPI、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。