tidb数据库备份（tidb 备份）

一、引言

TiDB 的实施过程并不像一般人所想的那样，做好数据迁移之后完全启用新库，抛弃旧库。新库对上层系统的兼容性需要长时间的测试以及实际生产过程来证明。过程中一旦发生问题，想要恢复将会遇到大问题。所以我们在 TiDB 实施案例中最常听到的单词就是平滑迁移。

何谓平滑迁移？也就是说并不在迁移阶段初始阶段就全部启用 TiDB。而是首先做好数据迁移，数据同步操作。接着将上层系统的读流量接入 TiDB，经过一段时间发现 TiDB 可以胜任读库任务，然后就在此基础上接入写流量。期间使用运维工具将 TiDB 的数据反向同步到 MySQL 以保证万一 TiDB 出现问题无法支持上层业务系统时，能够快速切换到该 MySQL 环境。我们称这个 MySQL 为逃生环境。

迁移 TiDB 数据到 MySQL 有多种方式。早期 TiDB Binlog 作为主流迁移工具，在实际生产中获得大量的实践应用。但是随着TiDB版本更迭，TiDB Binlog已无法完全兼容最新的 TiDB 版本。具体兼容性问题可以查看官方文档

https://link.zhihu.com/?target=https%3A//docs.pingcap.com/zh/tidb/stable/tidb-binlog-overview

今天向大家介绍的是另外一种迁移工具：TiCDC。TiCDC 是一款通过拉取 TiKV 变更日志实现的 TiDB 增量数据同步工具，具有将数据还原到与上游任意 TSO 一致状态的能力，同时提供开放数据协议 (TiCDC Open Protocol)，支持其他系统订阅数据变更。

二、实验环境

实验中使用9台虚拟机，每台虚拟机配置及节点分配如下；

软件环境： TiDB v5.0.0 Sysbench v1.0.20

集群架构如下

实验环境中部署一个PD与一个TiDB以及三个TiKV。TiCDC则部署两个。以上这些组件均使用tiup部署，MySQL部署在10.3.72.80这台机器上。Sysbench作为压测工具，负责向TiDB写入数据。以此触发CDC同步任务。

三、操作过程

1、部署标准集群。

集群内包含PD、TiDB、TiKV、TiCDC、Grafana，Prometheus和Alertmanager组件。

部署配置文件实例如下：

将该配置信息写入配置文件topology.yaml中，并使用tiup发布并启动集群。（主控机与其他机器配置好免密）

启动集群之后验证集群的状态

报告集群状况如下，所有组件状态均为 “UP” 说明当前集群状态良好。

2、使用tiup创建 cdc 同步任务。

首先查看cdc capture list。

结果如下，一共有两个节点，其中10.3.72.86为owner节点，10.3.72.87为从节点。

接着创建cdc同步任务。

接下来可以验证cdc同步任务是否起作用。连接 TiDB server并做建库床表查数据等操作，手动检查MySQL库中是否有对应的库表结构出现以及数据是否一致。

在手动验证阶段，由于数据量十分小，同步任务的延迟也十分低，可以登录 grafana 查看TiCDC的面板，观察到刚才的操作时延只有2ms -4ms。

接着我们使用 Sysbench 运行 oltp_write_only脚本。将表数量设置为10，每张表10w行数据，并发数量为100，模拟较大压力下cdc同步的时延情况。

tidb-config 是提前编写好的配置文件，使用 --config-file 指定即可。如果不指定也可以在命令行中直接指定。如：–mysql-user=root。配置文件内容如下：

经过一段时间的运行，再次打开Grafana的TiCDC监控面板。可以看到 sink write duration指标值有了明显的提高。

四、监控数据解读及结果分析

TiCDC 的监控指标解读可以参考官方文档

https://link.zhihu.com/?target=https%3A//docs.pingcap.com/zh/tidb/stable/monitor-ticdc

在这里我们对两个指标进行一个解读。

两个指标的截图如下图。

Sink write duration

Sink write duration percentile

对于第一张图，主要组成为不同颜色的方块，左侧方块群为 Sysbench prepare阶段也就是创表，创索引，插数据的阶段。这一阶段耗时偏高一点是主要是因为创建索引耗费时间较高。

通过TiDB Dashboard也可以查看慢查询列表中居前几位的都是创建索引。

右侧方块群是 Sysbench 向 TiDB 中写入数据，从而触发 CDC 同步任务。其中小方块的颜色代表该时间段内同步时延落在该范围的数量多少。颜色越深，数量越多。可以观察到大部分分同步任务时延都在 128ms 以内，在这样的集群配置情况下还是比较可观的。

再看第二张图，p95、p99、p999分别代表这同步任务中的前%95、99%、99.9%能在指标值内完成。我们发现最坏情况99.9%的同步任务完成也在1s以内，大部分都在250ms以内完成。这与第一张图其实表达的意思类似。只不过表现形式不同。

以上的这些测试数据都是在指定配置的机器上测试所得，与官方提供的数据可能不太相同。具体最佳性能数据请参考官方提供的数据。

到此这篇tidb数据库备份（tidb 备份）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！

上一篇： st7735s中文数据手册（st7735配置说明）

下一篇：中文期刊全文数据库有哪些（中文期刊类数据库）

版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/sjkxydsj/20191.html

相关文章：