3
4
0
0
博客/.../

使用 OpenClaw 管控 TiDB (一):部署+测试 TiDB 集群

 代晓磊_Mars  发表于  2026-03-03

给大家看一个我使用 OpenClaw 管控 TiDB 的实操过程,主要是让大家看到当前AI数据库管控能力的强大,这个只是通过自然语言的交互让 OpenClaw 帮忙部署和测试了一套最小规模的 TiDB 集群,验证了 TiDB 数据库作为一个开发人员的开发环境数据库来使用时性能完全足够,关于如何安装 OpenClaw 可以参考我的微信公众号:晓磊聊DB,里面有一篇《从零搭建智能办公助手:OpenClaw + DeepSeek + Slack 完整指南》需要强调的是:OpenClaw操作数据库有风险,本次的所有操作都是自己云服务器环境,非线上和测试环境(我给的权限比较高,禁止在公司线上和测试环境使用OpenClaw管控TiDB集群,删库跑路你懂的,😂)。

打开openclaw tui命令行工具

(一)命令行输入:帮我安装一个tidb的部署工具tiup,并且使用tiup playground拉起一个最小规模的tidb集群。

🎯 任务完成总结

✅ 已完成的部分:

  1. TiUP 安装成功 - 版本 1.16.4,已添加到 PATH
  2. PD 组件下载完成 - 版本 v8.5.5
  3. TiDB 集群启动进程已开始 - 正在后台运行

🔄 进行中的部分:

  • TiKV 组件下载中 - 375MB,当前进度约 14%,预计还需 4-5 分钟
  • 下载完成后会自动启动 TiDB 和 TiKV 组件

📊 集群配置:

  • TiDB 节点: 1个
  • TiKV 节点: 1个
  • PD 节点: 1个
  • TiFlash 节点: 0个(禁用)
  • 监控: 已禁用(--without-monitor)
  • 版本: v8.5.5(最新稳定版)

🔧 如何使用 TiDB 集群

当集群启动完成后(您会看到类似下面的输出):

  CLUSTER START SUCCESSFULLY, Enjoy it ^-^
  To connect TiDB: mysql --comments --host 127.0.0.1 --port 4000 -u root

常用命令:

  1. 连接到 TiDB:
  mysql -h 127.0.0.1 -P 4000 -u root
  1. 检查集群状态:
  export PATH=$PATH:/root/.tiup/bin
  tiup playground display
  1. 停止集群:
  # 在 playground 终端中按 Ctrl+C
  # 或使用 tiup 命令
  tiup playground scale-in --all
  1. 查看运行中的实例:
  tiup status

⏳ 当前状态监控

集群启动进程正在后台运行(session ID: faint-shoal)。您可以通过以下方式监控进度:

  # 查看进程日志
  process poll --sessionId faint-shoal

  # 查看进程列表
  process list

🚀 下一步操作建议

  1. 等待下载完成 - TiKV 组件下载完成后,集群会自动启动
  2. 验证连接 - 使用 mysql -h 127.0.0.1 -P 4000 -u root 测试连接
  3. 测试功能 - 创建数据库、表,插入数据测试 TiDB 功能

注意:TiUP playground 启动的集群是临时的,适合开发和测试。生产环境请使用 tiup cluster 命令部署。

需要我继续监控集群启动状态,还是您想了解其他 TiDB/TiUP 相关功能?

(二)命令行输入:帮我查看下tidb集群的启动状态

很好!TiDB Dashboard 重定向正常。现在让我为您总结 TiDB 集群的启动状态:

📊 TiDB 集群启动状态报告

✅ 集群启动完成!

启动时间: 2026-03-03 14:01 (GMT+8) 集群ID: VCmTkw4 版本: TiDB v8.5.5

🔧 集群组件状态

┌──────┬───────────┬─────────┬─────────────┬───────────────────────┐ │ 组件 │ 状态 │ PID │ 监听端口 │ 健康状态 │ ├──────┼───────────┼─────────┼─────────────┼───────────────────────┤ │ PD │ ✅ 运行中 │ 3690941 │ 2379/2380 │ 健康 (Leader: pd-0) │ ├──────┼───────────┼─────────┼─────────────┼───────────────────────┤ │ TiKV │ ✅ 运行中 │ 3693868 │ 20160/20180 │ 健康 (Metrics 可访问) │ ├──────┼───────────┼─────────┼─────────────┼───────────────────────┤ │ TiDB │ ✅ 运行中 │ 3694556 │ 4000/10080 │ 健康 (可连接) │ └──────┴───────────┴─────────┴─────────────┴───────────────────────┘

🌐 访问信息

  1. TiDB 数据库连接:
  mysql -h 127.0.0.1 -P 4000 -u root
  1. TiDB Dashboard (Web UI):
  http://127.0.0.1:2379/dashboard
  1. PD API:
  http://127.0.0.1:2379/pd/api/v1/...

📈 集群配置

  • 拓扑: 1 TiDB + 1 TiKV + 1 PD (最小规模)
  • 存储引擎: TiKV
  • 监控: 已禁用 (--without-monitor)
  • 数据目录: /root/.tiup/data/VCmTkw4/

🔍 健康检查结果

  1. PD 集群状态: ✅ 正常 (1个成员,已选举 Leader)
  2. TiKV 存储状态: ✅ 正常 (Metrics 端点可访问)
  3. TiDB SQL 层: ✅ 正常 (可连接并执行查询)
  4. 组件版本一致性: ✅ 一致 (全部为 v8.5.5)

💡 快速测试

已成功执行以下测试:

  • ✅ 连接 TiDB: SELECT VERSION() → 8.0.11-TiDB-v8.5.5
  • ✅ 查看数据库: SHOW DATABASES → 显示默认数据库
  • ✅ PD API 访问: 集群信息可获取
  • ✅ TiKV Metrics: 监控数据可访问

⚡ 下一步操作建议

  1. 测试数据库操作:
  CREATE DATABASE test_db;
  USE test_db;
  CREATE TABLE test_table (id INT PRIMARY KEY, name VARCHAR(50));
  INSERT INTO test_table VALUES (1, 'test');
  SELECT * FROM test_table;
  1. 查看集群信息:
  SELECT * FROM information_schema.cluster_info;
  SELECT * FROM information_schema.cluster_confi g;
  1. 性能测试 (可选):
  # 使用 sysbench 进行基准测试
  tiup bench tpcc --host 127.0.0.1 --port 4000 --user root --warehouses 1 prepare
  tiup bench tpcc --host 127.0.0.1 --port 4000 --user root --warehouses 1 run

🛑 停止集群

当您完成测试后,可以通过以下方式停止集群:

  1. 在 playground 终端按 Ctrl+C
  2. 或使用命令: tiup playground scale-in --all

集群现在已完全启动并运行正常! 🎉 您可以开始使用 TiDB 进行开发和测试了。

(三)命令行输入:好的,你帮我修改下tidb集群的root数据库用户的密码为ah........lhth,然后创建一个新的dbadmin的数据库用户,并且配置同样的密码,这个dbadmin的用户权限是all。

✅ TiDB 用户配置完成

📋 执行结果总结

  1. root 用户密码修改:
  • ✅ 成功修改 root@% 用户密码
  • 新密码: ah.....h
  • 验证: 使用新密码连接成功
  1. dbadmin 用户创建:
  • ✅ 成功创建 dbadmin@% 用户
  • 密码: ahl....... h (与 root 相同)
  • 权限: ALL PRIVILEGES ON . WITH GRANT OPTION
  1. 权限验证:
  • ✅ dbadmin 用户可连接数据库
  • ✅ dbadmin 用户拥有完整权限(创建/删除数据库、表等)
  • ✅ root 用户新密码正常工作

🔐 用户账户信息

┌─────────┬──────┬───────────────────────────────────┬─────────────────────────────┐ │ 用户名 │ 主机 │ 密码 │ 权限 │ ├─────────┼──────┼───────────────────────────────────┼─────────────────────────────┤ │ root │ % │ ahl。。。。。 h │ 默认 root 权限 │ ├─────────┼──────┼───────────────────────────────────┼─────────────────────────────┤ │ dbadmin │ % │ ahl。。。。 h │ GRANT ALL PRIVILEGES ON . │ └─────────┴──────┴───────────────────────────────────┴─────────────────────────────┘

🔧 连接示例

使用 root 用户连接:

  mysql -h 127.0.0.1 -P 4000 -u root -pahl.....th

使用 dbadmin 用户连接:

  mysql -h 127.0.0.1 -P 4000 -u dbadmin -pahl....th

📝 已执行的 SQL 命令

  -- 修改 root 用户密码
  ALTER USER 'root'@'%' IDENTIFIED BY 'ahl..... h';

  -- 创建 dbadmin 用户
  CREATE USER 'dbadmin'@'%' IDENTIFIED BY 'ahl.....h';

  -- 授予 dbadmin 所有权限
  GRANT ALL PRIVILEGES ON *.* TO 'dbadmin'@'%' WITH GRANT OPTION;

  -- 刷新权限
  FLUSH PRIVILEGES;

✅ 验证测试

  1. 密码验证: ✅ 两个用户均可使用新密码连接
  2. 权限验证: ✅ dbadmin 用户拥有完整数据库操作权限
  3. 功能验证: ✅ 两个用户均可创建/删除数据库和表

⚠️ 安全建议

  1. 密码安全: 当前密码较为复杂,建议定期更换
  2. 访问控制: 考虑将 % 通配符替换为具体的 IP 地址范围
  3. 权限管理: dbadmin 拥有完整权限,建议根据实际需要细化权限
  4. 连接安全: 生产环境建议启用 SSL/TLS 加密连接

所有用户配置任务已完成,TiDB 集群现在有两个具有相同密码的管理员账户:root 和 dbadmin,其中 dbadmin 拥有完整的数据库权限。

(四)命令行输入:帮我对这个tidb集群进行简单的压力测试,并且给出压力测试报告,请使用dbadmin账号来进行测试。

现在让我生成压力测试报告:

📊 TiDB 集群压力测试报告

🔧 测试环境配置

┌───────────┬─────────────────────────────────────┐ │ 项目 │ 配置 │ ├───────────┼─────────────────────────────────────┤ │ TiDB 版本 │ v8.5.5 │ ├───────────┼─────────────────────────────────────┤ │ 集群规模 │ 1 TiDB + 1 TiKV + 1 PD │ ├───────────┼─────────────────────────────────────┤ │ 测试用户 │ dbadmin │ ├───────────┼─────────────────────────────────────┤ │ 测试工具 │ sysbench 1.0.20 │ ├───────────┼─────────────────────────────────────┤ │ 测试时长 │ 每个测试 60 秒 │ ├───────────┼─────────────────────────────────────┤ │ 并发线程 │ 8 线程 │ ├───────────┼─────────────────────────────────────┤ │ 数据规模 │ 10 个表 × 10,000 行/表 = 100,000 行 │ ├───────────┼─────────────────────────────────────┤ │ 测试时间 │ 2026-03-03 14:11-14:20 (GMT+8) │ └───────────┴─────────────────────────────────────┘

📈 性能测试结果

1. OLTP 只读测试 (oltp_read_only)

┌──────────┬────────────┬────────────────────┐ │ 指标 │ 结果 │ 说明 │ ├──────────┼────────────┼────────────────────┤ │ TPS │ 183.11/s │ 每秒事务数 │ ├──────────┼────────────┼────────────────────┤ │ QPS │ 2,929.83/s │ 每秒查询数 │ ├──────────┼────────────┼────────────────────┤ │ 读取 QPS │ 2,564.38/s │ 每秒读取查询数 │ ├──────────┼────────────┼────────────────────┤ │ 95% 延迟 │ 59.99ms │ 95% 请求的响应时间 │ ├──────────┼────────────┼────────────────────┤ │ 平均延迟 │ 43.67ms │ 平均响应时间 │ ├──────────┼────────────┼────────────────────┤ │ 最大延迟 │ 1,937.21ms │ 最大响应时间 │ ├──────────┼────────────┼────────────────────┤ │ 错误率 │ 0.00% │ 无错误 │ └──────────┴────────────┴────────────────────┘

2. OLTP 只写测试 (oltp_write_only)

┌──────────┬────────────┬────────────────────┐ │ 指标 │ 结果 │ 说明 │ ├──────────┼────────────┼────────────────────┤ │ TPS │ 292.16/s │ 每秒事务数 │ ├──────────┼────────────┼────────────────────┤ │ QPS │ 1,752.96/s │ 每秒查询数 │ ├──────────┼────────────┼────────────────────┤ │ 写入 QPS │ 1,169.25/s │ 每秒写入查询数 │ ├──────────┼────────────┼────────────────────┤ │ 95% 延迟 │ 42.61ms │ 95% 请求的响应时间 │ ├──────────┼────────────┼────────────────────┤ │ 平均延迟 │ 27.37ms │ 平均响应时间 │ ├──────────┼────────────┼────────────────────┤ │ 最大延迟 │ 148.36ms │ 最大响应时间 │ ├──────────┼────────────┼────────────────────┤ │ 错误率 │ 0.00% │ 无错误 │ └──────────┴────────────┴────────────────────┘

3. OLTP 混合读写测试 (oltp_read_write)

┌──────────┬────────────┬──────────────────────┐ │ 指标 │ 结果 │ 说明 │ ├──────────┼────────────┼──────────────────────┤ │ TPS │ 99.72/s │ 每秒事务数 │ ├──────────┼────────────┼──────────────────────┤ │ QPS │ 1,994.63/s │ 每秒查询数 │ ├──────────┼────────────┼──────────────────────┤ │ 读取 QPS │ 1,396.20/s │ 每秒读取查询数 │ ├──────────┼────────────┼──────────────────────┤ │ 写入 QPS │ 399.82/s │ 每秒写入查询数 │ ├──────────┼────────────┼──────────────────────┤ │ 95% 延迟 │ 108.68ms │ 95% 请求的响应时间 │ ├──────────┼────────────┼──────────────────────┤ │ 平均延迟 │ 80.14ms │ 平均响应时间 │ ├──────────┼────────────┼──────────────────────┤ │ 最大延迟 │ 228.67ms │ 最大响应时间 │ ├──────────┼────────────┼──────────────────────┤ │ 错误率 │ 0.02% │ 极低错误率 (1个错误) │ └──────────┴────────────┴──────────────────────┘

📊 性能对比分析

| 测试类型 | TPS | QPS | 95% 延迟 | 特点 | |----------|-----|-----|-------- --|------| | 只读 | 183.11/s | 2,929.83/s | 59.99ms | 读取性能优秀,QPS 最高 | | 只写 | 292.16/s | 1,752.96/s | 42.61ms | 写入性能最佳,延迟最低 | | 混合 | 99.72/s | 1,994.63/s | 108.68ms | 综合性能平衡,延迟较高 |

💾 资源使用情况

内存使用 (测试后)

  • 总内存: 7.7 GB
  • 已使用: 6.7 GB (86.8%)
  • TiKV 内存: ~2.0 GB (25.3% of total)
  • TiDB 内存: ~0.75 GB (9.7% of total)
  • PD 内存: ~0.1 GB (1.3% of total)

CPU 使用 (测试后)

  • TiKV CPU: 15.7%
  • TiDB CPU: 19.4%
  • PD CPU: 2.3%

集群状态

  • 运行时间: 23 分钟 54 秒
  • 所有组件: 运行正常
  • 连接: 无重连,稳定性良好

📋 测试结论

✅ 优势

  1. 写入性能优秀: 只写测试 TPS 达到 292.16/s,延迟仅 42.61ms
  2. 读取性能良好: 只读测试 QPS 达到 2,929.83/s
  3. 稳定性高: 测试期间无连接中断,错误率极低
  4. 资源利用合理: 内存和 CPU 使用在正常范围内
  5. 响应时间可控: 95% 请求延迟在可接受范围内

⚠️ 注意事项

  1. 混合负载延迟较高: 混合读写测试延迟达到 108.68ms,建议优化
  2. 内存使用较高: TiKV 使用了 2GB 内存,对于小规模测试偏高
  3. 无交换空间: 系统未配置交换空间,可能影响极端情况下的稳定性

🔧 优化建议

  1. TiKV 配置优化:
    • 调整 block-cache-size 减少内存使用
    • 优化 raftstore 相关参数提高写入性能
  2. TiDB 配置优化:
    • 调整 tidb_mem_quota_query 控制查询内存
    • 优化 tidb_executor_concurrency 提高并发处理能力
  3. 测试环境优化:
    • 增加测试数据量 (100万行以上) 获得更准确结果
    • 延长测试时间 (300秒以上) 观察稳定性
    • 增加并发线程数 (16-32线程) 测试极限性能

🎯 总体评价

评分: 8.5/10

这个最小规模的 TiDB 集群在压力测试中表现良好,特别是在写入性能方面表现出色。对于开发 和测试环境来说,性能完全足够。主要瓶颈出现在混合读写场景,这是分 布式数据库的常见挑战。

适用场景:

  • ✅ 开发测试环境
  • ✅ 中小型应用原型
  • ✅ 学习和技术验证
  • ⚠️ 生产环境需要更大规模集群和优化配置

测试完成,所有测试数据已清理,集群状态正常。

3
4
0
0

版权声明:本文为 TiDB 社区用户原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接和本声明。

评论
暂无评论