ProxySQL 嵌入式 TSDB 快速上手:启用、验证与 SQL 查询实战指南

发布时间:2026/10/8 1:23:23
ProxySQL 嵌入式 TSDB 快速上手:启用、验证与 SQL 查询实战指南 后端数据库负载均衡【免费下载链接】proxysqlHigh-performance proxy for MySQL and PostgreSQL项目地址https://gitcode.com/gh_mirrors/pr/proxysql点击查看免费下载ProxySQL 内置了一套基于 SQLite 的轻量级时序数据库TSDB子系统用于把内建 Prometheus 注册表中的指标与后端服务器 TCP 探针健康数据周期性地落盘存储。本指南将带你从零开始如何通过tsdb-前缀全局变量启用该功能、如何用管理 SQL 验证状态与表结构以及如何查询原始样本、小时级聚合与后端探针健康数据并深入剖析背后的采样、降采样与保留清理机制让你能直接在自己的 ProxySQL 实例上复现并投入使用。1. 什么是 ProxySQL 嵌入式 TSDBTSDBTime-Series Database是集成在 ProxySQL 内部的时间序列存储子系统实现位于ProxySQL_Statistics见 lib/ProxySQL_Statistics.cpp。它的职责有两部分指标记录周期性从内建 Prometheus 注册表GloVars.prometheus_registry采集全部 metric family归一化后写入 SQLite 表stats_history.tsdb_metrics后端健康探针可选地以 TCP 连接方式对mysql_servers/pgsql_servers中的后端服务器做存活探测结果写入stats_history.tsdb_backend_health。所有数据存储在statsdb_disk对应的stats_history库中可通过标准 SQL 直接查询无需额外部署时序数据库组件。系统级设计细节可参考 doc/tsdb/embedded_tsdb_architecture.md 与 doc/tsdb/embedded_tsdb_overview.md。2. 启用 TSDB三步配置命令TSDB 配置项全部是带tsdb-前缀的全局变量沿用 ProxySQL 经典的内存变量 → 运行时 → 磁盘三段式生命周期管理。启用主开关SET tsdb-enabled1; LOAD TSDB VARIABLES TO RUNTIME; SAVE TSDB VARIABLES TO DISK;如果你还需要采集后端服务器的连通性健康数据再开启探针开关SET tsdb-monitor_enabled1; LOAD TSDB VARIABLES TO RUNTIME; SAVE TSDB VARIABLES TO DISK;命令语义说明LOAD TSDB VARIABLES TO RUNTIME把当前内存中的 TSDB 变量应用到运行时等价于LOAD TSDB VARIABLES TO RUN也支持FROM MEM等别名SAVE TSDB VARIABLES TO DISK把运行时/内存值持久化到磁盘等价于SAVE TSDB VARIABLES FROM RUN另有LOAD TSDB VARIABLES FROM CONFIG用于从配置文件回载SHOW TSDB VARIABLES用于查看当前值。这些命令的解析逻辑可以在 lib/Admin_Handler.cpp 中找到其处理流程与MYSQL/PGSQL变量命令保持一致见 doc/tsdb/embedded_tsdb_architecture.md 的 Configuration Lifecycle 一节。2.1 配置变量速查表变量类型默认值取值范围说明tsdb-enabledint00/1主开关关闭时采样/降采样/探针/清理全部跳过tsdb-sample_intervalint51..3600Prometheus 指标采样间隔秒tsdb-retention_daysint71..3650原始指标与探针数据的保留天数tsdb-monitor_enabledint00/1后端探针开关tsdb-monitor_intervalint101..3600探针执行间隔秒上述默认值retention_days7、monitor_enabled0、monitor_interval10与取值范围在 lib/ProxySQL_Statistics.cpp 的初始化与变量解析代码中得到印证。完整变量说明参见 doc/tsdb/embedded_tsdb_reference.md。说明LOAD TSDB VARIABLES TO RUNTIME与SAVE TSDB VARIABLES TO DISK均需要组合使用才能让变更同时生效并持久化单独执行SET只修改内存中的管理变量。3. 验证运行状态SHOW TSDB STATUS启用后可以用管理命令检查子系统运行状态SHOW TSDB STATUS;该命令在 lib/Admin_Handler.cpp 中被解析最终由ProxySQL_Statistics::get_tsdb_status()见 lib/ProxySQL_Statistics.cpp计算返回内部通过SELECT COUNT(DISTINCT metric_name || labels)统计序列数、SELECT COUNT(*)统计数据点总数并汇总磁盘占用与最旧/最新数据点时间。同时可用SHOW TSDB VARIABLES核对当前变量值是否与预期一致。4. 验证表结构查询 sqlite_masterTSDB 创建的表都位于stats_history库中且以tsdb_前缀命名。查看当前已存在的 TSDB 表SELECT name FROM stats_history.sqlite_master WHERE typetable AND name LIKE tsdb_%;正常情况下应能看到三张核心表tsdb_metrics原始采样数据tsdb_metrics_hour小时级聚合rollup数据tsdb_backend_health后端探针健康数据。三张表的完整 DDL 定义如下见 doc/tsdb/embedded_tsdb_specs.md 与 doc/tsdb/embedded_tsdb_reference.mdCREATE TABLE tsdb_metrics ( timestamp INT NOT NULL, -- Unix 秒级时间戳 metric_name TEXT NOT NULL, -- 指标名与 Prometheus 暴露名一致 labels TEXT NOT NULL DEFAULT {}, -- 标签JSON 文本 value REAL, -- 采样值 PRIMARY KEY (timestamp, metric_name, labels) ) WITHOUT ROWID; CREATE TABLE tsdb_metrics_hour ( bucket INT NOT NULL, -- 小时桶起点timestamp/3600*3600 metric_name TEXT NOT NULL, labels TEXT NOT NULL DEFAULT {}, avg_value REAL, max_value REAL, min_value REAL, count INT, PRIMARY KEY (bucket, metric_name, labels) ) WITHOUT ROWID; CREATE TABLE tsdb_backend_health ( timestamp INT NOT NULL, hostgroup INT NOT NULL, -- 主机组 ID hostname TEXT NOT NULL, -- 后端主机名 port INT NOT NULL, -- 后端端口 probe_up INT NOT NULL, -- 探测是否成功1/0 connect_ms INT, -- 连接耗时毫秒 PRIMARY KEY (timestamp, hostgroup, hostname, port) ) WITHOUT ROWID;三张表都使用WITHOUT ROWID与复合主键设计避免重复写入同一时间点的同一条序列。5. 查询原始采样数据tsdb_metricstsdb_metrics保存的是按tsdb-sample_interval默认 5 秒周期采集的原始样本。查询最近 5 分钟的样本SELECT datetime(timestamp,unixepoch) AS ts, metric_name, labels, value FROM stats_history.tsdb_metrics WHERE timestamp unixepoch() - 300 ORDER BY timestamp DESC LIMIT 50;字段含义ts把 Unix 时间戳格式化为可读时间metric_name指标名例如process_resident_memory_bytes、mysql_questions_total等labels该样本携带的 Prometheus 标签JSON 文本如{hostgroup:1}无标签时为{}value数值采样值。其写入路径对应源码中的tsdb_sampler_loop()见 lib/ProxySQL_Statistics.cpp采样触发时先调用update_modules_metrics()刷新模块指标再执行GloVars.prometheus_registry-Collect()拉取全部 metric family在单个事务BEGIN/COMMIT中逐条写入保证一批样本的原子性。5.1 指标家族Metric Family存储约定由于指标直接来自 Prometheus 注册表且注册表会随版本演化TSDB 代码中不维护固定指标清单而是按类型统一处理详见 doc/tsdb/embedded_tsdb_metrics_catalog.mdPrometheus 类型落库约定Counter / Gauge / Untyped / Info直接以暴露的指标名存储一个数据点一行Summaryname存储各分位数标签quantile并额外生成name_sum、name_count两个伴随序列Histogramname_bucket存储各桶累计计数标签le并额外生成name_sum、name_count这条映射逻辑在 lib/ProxySQL_Statistics.cpp 的switch (family.type)分支中有完整实现与 doc/tsdb/embedded_tsdb_reference.md 中的 Ingestion Mapping 表一致。6. 查询小时级聚合tsdb_metrics_hourtsdb_metrics_hour是按小时桶聚合的降采样数据用于长周期趋势分析避免直接扫描海量原始数据。查询最近 24 小时的聚合结果SELECT datetime(bucket,unixepoch) AS hour, metric_name, avg_value, max_value, min_value, count FROM stats_history.tsdb_metrics_hour WHERE bucket unixepoch() - 86400 ORDER BY bucket;字段含义hour为小时桶起点avg_value/max_value/min_value为该小时内样本的平均值、最大值、最小值count为该小时内的样本条数。底层降采样由tsdb_downsample_metrics()见 lib/ProxySQL_Statistics.cpp驱动核心 SQL 为INSERT OR REPLACE INTO tsdb_metrics_hour SELECT (timestamp/3600)*3600 AS bucket, metric_name, labels, AVG(value) AS avg_value, MAX(value) AS max_value, MIN(value) AS min_value, COUNT(*) AS count FROM tsdb_metrics WHERE timestamp last_hour AND timestamp current_hour GROUP BY bucket, metric_name, labels;实现细节值得注意通过SELECT MAX(bucket) FROM tsdb_metrics_hour找出已处理的最新小时桶再对边界桶重新聚合保证在小时边界前后到达的指标也能被正确纳入INSERT OR REPLACE使重算具有幂等性该任务每小时执行一次tsdb_downsample_timetoget使用3600ULL * 1000000ULL微秒间隔见 lib/ProxySQL_Statistics.cpp。7. 查询后端探针健康tsdb_backend_health若开启了tsdb-monitor_enabledTSDB 会按tsdb-monitor_interval默认 10 秒对runtime_mysql_servers中的后端做 TCP 连通性探测结果写入tsdb_backend_health。查询最近 1 小时的探针结果SELECT datetime(timestamp,unixepoch) AS ts, hostgroup, hostname, port, probe_up, connect_ms FROM stats_history.tsdb_backend_health WHERE timestamp unixepoch() - 3600 ORDER BY timestamp DESC;字段含义probe_up为 1 表示探测成功、0 表示失败connect_ms为本次 TCP 连接耗时毫秒。其实现位于tsdb_monitor_loop()见 lib/ProxySQL_Statistics.cpp执行流程如下通过MyHGM-dump_table_mysql(mysql_servers)与PgHGM-dump_table_pgsql(pgsql_servers)拉取当前 MySQL/PgSQL 后端目标与运行时表构建走同一 hostgroup-manager 路径因此也覆盖了 PostgreSQL 后端以每批最多 16 个目标max_concurrent的方式用std::async并发执行probe_backend()探测探测函数采用非阻塞connect()poll()1 秒超时见 lib/ProxySQL_Statistics.cpp并精确测量connect_ms网络完成阶段不持有 TSDB 互斥锁全部结果收集完毕后才统一加锁并批量BEGIN/COMMIT写入避免不可达后端拖慢采样、状态查询与清理任务。8. 数据保留策略RetentionTSDB 按以下规则自动清理过期数据见 lib/ProxySQL_Statistics.cpp 的tsdb_retention_cleanup()该任务同样每小时执行一次原始指标tsdb_metrics保留tsdb-retention_days天默认 7 天最小强制 1 天后端探针tsdb_backend_health保留tsdb-retention_days天小时聚合tsdb_metrics_hour固定保留 365 天。对应的删除语句形如DELETE FROM tsdb_metrics WHERE timestamp now - 86400*retention_days。因此查询原始数据的时间窗口不应超过tsdb-retention_days超过后请改用小时聚合表。9. 内置 Web 仪表盘与 REST API除了 SQL 查询TSDB 还提供 Web 与 REST 两种访问方式详见 doc/tsdb/ui_endpoints.mdWeb 仪表盘http://proxysql_host:6080/tsdb基于 Chart.js 交互图表支持选择指标与时间范围Last Hour / Last Day / Last WeekREST API返回 JSON便于外部系统集成端点说明GET /api/tsdb/metrics返回所有可用指标名列表GET /api/tsdb/query查询某个指标的时间序列参数metric必填、from/toUnix 秒默认最近 1 小时、agg聚合函数如avg、max取决于后端实现、其余参数作为标签过滤如clustercluster1GET /api/tsdb/status返回子系统状态total_series、total_datapoints、disk_size_bytes、oldest_datapoint、newest_datapoint10. 使用建议与注意事项所有 TSDB 设置均为tsdb-前缀全局变量只能通过SETLOAD TSDB VARIABLES TO RUNTIME生效务必配合SAVE TSDB VARIABLES TO DISK持久化否则重启后配置丢失原始表与探针表受tsdb-retention_days约束长周期历史分析请使用tsdb_metrics_hour保留 365 天采样与探针都要求tsdb-enabled1探针还额外要求tsdb-monitor_enabled1探针会额外产生网络连接若后端规模较大或网络不可靠请合理设置tsdb-monitor_interval以控制探测频率若当前仓库版本中ProxySQL_Statistics.cpp的 TSDB 代码被宏开关包裹文件末尾#endif确认构建时启用了对应特性否则相关变量与命令不会生效。至此你已经掌握了 ProxySQL 嵌入式 TSDB 从启用、验证到查询的完整闭环并能结合 lib/ProxySQL_Statistics.cpp 理解其采样、降采样、探针与清理的底层机制。更多细节可继续阅读 doc/tsdb/embedded_tsdb_reference.md变量与表定义、doc/tsdb/embedded_tsdb_metrics_catalog.md指标覆盖与 doc/tsdb/embedded_tsdb_specs.md技术规格。赞分享后端数据库负载均衡【免费下载链接】proxysqlHigh-performance proxy for MySQL and PostgreSQL项目地址https://gitcode.com/gh_mirrors/pr/proxysql点击查看免费下载相关推荐ProxySQL 内嵌 TSDB 参考手册配置变量、存储表结构与 Prometheus 指标查询实战ProxySQL 内嵌 TSDB 参考手册配置变量、存储表结构与 Prometheus 指标查询实战 ProxySQL高性能 MySQL/PostgreSQ后端数据库负载均衡Zcash 内嵌 LevelDB 存储引擎实现剖析文件组织、分层合并与崩溃恢复机制Zcash 内嵌 LevelDB 存储引擎实现剖析文件组织、分层合并与崩溃恢复机制 导读 本文以 Zcash 仓库内嵌的 LevelDB 源码文档 src/后端数据库负载均衡TDengine TSDB 快速上手从环境安装到建模、写入、查询与流式计算的完整体验指南TDengine TSDB 快速上手从环境安装到建模、写入、查询与流式计算的完整体验指南 TDengine 是为工业物联网IIoT场景设计的高性能时序数据数据库时序数据库大数据物联网云原生上一篇Apollo自动驾驶平台软件包管理教程从基础概念到自定义开发下一篇Pydantic数据验证库全面解析Python类型提示驱动的数据验证利器创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询