1. BR 备份的支持的后端存储
From tidb doc https://docs.pingcap.com/zh/tidb/v5.0/backup-and-restore-storages#scheme
Scheme
TiDB 迁移工具支持以下存储服务：
| 服务 | Scheme | 示例 |
|---|---|---|
| 本地文件系统（分布在各节点上） | local | local:///path/to/dest/ |
| Amazon S3 及其他兼容 S3 的服务 | s3 | s3://bucket-name/prefix/of/dest/ |
| GCS | gcs, gs | gcs://bucket-name/prefix/of/dest/ |
| 不写入任何存储（仅作为基准测试） | noop | noop:// |
其中 local 的模式我们可以直接使用本地挂载的硬盘，也可以使用 nfs。
2. 使用 local 模式存在的问题
From tidb doc： 使用 BR 命令行进行备份恢复
目前官方并不建议在 BR 备份恢复中使用 local storage。在实际使用中，local storage 也可能存在一些问题：
- 通过 BR 备份的数据会分散到每个 TiKV 上
- 通过 BR 恢复时，需要将每个 TiKV 上的 sst 收集到一起，全量的 sst 文件要复制到每个 TiKV 下
- 大量的小文件在 server 中复制，很容易造成丢包，任何一个 sst 文件的异常，都可能导致恢复失败
- 大量小文件的传输时间远远高于一个同体积的大文件传输时间
- BR 备份的 sst 文件打包压缩，体积并没有明显减小，压缩与解压时间依然消耗巨大
一般来说，我们建议使用 NFS 网盘，或者直接备份到 S3 上。
当我们使用 NFS 网盘恢复的时候，很有可能因为大量的 server 同时读取 NFS，即便我们使用 ratelimit 进行了限速，也会抛出 i/o timeout 的异常。这是一个比较迷惑的报错，从用户的角度上来看，硬盘的 io 不够最多只应该导致性能问题，而不应该导致功能上不可用。
3. 使用 minio 模拟 S3 的对象存储及 API
S3 的好处一大堆，但不选用 S3 的理由也很简单：对不起，我没有。
对于大部分技术人员来说，IDC 的物理设备虽然也有成本的，但下意识还是认为是免费的。如果真的需要申请购买 S3 的存储，流程审核多半通过不了。为了解决这个问题，我们可以考虑通过 IDC 的设备模拟 S3 的协议，搭建一套对象存储系统。目前比较流行的兼容 S3 协议的文件或对象存储有 ceph 和 minio。简单打个比方，同样是拍照，minio 像手机，ceph 像单反。minio 操作简单，运维成本低，不支持在线动态扩容。ceph 功能强大，支持数千结点，支持动态增减结点，自动平衡分布。据了解，阿里云和华为云都是基于 ceph 做的云存储。但是伴随强大的功能，维护成本高到可怕。我在研究 MySQL + 分布式存储的时候，考虑过 MySQL + ceph 的方案。但是高昂的运维成本使我迟迟不敢上线。一般来说，我更建议由专门的团队来维护 ceph。
对于大部分中小型企业，如果不选择存储上云，那么 minio 是一个不错的选择。麻雀虽小，五脏俱全。或者对于大中型企业的某一个独立的业务，minio 也足够能支撑起业务的要求。minio 不仅可以作为对象存储使用，也可以作为云上对象存储服务的网管，无缝对接到 Amazon S3、MicroSoft Azure。
4. 使用 minio S3 接口进行 BR 备份的方案落地
4.1 环境介绍
4.1.1 操作系统环境
在本例中，使用 CentOS Stream release 8 版本。
暂时无法在{app_display_name}文档外展示此内容
4.1.2 硬件环境及机器分配
| HOSTNAME | IP | COMPONENT | COMMENT |
|---|---|---|---|
| r60 | 192.168.232.60 | TiUP | |
| r61 | 192.168.232.61 | TiDB Cluster 1 [tidb-c1] | 1 * TiDB, 1 * PD, 1 * TiKV |
| r62 | 192.168.232.62 | TiDB Cluster 2 [tidb-c2] | 1 * TiDB, 1 * PD, 1 * TiKV |
| r63 | 192.168.232.63 | minio client | |
| r64 | 192.168.232.64 | minio server | |
| r65 | 192.168.232.65 | minio server |
4.2 搭建 minio 环境
4.2.1 minio 目录
目录结构
暂时无法在{app_display_name}文档外展示此内容
数据目录
本例中的 minio 集群由 2 台服务器构成（官方推荐集群最小为 4 台服务器），每台服务器上挂在两个磁盘目录，最小的数据挂载点为 4 个。
暂时无法在{app_display_name}文档外展示此内容
4.2.2 下载 minio server 与 client 执行文件
暂时无法在{app_display_name}文档外展示此内容
4.2.3 创建 minio 启动脚本
暂时无法在{app_display_name}文档外展示此内容
4.2.4 创建 minio 服务文件
暂时无法在{app_display_name}文档外展示此内容
4.2.5 启动 minio 并测试 minio 服务
启动 minio 服务
暂时无法在{app_display_name}文档外展示此内容
测试 minio 服务
浏览器中输入 http://192.168.232.64:9000 或 http://192.168.232.65:9000
4.2.6 minio 客户端命令测试
在下载了 minio 客户端 mc 的机器上可以进行以下的测试
在 mc 客户端添加主机信息
暂时无法在{app_display_name}文档外展示此内容
查看 mc 客户端已经添加的主机信息
暂时无法在{app_display_name}文档外展示此内容
在 minio 中创建 buket
暂时无法在{app_display_name}文档外展示此内容
上传文件到 buket 中
暂时无法在{app_display_name}文档外展示此内容
下载 buket 中的文件
暂时无法在{app_display_name}文档外展示此内容
在 minio 中查看创建的 buket
暂时无法在{app_display_name}文档外展示此内容
4.3 创建 TiDB 集群
4.3.1 使用以下的 yaml 文件创建两套 TiDB 集群
其中 tidb-c1 集群 pd，tidb，tikv 混部在 192.168.232.61 上，tidb-c2 集群 pd，tidb，tikv 混部在 192.168.232.62 上。
暂时无法在{app_display_name}文档外展示此内容
4.3.2 检查 TiDB 集群
暂时无法在{app_display_name}文档外展示此内容
4.3.3 tidb-c1 集群上生成用于备份的数据
暂时无法在{app_display_name}文档外展示此内容
4.4 使用 BR 将数据备份到 minio 上
相关文档参考 使用 BR 命令行进行备份恢复
暂时无法在{app_display_name}文档外展示此内容
4.5 使用 BR 从 minio 恢复数据
暂时无法在{app_display_name}文档外展示此内容
检查 tidb-c2 集群中的数据
暂时无法在{app_display_name}文档外展示此内容
4.6 参数及变量对应说明
以 BR 备份的命令为例
暂时无法在{app_display_name}文档外展示此内容
其中 --storage “s3://br-dir” 表示使用 S3 存储。
br-dir 使我们在 myminio 下创建的 buket 如果 --storage 后面的参数值为 “s3://myminio/br-dir” 会有以下报错
暂时无法在{app_display_name}文档外展示此内容
5. 使用 minio 进行 BR 备份的权限说明
minio 默认为我们提供了五中权限：
- consoleAdmin
- diagnostics
- readonly
- Readwrite
- writeonly
在大多数情况下，这些权限不足以满足复杂的业务需求。在上面的实验中，我们使用了 admin 用户 myminioid。在实际的业务中，我们要针对不同的角色分配不同的用户与 quota。
比如说备份与恢复的场景。我们可以定义 backup-user 与 restore-user。对于 backup-user，我们可以赋予某一个 bucket 的 readwrite 权限。而对于 restore-user，我们赋予 readonly 权限。
在下面的例子中，我们完成了以下的操作
- 创建了用于 BR 备份回复的 bucket test-bucket-br-dir
- 针对于备份操作
- 创建针对 test-bucket-br-dir 的 readwrite 权限 policy-readwrite-brbucket
- 创建 user test-user-br-backup
- 给 test-use-br-backupr 赋予 policy-readwrite-brbucket 权限
- 针对于恢复操作
- 创建针对 test-bucket-br-dir 的 readonly 权限 policy-readonly-brbucket
- 创建 user test-user-br-restore
- 给 test-user -br-restore赋予 policy-readonly-brbucket 权限
5.1 创建 bucket test-bucket-br-dir
暂时无法在{app_display_name}文档外展示此内容
5.2 针对于备份操作，创建一下的权限与用户
5.2.1 创建针对 test-bucket-br-dir 的 readwrite 权限 policy-readwrite-brbucket
模仿 readwrite 权限，我们可以修改只针对与 test-bucket-br-dir，在本例中，我们可以将 “arn:aws:s3::😗” 中的通配符 * 替换成指定的 bucket test-bucket-br-dir
暂时无法在{app_display_name}文档外展示此内容
通过 policy-readwrite-br-bucket.json 文件，我们可以创建 policy-readwrite-br-bucket 权限
暂时无法在{app_display_name}文档外展示此内容
5.2.2 创建 user test-user-br-backup
暂时无法在{app_display_name}文档外展示此内容
6.2.3 给 test-user-br-backup 赋予 policy-readwrite-brbucket 权限
暂时无法在{app_display_name}文档外展示此内容
