后端数据库负载均衡【免费下载链接】proxysqlHigh-performance proxy for MySQL and PostgreSQL项目地址https://gitcode.com/gh_mirrors/pr/proxysql点击查看免费下载本文围绕 GTID、Aurora 与 Admin 覆盖设计文档 展开系统讲解 ProxySQL 如何通过 TAP 测试提升MyHGC.cpp与ProxySQL_Admin_Tests2.cpp的有效 GCOV 覆盖率。你将理解三大覆盖策略的取舍——复用既有 GTID 因果负载、用TEST_AURORA模拟器驱动 Aurora 延迟路由、用PROXYSQLTEST内建命令验证 Admin 行为——并掌握对应的测试注册、聚焦运行与 LCOV 验证方法。一、目标让覆盖率命中真实可观测路径设计文档的核心目标非常明确通过对可观测生产路径执行 TAP 测试提升MyHGC.cpp与ProxySQL_Admin_Tests2.cpp中有意义的 GCOV 覆盖率。这句话包含两层含义有意义meaningful覆盖率不追求数字堆砌而是要求 GCOV 记录到的分支确实由真实业务路径触发。若一个 TAP 虽然跑了但从未被纳入上传 GCOV 数据的 CI 组那么它的执行对覆盖率报告毫无贡献——这正是 GTID 测试当时面临的状况。可观测生产路径observable production paths覆盖应当发生在真实的前端连接、真实的查询路由、真实的 Admin SQL 接口之上而不是通过单元测试直接调用内部函数绕过接口。实现计划2026-08-15-gtid-aurora-admin-coverage.md进一步明确了三条全局约束它们是整个设计的事实基线对 ProxySQL 的所有请求一律使用普通 libmysql 客户端流量不手工构造客户端协议包TEST_AURORA仅用于提供 Aurora 监控状态端点选择与状态影响必须由前端查询断言Admin 状态的恢复一律通过LOAD ... FROM DISK与LOAD ... TO RUNTIME完成。二、三大覆盖领域与决策概览设计文档将工作拆分为三个互不重叠的领域每个领域对应一个已经落地于 test/tap/groups/groups.json 的 TAP 测试覆盖领域测试文件注册的 GCOV 组覆盖目标GTID 因果路由test_gtid_from_ok-t.cpp14 项断言mysql84-g5追加MyHGC.cpp中gtid_trxid候选分支Aurora 查询路由test_aurora_query_routing-t.cpp9 项断言cluster_sim_aurora-g1MyHGC.cpp中 lag 过滤与 writer 移除路径内置 Admin 测试test_admin_builtin_coverage-t.cpp23 项断言mysql84-g5ProxySQL_Admin_Tests2.cpp中PROXYSQLTEST2/3/6/12/13/16三者的共同点是不修改任何生产代码计划中明确 No production code changes仅通过测试注册、模拟器状态注入与 TAP 行为断言来扩大 GCOV 的执行覆盖。实现计划中的执行证据2026-08-15显示GTID 测试在 MySQL 8.4 聚焦运行通过并记录到目标分支Aurora 测试 9 项断言全过Admin 测试 23 项断言全过且 GCOV 记录了目标case。三、GTID 因果路由覆盖复用而非重写3.1 问题所在测试存在但覆盖率缺失GTID 因果路由的测试其实早就存在。test_gtid_from_ok-t.cpp 已经完成了完整的真实写入 →min_gtid因果读取 → 验证只读主机组查询计数工作负载。设计文档明确指出这个测试当前只注册在不上传 GCOV 数据的 binlog 组中即legacy-binlog-g1、mysql84-binlog-g1、mysql90-binlog-g1、mysql95-binlog-g1因此它的执行无法反映到覆盖率报告里。关键决策先在 MySQL 8.4 GCOV 环境中原样运行这个未修改的 TAP。如果它通过、且覆盖率报告包含 GTID 候选分支就把mysql84-g5追加进它的组注册。既不复制工作量也不用单元测试替换它。落地后的注册groups.json 第 583 行为test_gtid_from_ok-t : [ legacy-binlog-g1, mysql84-binlog-g1, mysql84-g5, mysql90-binlog-g1, mysql95-binlog-g1 ]3.2 测试如何构造真实因果负载从源码看测试搭建了一套专用的、高优先级的路由环境避免与组基线的通用testuser规则冲突专用前端账号gtid_from_ok_tap注释明确说明该账号故意不属于任何组基线测试会安装高优先级专用规则否则会被覆盖率组里的通用规则抢占专用主机组写主机组RW_HG15983、只读主机组RO_HG15984专用规则区间159830~159832INSERT 与session_track_gtids查询走向写组SELECT id FROM test.gtid_from_ok走向只读组后端行为控制将mysql-update_gtid_from_ok先设为false验证 min_gtid 读取被拒绝disabled OK-packet ingestion rejects min_gtid read再设为true并LOAD MYSQL VARIABLES TO RUNTIME验证因果读取生效。测试的核心执行链run_test依次串联resolve_writer_endpoint从runtime_mysql_servers解析 ONLINE 写端点并转成数字 IPBINLOG_WHG环境变量可指定优先的写主机组install_dedicated_routing插入前端用户、双主机组服务器只读组gtid_port1与三条专用规则configure_gtid_variables保存并覆盖mysql-connect_timeout_server_max、mysql-client_session_track_gtid、mysql-default_session_track_gtids、mysql-server_capabilities追加CLIENT_SESSION_TRACKING与mysql-update_gtid_from_okverify_disabled_ingestionSET SESSION session_track_gtidsOWN_GTID后 INSERT 第 1 行从 OK 包取回 GTID确认关闭状态下/* ;min_gtid... */读取被拒绝verify_untracked_insert确认未请求跟踪的会话 INSERT 不回传 GTID、端点 GTID 记录保持为空verify_tracked_causal_readINSERT 第 3 行拿到 GTID 后轮询stats_mysql_gtid_executed直至端点学习到该 GTID再发起/* ;min_gtidgtid3 */因果读取断言读回id3并验证只读组15984的查询计数严格递增。3.3 源码印证候选分支在MyHGC.cpp测试想要打中的 GCOV 分支位于 lib/MyHGC.cpp 的get_random_MySrvC(char *gtid_uuid, uint64_t gtid_trxid, int max_lag_ms, MySQL_Session *sess)定义于第 107 行。在该函数的候选扫描循环中当gtid_trxid非零时即 GTID 因果读取场景每个 ONLINE 服务器必须通过MyHGM-gtid_exists(mysrvc, gtid_uuid, gtid_trxid)校验才进入候选数组第 167–173 行同时max_lag_ms 0时还要求(unsigned int)max_lag_ms mysrvc-aws_aurora_current_lag_us/1000第 175–176 行。由于测试走真实前端写入并经 OK 包学习 GTID再以min_gtid注释触发因果读get_random_MySrvC的gtid_trxid分支会在运行时真正被执行从而被编译器匹配的 GCOV 记录为已覆盖。四、Aurora 查询路由覆盖模拟器只做控制面4.1 为什么需要TEST_AURORA模拟器普通 MySQL 无法提供 Aurora 专属的REPLICA_HOST_STATUS监控源。设计文档明确说明只有带REPLICA_HOST_STATUS的源才能让 ProxySQL 分配被测代码依赖的 Aurora lag 字段aws_aurora_current_lag_us。因此备选方案用普通 MySQL 充当 Aurora 源被直接否决。而TEST_AURORA模拟器在此处的职责被严格限定只用于控制监控状态monitor state不构造客户端流量、也不充当裸线客户端助手。真正的断言流量是普通 libmysql 查询经由 ProxySQL 前端转发。4.2 模拟器 fixture三节点 Aurora 拓扑状态注入由模拟器 payload 描述query_routing.json 定义了三节点实际为四台服务器拓扑主机角色初始 lagREPLICA_LAG_IN_MILLISECONDS主机组host.1.11.aws-test.com写节点MASTER_SESSION_ID01271host.1.12.aws-test.com零延迟只读副本01272host.1.13.aws-test.com低延迟合格副本41272host.1.14.aws-test.com高延迟副本高于查询注解的max_lag_ms501272配套的 Aurora 主机组配置mysql_aws_aurora_hostgroups为写组 1271、读组 1272、domain_name.aws-test.com、监控阈值max_lag_ms100高延迟服务器保持在监控阈值之下 ONLINE从而测试服务器在线但被查询注解过滤的场景、writer_is_also_reader1。4.3 TAP 的执行链与断言test_aurora_query_routing-t.cpp 的流程与设计文档的四步完全对应注入状态以cluster_simulator --mode verify -f payload运行模拟器依赖环境变量CLUSTER_SIM_BINARY_PATH与CLUSTER_SIM_TESTS_ROOT并校验其 JSON 输出err_type none等待收敛通过AuroraVariableRestore::set_one_replica_minimum()将mysql-aurora_max_lag_ms_only_read_from_replicas置为 1 并LOAD MYSQL VARIABLES TO RUNTIME该 RAII 守卫同时保存旧值、在析构时恢复防止部分 SET/LOAD 泄漏状态发出真实前端查询以aurora1/pass1账号连接 ProxySQL 普通前端执行带注解的查询SELECT version_comment LIMIT 1 /* ;max_lag_ms10;create_new_connection1 */断言后端身份与计数共 9 项断言plan(9)查询成功host.1.13lag 4ms处于注解阈值 10ms 内的连接池计数ConnUsedConnFree增加host.1.12零延迟候选与写节点host.1.11的连接池计数保持不变stats_mysql_global中的get_aws_aurora_replicas_skipped_during_query计数器严格增加证明host.1.14因超过max_lag_ms10被跳过。测试开头注释精确概括了分工cluster simulator 被刻意限制在监控控制面它发布一个写节点、一个低延迟副本、一个高延迟副本断言流量本身是经过 ProxySQL 前端的普通 libmysql 流量。4.4 源码印证lag 过滤、跳过计数与 writer 移除MyHGC.cpp中与此测试对应的三条执行路径1lag 过滤与跳过计数第 175–183 行候选扫描中max_lag_ms 0时比较注解阈值与服务器aws_aurora_current_lag_us/1000不满足的服务器走else分支递增st_var_aws_aurora_replicas_skipped_during_query——这正是 TAP 断言计数器增加所验证的代码if ((unsigned int)max_lag_ms mysrvc-aws_aurora_current_lag_us/1000) { ... mysrvcCandidates[num_candidates]mysrvc; num_candidates; } else { sess-thread-status_variables.stvar[st_var_aws_aurora_replicas_skipped_during_query]; }2writer 排除第 271–296 行max_lag_ms 0时读取aurora_max_lag_ms_only_read_from_replicas源码取名为min_num_replicas当候选数 ≥ 该值、且候选的aws_aurora_current_lag_us总和非零避免误判全零场景时将所有aws_aurora_current_lag_us0的候选即写节点从候选数组中移除。TAP 断言写节点连接数不增加正是这条 writer-removal 路径被执行并生效的证明。3TEST_AURORA统计插桩第 115–122 行#ifdef TEST_AURORA下维护array_mysrvc_total/array_mysrvc_cands用于模拟器环境下的候选统计说明该模拟器代码路径本身即为覆盖率设计的一部分。注册groups.json 第 505 行test_aurora_query_routing-t : [ cluster_sim_aurora-g1 ]cluster_sim_aurora-g1是会上传 GCOV 数据的工作流组保证该测试的执行能进入覆盖率报告。五、内置 Admin 测试覆盖行为断言而非盲目派发5.1 原则扩展已有调用者的行为覆盖PROXYSQLTEST是一条由 Admin 接口处理的测试命令其派发逻辑位于 lib/ProxySQL_Admin_Tests2.cpp第 1156–1158 行以sscanf解析PROXYSQLTEST n arg1 arg2 ...。设计文档的原则是扩展它们的行为覆盖而不是盲目地派发每一个编号——即不追求把所有 case 都跑一遍而是挑出已有 TAP 调用者从未覆盖、且具备可观测行为后置条件的命令逐一断言其效果。5.2 Digest 路径命令 2 / 3 / 6对应源码中的三个 casecase 1第 1161–1169 行ProxySQL_Test___GenerateRandomQueryInDigestTable(test_arg1)生成test_arg1*1000条随机 digest 条目case 2第 1170–1176 行ProxySQL_Test___GetDigestTable(false, false)——只快照digest map不写 DBcase 3第 1177–1183 行ProxySQL_Test___GetDigestTable(true, false)——快照并 reset不写 DBcase 6第 1196–1201 行ProxySQL_Test___PurgeDigestTable...(true, false, arg1)——异步 purgedigest map。test_admin_builtin_coverage-t.cpp 依次验证前 11 项断言覆盖该路径PROXYSQLTEST 3 0清空任何既有内存 digestPROXYSQLTEST 1 1生成 1000 条断言affected_rows 1000PROXYSQLTEST 2 0快照断言行数 0PROXYSQLTEST 3 0快照并 reset断言返回行数等于快照行数PROXYSQLTEST 2 0再次快照断言为 0reset 确实生效PROXYSQLTEST 1 1重新生成 1000 条PROXYSQLTEST 6 0启动异步 purge断言接受的条目数 0随后有界轮询PROXYSQLTEST 2 0直至返回 0 行10 秒超时wait_for_empty_digest_table证明异步 purge 真正完成。这里对异步完成的验证是本测试区别于仅接受命令成功的关键——测试用mysql_affected_rows观察命令返回值并用轮询观察 digest 表的终态而不是简单调用后直接断言成功。5.3 Fast-routing 路径命令 12 / 13 / 16对应源码中的 casecase 12/case 16第 1230–1248 行ProxySQL_Test___GenerateRandom_mysql_query_rules_fast_routing(arg1, with_username)生成随机 fast-routing 表——12生成带 username的规则16生成空 usernametrue参数的规则两者生成后都会执行load_mysql_query_rules_to_runtime()把表载入运行时case 13第 1249–1262 行循环load_mysql_query_rules_to_runtime()指定次数。TAP 的对应断言第 12–23 项PROXYSQLTEST 12 64断言影响行数 64并分别统计配置表mysql_query_rules_fast_routing与运行时表runtime_mysql_query_rules_fast_routing中username 的行数二者均为 64——证明生成且已加载到 runtimePROXYSQLTEST 13 2重复加载两次后runtime 中命名规则仍为 64 条——证明重复加载无损PROXYSQLTEST 16 64断言影响行数 64配置表与运行时表中username 的行数均为 64。5.4 Teardown从磁盘恢复规则测试用 RAII 守卫QueryRulesRestore在构造时生效、所有退出路径含早期 return 与异常路径上执行LOAD MYSQL QUERY RULES FROM DISK LOAD MYSQL QUERY RULES TO RUNTIME从而保证 fast-routing 生成器对规则表的污染在测试结束后被完全还原。设计文档还特别划定了不覆盖的边界命令 31 的 mode 2/3存在未调查的FIXME不做覆盖尝试无条件 early return 之后的代码、以及#ifdef DEBUG保护下的代码不属于正常 GCOV 目标使其覆盖需要生产代码或构建矩阵层面的决策而不是增加 TAP 命令。注册groups.json 第 501 行test_admin_builtin_coverage-t : [ mysql84-g5 ]六、备选方案为何被否决设计文档给出了三个被系统否决的备选方案理解它们有助于把握设计意图为三个领域分别新增单元测试——否决。单元测试绕过了路由与 Admin 会话的集成接口而恰恰是这些接口的集成覆盖存在缺口。新增一个 GTID TAP——否决。现有测试已经具备所需的真实因果负载缺陷仅仅是它没有在 GCOV 环境中执行新增测试是重复工作量。用普通 MySQL 充当 Aurora 源——否决。它缺少REPLICA_HOST_STATUS无法让 ProxySQL 分配被测的 Aurora lag 字段因而根本无法驱动目标分支。七、验证方法与 CI 运行设计文档对验证有硬性要求每个变更的 TAP 必须在它所属的隔离组中运行并且聚焦运行的 LCOV 报告必须命中目标行。实现计划给出了可复制的运行方式。7.1 用 GCOV 构建目标测试以 GTID 测试为例ubuntu22_dbg_build容器内git_version$(git describe --long --abbrev7) git_epoch$(git show -s --format%ct HEAD) docker compose run --rm --no-deps --entrypoint bash \ -e GIT_VERSION_BASE$git_version -e GIT_VERSION$git_version \ -e SOURCE_DATE_EPOCH$git_epoch -e WITHGCOV1 \ -w /opt/proxysql ubuntu22_dbg_build -lc make -j8 WITHGCOV1 GIT_VERSION_BASE$GIT_VERSION_BASE GIT_VERSION$GIT_VERSION debug make -C test/tap -j8 WITHGCOV1 GIT_VERSION$GIT_VERSION tap make -C test/tap/tests -j8 WITHGCOV1 GIT_VERSION$GIT_VERSION test_gtid_from_ok-t 7.2 在隔离组中聚焦运行并检查 LCOVexport INFRA_IDcoverage-gtid-proof export TAP_GROUPmysql84-g5 export TEST_PY_TAP_INCLtest_gtid_from_ok-t export COVERAGE1 ./test/infra/control/ensure-infras.bash ./test/infra/control/run-tests-isolated.bash预期结果TAP 通过且 LCOV 报告把 MyHGC.cpp 中的 GTID 候选行标记为已执行。Aurora 组TAP_GROUPcluster_sim_aurora-g1的预期是 LCOV 覆盖 lag 过滤与 writer 移除路径Admin 组mysql84-g5的预期是ProxySQL_Admin_Tests2.cpp覆盖 case 2/3/6/12/13/16。7.3 组注册校验与最终检查所有 groups.json 变更须通过仓库 linter全部变更文件须通过空白检查python3 test/tap/groups/lint_groups_json.py python3 test/tap/groups/check_groups.py --source python3 test/tap/groups/lint_group_coverage.py test/tap/groups/groups.json git diff --check还可直接在覆盖率报告产物中检索目标文件确认命中rg -n MyHGC\.cpp|ProxySQL_Admin_Tests2\.cpp ci_infra_logs/*/coverage-report/*.info八、小结这份设计给出了一个可复用的覆盖率缺口修补方法论优先复用并重定位已有真实负载GTID、把模拟器严格限制在控制面Aurora、以行为后置条件驱动内建命令覆盖Admin。三者都坚持走真实前端/Admin 接口、坚持在 GCOV 组中聚焦运行、坚持用 LCOV 逐行验收。对希望为 ProxySQL 贡献测试覆盖的开发者而言这套设计 → 计划 → 聚焦验证 → 注册 → 校验的流程与 设计文档、实现计划 中的完整命令可以直接作为后续同类工作的模板。赞分享后端数据库负载均衡【免费下载链接】proxysqlHigh-performance proxy for MySQL and PostgreSQL项目地址https://gitcode.com/gh_mirrors/pr/proxysql点击查看免费下载相关推荐ProxySQL 覆盖率工程实战GTID 因果读、Aurora 延迟路由与 Admin 内建命令的 GCOV 覆盖计划ProxySQL 覆盖率工程实战GTID 因果读、Aurora 延迟路由与 Admin 内建命令的 GCOV 覆盖计划 本文基于仓库计划文档 docs/sup后端数据库负载均衡Voyager 路由覆盖指南在 Laravel Admin 中安全重写内置路由Voyager 路由覆盖指南在 Laravel Admin 中安全重写内置路由 Voyager 是 Laravel 生态中著名的 Missing Larav后端CMSProxySQL CI 覆盖率采集器 GCOV 兼容性改造用 GCOV 11 统一 TAP 覆盖率转换链路ProxySQL CI 覆盖率采集器 GCOV 兼容性改造用 GCOV 11 统一 TAP 覆盖率转换链路 本文围绕仓库内 docs/superpowers/后端数据库负载均衡上一篇终极智能家居安全配置指南保护Home Assistant系统的10个关键步骤下一篇Linux Deploy终极指南在Android上快速搭建完整Linux系统创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
