TiDB 如何用 docker-compose 配合 BR 完成第一次全量备份与恢复【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址: https://gitcode.com/GitHub_Trending/ti/tidb如果你想在本机快速跑通 BRBackup Restore的第一次全量备份与恢复TiDB 仓库的 br/README.md 提供了一个基于 docker-compose 的 Quick start一条命令拉起一个可写数据的 TiDB 测试集群然后在control容器里用br命令行工具完成写入数据 → 全量备份 → 删库 → 恢复 → 校验行数的完整闭环。本文按该 Quick start 的顺序拆解每一步说明每个命令的作用、参数含义和如何判断结果正确。前提是本机已安装 Docker 和 docker-compose且当前目录为仓库中的br/目录下文所有docker-compose -f docker-compose.yaml ...命令都假定在这里执行。docker-compose 集群里有什么br/docker-compose.yaml 定义了以下服务理解它们有助于后面判断命令为什么能跑通control控制容器由 br/docker/Dockerfile 构建。它以golang:1.18.9-alpine为基础预装了写数据用的go-ycsb和 S3 客户端mc并把br/源码整体复制进/go/src/github.com/pingcap/br。备份、恢复等 BR 操作都在这个容器里执行。pd0PD 服务镜像为pingcap/pd:nightly宿主端口2379。tikv0tikv45 个 TiKV 节点镜像为pingcap/tikv:nightly。tidbTiDB SQL 前端镜像为pingcap/tidb:nightly对外暴露4000SQL和10080端口。minioS3 兼容存储可选分支使用配合 br/docker/minio.env 中的环境变量。几个挂载关系需要记住后面验证备份文件位置时会用到容器内路径宿主机路径用途/data/tmp/br/docker/dataTiKV/PD 数据、备份文件/logs/tmp/br/docker/logs各服务与 BR 的日志仓库内./bin容器内/go/src/github.com/pingcap/br/binbr可执行文件注意 PD、TiKV、TiDB 都使用nightly标签镜像这是仓库文档给出的组合本文不做替换。启动集群# Start TiDB cluster docker-compose -f docker-compose.yaml rm -s -v \ docker-compose -f docker-compose.yaml build \ docker-compose -f docker-compose.yaml up --remove-orphans这条命令链有三段rm -s -v会停止并删除该 compose 项目的已有容器和命名卷属于清理性操作——它会清掉上一次运行遗留的集群状态第一次执行时如果项目未运行过这一步基本无副作用。build按 br/docker/Dockerfile 构建control:nightly镜像构建过程会联网拉取 go-ycsb 依赖。up --remove-orphans启动全部服务。启动完成后宿主机的127.0.0.1:4000可以连到 TiDB127.0.0.1:2379是 PD 端点备份、恢复等 BR 操作则在容器网络内通过服务名访问。进入 control 容器并写入测试数据# Attach to control container to run BR docker exec -it br_control_1 bash进入容器后用镜像里预装的go-ycsb写入 10 万行测试数据go-ycsb load mysql -p workloadcore \ -p mysql.hosttidb -p mysql.port4000 -p mysql.userroot \ -p recordcount100000 -p threadcount100这里mysql.hosttidb、mysql.port4000指向 compose 网络内的 TiDB 服务数据落在test.usertable表。写入行数由recordcount100000决定threadcount100是写入并发。写入完成后核对行数# How many rows do we get? 100000 rows. mysql -uroot -htidb -P4000 -E -e SELECT COUNT(*) FROM test.usertable文档预期的返回值是100000与recordcount一致。这一步是后面恢复校验的基准值。构建 BR 并执行全量备份仍在control容器内执行# Build BR and backup! make build \ bin/br backup full --pd pd0:2379 --storage local:///data/backup/full \ --log-file /logs/br_backup.logmake build在容器内编译源码产物落在仓库的./bin目录因为 compose 把./bin挂载进了容器所以编译出的bin/br可以直接执行。备份命令各参数含义backup full全量备份--pd pd0:2379PD 地址pd0是 compose 网络内的服务名--storage local:///data/backup/full备份文件写入容器内/data/backup/full目录对应宿主机的/tmp/br/docker/data/backup/full--log-file /logs/br_backup.logBR 日志写入容器内/logs对应宿主机的/tmp/br/docker/logs/br_backup.log命令执行后可以在宿主机上查看该文件确认备份过程。删除数据库并执行恢复下面这一步是破坏性操作DROP DATABASE会永久删除test库只有在确认备份已成功上一步命令正常退出、宿主机/tmp/br/docker/data/backup/full下生成了备份文件后再执行。# Lets drop database. mysql -uroot -htidb -P4000 -E -e DROP DATABASE test; SHOW DATABASES;SHOW DATABASES的输出用于确认test已不在库列表中。然后从备份恢复# Restore! bin/br restore full --pd pd0:2379 --storage local:///data/backup/full \ --log-file /logs/br_restore.log恢复命令与备份命令的--pd、--storage保持一致日志写到br_restore.log宿主机路径同上/tmp/br/docker/logs下。恢复完成后再次核对行数# How many rows do we get again? Expected to be 100000 rows. mysql -uroot -htidb -P4000 -E -e SELECT COUNT(*) FROM test.usertable文档预期恢复后行数为100000与备份前一致说明全量备份与恢复链路走通。可选分支备份到 S3 兼容存储MinIO如果需要验证 S3 兼容存储路径本仓库 compose 里带了 MinIO 服务可以继续执行# Test S3 compatible storage (MinIO). # Create a bucket to save backup by mc (a MinIO Client). mc config host add minio $S3_ENDPOINT $MINIO_ACCESS_KEY $MINIO_SECRET_KEY \ mc mb minio/mybucket # Backup to S3 compatible storage. bin/br backup full --pd pd0:2379 --storage s3://mybucket/full \ --s3.endpoint$S3_ENDPOINT # Drop database and restore! mysql -uroot -htidb -P4000 -E -e DROP DATABASE test; SHOW DATABASES; \ bin/br restore full --pd pd0:2379 --storage s3://mybucket/full \ --s3.endpoint$S3_ENDPOINTmc config host add先注册 MinIO 端点mc mb minio/mybucket创建存放备份的桶之后备份、恢复都指向s3://mybucket/full。命令中的$S3_ENDPOINT、$MINIO_ACCESS_KEY、$MINIO_SECRET_KEY是control容器由 br/docker/minio.env 注入的环境变量S3_ENDPOINThttp://minio:24927在容器内直接引用即可无需手填。这一分支同样以恢复后SELECT COUNT(*) FROM test.usertable返回100000作为校验。边界与限制该 compose 集群是仓库内置的测试拓扑1 个 PD、5 个 TiKV、1 个 TiDB使用nightly镜像适合功能验证不代表生产部署形态。集群数据与日志都落在宿主机的/tmp/br/docker下再次执行rm -s -v或清理该目录会删除全部集群状态与备份文件。本地路径与 S3 路径两条备份链路都依赖容器内访问 PDpd0:2379不要把--pd换成宿主机地址否则容器内的 BR 无法按 compose 网络解析。集群的日常运维与更多 BR 用法如按表备份、压缩参数等可以继续在 br/README.md 和仓库其余文档中查看本文只覆盖首次全量备份与恢复这一条路径。【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址: https://gitcode.com/GitHub_Trending/ti/tidb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 TiDB 如何用 docker-compose 配合 BR 完成第一次全量备份与恢复
TiDB 如何用 docker-compose 配合 BR 完成第一次全量备份与恢复【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址: https://gitcode.com/GitHub_Trending/ti/tidb如果你想在本机快速跑通 BRBackup Restore的第一次全量备份与恢复TiDB 仓库的 br/README.md 提供了一个基于 docker-compose 的 Quick start一条命令拉起一个可写数据的 TiDB 测试集群然后在control容器里用br命令行工具完成写入数据 → 全量备份 → 删库 → 恢复 → 校验行数的完整闭环。本文按该 Quick start 的顺序拆解每一步说明每个命令的作用、参数含义和如何判断结果正确。前提是本机已安装 Docker 和 docker-compose且当前目录为仓库中的br/目录下文所有docker-compose -f docker-compose.yaml ...命令都假定在这里执行。docker-compose 集群里有什么br/docker-compose.yaml 定义了以下服务理解它们有助于后面判断命令为什么能跑通control控制容器由 br/docker/Dockerfile 构建。它以golang:1.18.9-alpine为基础预装了写数据用的go-ycsb和 S3 客户端mc并把br/源码整体复制进/go/src/github.com/pingcap/br。备份、恢复等 BR 操作都在这个容器里执行。pd0PD 服务镜像为pingcap/pd:nightly宿主端口2379。tikv0tikv45 个 TiKV 节点镜像为pingcap/tikv:nightly。tidbTiDB SQL 前端镜像为pingcap/tidb:nightly对外暴露4000SQL和10080端口。minioS3 兼容存储可选分支使用配合 br/docker/minio.env 中的环境变量。几个挂载关系需要记住后面验证备份文件位置时会用到容器内路径宿主机路径用途/data/tmp/br/docker/dataTiKV/PD 数据、备份文件/logs/tmp/br/docker/logs各服务与 BR 的日志仓库内./bin容器内/go/src/github.com/pingcap/br/binbr可执行文件注意 PD、TiKV、TiDB 都使用nightly标签镜像这是仓库文档给出的组合本文不做替换。启动集群# Start TiDB cluster docker-compose -f docker-compose.yaml rm -s -v \ docker-compose -f docker-compose.yaml build \ docker-compose -f docker-compose.yaml up --remove-orphans这条命令链有三段rm -s -v会停止并删除该 compose 项目的已有容器和命名卷属于清理性操作——它会清掉上一次运行遗留的集群状态第一次执行时如果项目未运行过这一步基本无副作用。build按 br/docker/Dockerfile 构建control:nightly镜像构建过程会联网拉取 go-ycsb 依赖。up --remove-orphans启动全部服务。启动完成后宿主机的127.0.0.1:4000可以连到 TiDB127.0.0.1:2379是 PD 端点备份、恢复等 BR 操作则在容器网络内通过服务名访问。进入 control 容器并写入测试数据# Attach to control container to run BR docker exec -it br_control_1 bash进入容器后用镜像里预装的go-ycsb写入 10 万行测试数据go-ycsb load mysql -p workloadcore \ -p mysql.hosttidb -p mysql.port4000 -p mysql.userroot \ -p recordcount100000 -p threadcount100这里mysql.hosttidb、mysql.port4000指向 compose 网络内的 TiDB 服务数据落在test.usertable表。写入行数由recordcount100000决定threadcount100是写入并发。写入完成后核对行数# How many rows do we get? 100000 rows. mysql -uroot -htidb -P4000 -E -e SELECT COUNT(*) FROM test.usertable文档预期的返回值是100000与recordcount一致。这一步是后面恢复校验的基准值。构建 BR 并执行全量备份仍在control容器内执行# Build BR and backup! make build \ bin/br backup full --pd pd0:2379 --storage local:///data/backup/full \ --log-file /logs/br_backup.logmake build在容器内编译源码产物落在仓库的./bin目录因为 compose 把./bin挂载进了容器所以编译出的bin/br可以直接执行。备份命令各参数含义backup full全量备份--pd pd0:2379PD 地址pd0是 compose 网络内的服务名--storage local:///data/backup/full备份文件写入容器内/data/backup/full目录对应宿主机的/tmp/br/docker/data/backup/full--log-file /logs/br_backup.logBR 日志写入容器内/logs对应宿主机的/tmp/br/docker/logs/br_backup.log命令执行后可以在宿主机上查看该文件确认备份过程。删除数据库并执行恢复下面这一步是破坏性操作DROP DATABASE会永久删除test库只有在确认备份已成功上一步命令正常退出、宿主机/tmp/br/docker/data/backup/full下生成了备份文件后再执行。# Lets drop database. mysql -uroot -htidb -P4000 -E -e DROP DATABASE test; SHOW DATABASES;SHOW DATABASES的输出用于确认test已不在库列表中。然后从备份恢复# Restore! bin/br restore full --pd pd0:2379 --storage local:///data/backup/full \ --log-file /logs/br_restore.log恢复命令与备份命令的--pd、--storage保持一致日志写到br_restore.log宿主机路径同上/tmp/br/docker/logs下。恢复完成后再次核对行数# How many rows do we get again? Expected to be 100000 rows. mysql -uroot -htidb -P4000 -E -e SELECT COUNT(*) FROM test.usertable文档预期恢复后行数为100000与备份前一致说明全量备份与恢复链路走通。可选分支备份到 S3 兼容存储MinIO如果需要验证 S3 兼容存储路径本仓库 compose 里带了 MinIO 服务可以继续执行# Test S3 compatible storage (MinIO). # Create a bucket to save backup by mc (a MinIO Client). mc config host add minio $S3_ENDPOINT $MINIO_ACCESS_KEY $MINIO_SECRET_KEY \ mc mb minio/mybucket # Backup to S3 compatible storage. bin/br backup full --pd pd0:2379 --storage s3://mybucket/full \ --s3.endpoint$S3_ENDPOINT # Drop database and restore! mysql -uroot -htidb -P4000 -E -e DROP DATABASE test; SHOW DATABASES; \ bin/br restore full --pd pd0:2379 --storage s3://mybucket/full \ --s3.endpoint$S3_ENDPOINTmc config host add先注册 MinIO 端点mc mb minio/mybucket创建存放备份的桶之后备份、恢复都指向s3://mybucket/full。命令中的$S3_ENDPOINT、$MINIO_ACCESS_KEY、$MINIO_SECRET_KEY是control容器由 br/docker/minio.env 注入的环境变量S3_ENDPOINThttp://minio:24927在容器内直接引用即可无需手填。这一分支同样以恢复后SELECT COUNT(*) FROM test.usertable返回100000作为校验。边界与限制该 compose 集群是仓库内置的测试拓扑1 个 PD、5 个 TiKV、1 个 TiDB使用nightly镜像适合功能验证不代表生产部署形态。集群数据与日志都落在宿主机的/tmp/br/docker下再次执行rm -s -v或清理该目录会删除全部集群状态与备份文件。本地路径与 S3 路径两条备份链路都依赖容器内访问 PDpd0:2379不要把--pd换成宿主机地址否则容器内的 BR 无法按 compose 网络解析。集群的日常运维与更多 BR 用法如按表备份、压缩参数等可以继续在 br/README.md 和仓库其余文档中查看本文只覆盖首次全量备份与恢复这一条路径。【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址: https://gitcode.com/GitHub_Trending/ti/tidb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考