数据库中间件这东西部署起来不难真正难的是让它长期稳定地跑着。Mycat作为国内用得最广的开源分布式数据库中间件之一很多团队把它搭起来、写完分片规则、业务连上之后就当成透明代理放在那儿不管了。可等你某天遇到连接数爆满、数据源心跳失败、SQL突然变慢的时候才会反过来翻管理和监控的手册——而这时候通常已经是在救火了。这篇文章会围绕Mycat的管理与监控展开命令行怎么管、可视化控制台怎么搭、指标怎么接进Prometheus和Grafana以及我实际遇到过的一些坑。适合正在使用Mycat的Java后端、DBA也适合刚开始接触中间件运维的朋友。先说个观点管理和监控的功课如果不做在前面Mycat跑得再顺也是运气。我见过一个团队Mycat上线大半年没出过大问题结果大促流量一上来连接池直接被打穿几个人现场翻命令手册找kill connection怎么写那场面真的狼狈。所以下面内容不是教科书复读而是按我实际运维时常用的顺序来写的先理解管理监控的整体结构再落命令和工具最后给故障排查清单。1. 管理与监控的整体设计先搞清楚要管什么、看什么1.1 管理的本质配置、连接、数据源、权限四条线我们可以把Mycat的管理工作拆成四条线每一条都对应一类具体操作。第一条线是配置管理。Mycat的核心配置集中在三个文件里server.xml管用户认证和全局参数schema.xml管逻辑库、逻辑表以及它们和后端物理库的映射关系rule.xml管分片规则。很多问题比如路由错误、表查不到都是这三个文件改得和实际数据不一致导致的所以配置管理是所有管理操作的基础。第二条线是连接管理。Mycat对外暴露两个端口8066是业务端口客户端通过它执行SQL9066是管理端口DBA通过它执行管理命令。连接管理要同时关注前端连接客户端到Mycat和后端连接Mycat到后端MySQL两个池子的状态。前端连接过多说明应用侧连接池可能泄漏后端连接过多说明Mycat到数据库的长连接没有及时释放这两个是连接数告警里最关键的数据来源。第三条线是数据源管理。Mycat通过dataHost和dataNode来抽象后端MySQL实例每个dataHost可以配置主从、读写分离权重和心跳检测。数据源是否存活、主备是否切换、心跳是否正常直接决定了读写链路稳不稳。我处理过的故障里因为数据源心跳异常导致读写流量走偏的情况比SQL本身写错还多。第四条线是权限管理。server.xml里配置的user节点除了限制能访问哪些逻辑库还能控制只读还是读写。即便是内部中间件也建议给业务账号和运维账号分开授权业务账号给最小权限运维账号才有9066的各类管理权限。这四条线理顺了后面的监控指标才知道往哪儿归排查问题时也能快速定位是配置层、连接层、数据源层还是权限层出了问题。1.2 监控的目标可用性、性能、容量、依赖四个维度监控不能等到出了问题再做这一点对中间件尤其重要。Mycat是整个数据访问链路的入口它挂掉或者性能劣化影响的不只是单个数据库而是所有接入它的业务。所以监控维度至少要有四个缺一个都会出现盲区。第一个维度是可用性包括Mycat进程是否存活、9066管理端口是否可连接、后端数据源心跳是否正常。第二个维度是性能包括QPS、TPS、SQL执行耗时、慢SQL数量、并发数变化。第三个维度是容量包括前端连接数、后端连接数、JVM堆内存使用率、磁盘空间、网络带宽。第四个维度是依赖状态Mycat不是孤立的它依赖后端MySQL集群Mycat-web还依赖ZooKeeper监控体系本身也可能依赖Prometheus、node_exporter这些组件任何一个环节断掉都会影响判断。这四个维度不是平均用力。以我的经验最需要优先盯的是心跳状态和连接数一个是数据链路的地基一个是旺季大促时最容易爆的瓶颈。心跳挂了但MySQL其实活着的情况比MySQL真的挂掉更头疼因为它会把问题从“数据库不可用”引向“Mycat误判”排查路线完全不同。后面所有的管理命令和监控配置都是为这四个维度服务的。2. Mycat管理实操9066命令与Mycat-web控制台2.1 9066管理端口常用命令与输出字段解读Mycat的管理命令都通过9066端口执行登录方式和正常连MySQL差不多装个mysql客户端就能用mysql -h127.0.0.1 -P9066 -uroot -p123456连上之后就可以执行各类show 开头的管理命令。下面是我日常最常用的一组命令整理成了一张速查表命令作用需要关注的输出字段show database查看当前可访问的逻辑库列表逻辑库名show connection查看前端连接详情host、user、schema、stateshow backend查看后端连接池中的连接host、port、dn、stateshow datanode查看数据节点分布dn、database、dataHostshow datasource查看物理数据源连接状态地址、端口、最大连接、活跃连接show heartbeat查看每个dataHost的心跳情况lastHeartbeat、status、heartbeatErrorshow command查看命令统计增删改查数量DML、DQL的次数show sql查看正在执行的SQL用户、SQL文本、耗时show slow查看慢SQL统计SQL、执行次数、平均耗时、最大耗时show sysparam查看系统参数线程池大小、bufferPool大小reload config热加载schema、rule等配置执行结果rollback config回滚最近一次配置变更执行结果光看不练没有意义举一个实际场景。某天应用突然报“too many connections”第一步我会先连9066执行show connection看前端连接的host来源和state。如果state基本都是Idle说明是客户端连接池没释放如果连接数接近配置上限再用kill connection清理异常连接比如某个来源IP占了大批量连接时kill connection 10086这个命令按连接ID清理ID可以从show connection的PROCESS列看到。紧急处理后再去查应用侧连接池配置否则过一会儿又会涨回来。这块的经验是管理命令本身不复杂复杂的是通过输出字段反推业务链路里哪个环节出了问题这需要你熟悉每条命令的字段含义而不是只会敲命令。2.2 Mycat-web控制台部署与数据上报原理命令行的好处是轻量、直接但想看趋势图和历史统计还是得靠可视化控制台。Mycat官方配套的控制台是Mycat-web早期版本也叫Mycat-eye它可以把Mycat的运行状态上报、聚合再用Web页面展示。部署Mycat-web时常见做法是下载war包放进Tomcat或者直接用自带启动脚本。它依赖ZooKeeper来保存自身配置和采集的任务信息所以要先准备好一个可用的ZooKeeper。启动之后默认访问端口8082首次进入需要配置ZooKeeper地址和Mycat的登录信息。Mycat节点会通过内置的采样任务定期把9066端口能拿到的状态数据连接数、SQL统计、心跳结果、JVM信息上报给Mycat-web页面上的数据节点状态、SQL分析、读写比例就是这样来的本质上是把管理命令的结果做了一层定时采集和可视化。不少朋友现在更喜欢容器化部署。比如我曾经帮一个团队把Mycat-web的服务端塞进Docker思路很简单基础镜像装好JDK和Tomcat把war包和环境变量打进去再用-p 8082:8082暴露端口。容器化确实省事但要注意ZooKeeper连接串和时区都得配置正确我遇到过好几次容器里时区不对导致监控图表时间线错位的问题一查日志才发现是容器默认用了UTC时区和本地的北京时间差了8个小时所有曲线看起来都像延迟了一样。需要提醒的是Mycat-web项目后续更新不算活跃新环境接入时要先确认版本兼容性特别是JDK版本、ZooKeeper版本。如果团队已经有成熟的Prometheus体系我更推荐把它作为辅助管理界面而核心告警和趋势分析交给Prometheus体系来做这样即使Mycat-web本身出现数据断档还有一条独立的监控链路兜底。2.3 配置文件热加载的正确姿势修改Mycat的schema.xml、server.xml或rule.xml之后不需要重启进程通过9066端口执行热加载就可以让配置生效。但热加载不是无脑执行reload按变更范围选择合适的命令这里是有讲究的。reload config; reload route; reload user;reload config是整体加载全部配置reload route只加载路由配置reload user只刷新用户权限。如果只是调整了某个分片表的规则没必要把用户权限也重新刷一遍权限更新反而会短暂影响在线会话。执行后Mycat会重新解析XML并应用整个过程对业务SQL的影响通常很小但依然建议在低峰期操作。热加载最大的坑是XML写错。Mycat解析配置时对格式要求比较严一个标签没闭合、一个属性名拼错reload执行后可能不会立刻报错而是等下一次SQL路由时出问题。所以我养成两个习惯改文件前先备份保留带日期后缀的副本reload之后立刻跑一遍冒烟用例覆盖原本的增删改查路径。万一线上出现了配置错误导致路由异常还能用rollback config快速回滚到上一次可用配置这个命令比紧急改文件再reload要快得多属于保命技能。3. 监控体系搭建从指标清单到PrometheusGrafana3.1 先列监控指标清单别等出事了再想很多团队的监控是从“看到别人有Dashboard才想起来加”开始的这样容易漏掉关键项。我习惯先把Mycat的监控指标列成一张清单再决定用什么工具采集。这比先选工具再想指标要合理得多因为工具是手段指标才是目的。下面这张表可以作为参考指标分类具体指标获取方式建议告警阈值可用性Mycat进程存活、9066端口连通shell脚本、端口探测进程或端口不可用立即告警可用性数据源心跳状态show heartbeat心跳失败立即告警性能QPS、TPS、命令执行次数show commandQPS超过平时水位2倍或持续攀升时告警性能慢SQL数量、平均耗时show slow慢SQL数量突增或平均耗时翻倍容量前端连接数、后端连接数show connection、show backend达到池上限80%容量JVM堆内存、GC次数JMX堆内存使用率持续超过80%或Full GC频繁系统CPU、内存、磁盘、网络node_exporterCPU85%、磁盘使用率85%列完清单会发现Mycat本身的指标大多数都能从9066管理端口拿到而系统层面的指标如CPU、磁盘走node_exporter就行。真正难的不是数据源而是统一采集和可视化这一步通常落到Prometheus和Grafana上。现在社区里聊监控基本绕不开这套组合很多团队甚至同时维护着Zabbix和Prometheus两套体系但Mycat这种偏开发态的中间件用PrometheusGrafana会更顺手告警规则写起来也更灵活。3.2 Prometheus采集Mycat指标的四种常用方案Mycat不是Prometheus原生支持的对象接入时我有过几种方案从简单到复杂都试过说下各自的适用场景大家可以根据团队现状选。第一种方案最简单用mysqld_exporter连Mycat的8066端口。因为Mycat对外走的是MySQL协议mysqld_exporter用普通业务账号就能连上去采集到的全局状态和线程状态里包含Mycat透传的一些MySQL变量比如连接数、线程数、Com_select等。优点是部署快缺点是很多Mycat自身的管理指标取不到只能当基础数据用。第二种方案是给Mycat打开JMX然后用jmx_exporter采集。Mycat是Java进程启动时加上-Dcom.sun.management.jmxremote.port1984 -Dcom.sun.management.jmxremote.authenticatefalse -Dcom.sun.management.jmxremote.sslfalse这些参数就能把JVM堆内存、GC等指标暴露出来。这是补全JVM指标的必要手段但JMX端口一定要限制在可信网段内否则有安全风险生产环境尤其要注意。第三种方案是node_exporter的textfile collector。写一个定时脚本登录9066端口执行show heartbeat、show command等命令把输出转换成Prometheus文本格式写到/var/lib/node_exporter/textfile目录node_exporter会自动暴露这些指标。这种方式不引入新组件只需要服务器上装了mysql客户端对大多数团队来说是最容易落地的。第四种方案是自研或使用社区开源的专用exporter本质上是替你把管理命令翻译成指标。优点是格式和命名规范可控缺点是前期有开发量还要持续维护。综合来看我的建议是如果只是先跑起来用方案三把心跳、连接数、命令数几个核心指标接进来就够了等规模上来后再叠加方案二的JMX采集JVM指标。方案一可以作为补充但不要只依赖它。给一个方案三的脚本示例把show command采集成Prometheus文本格式#!/bin/bash # mycat_export.sh 每60秒执行一次 OUT_DIR/var/lib/node_exporter/textfile MYSQLmysql -h127.0.0.1 -P9066 -uroot -p123456 -N -e TMP_FILE$OUT_DIR/mycat_command.prom.$$ $MYSQL show command; | awk NR1 { printf mycat_command_total{command\%s\} %s\n, $1, $2 } $TMP_FILE mv $TMP_FILE $OUT_DIR/mycat_command.prom脚本里的密码默认写在命令行里实际生产建议放到~/.my.cnf并配置好权限避免在进程列表里暴露。另外脚本执行时间要注意和采集周期错开比如Prometheus每15秒抓一次textfile脚本就每60秒写一次文件避免高频写文件造成IO波动。3.3 Grafana大盘与告警规则配置数据进了Prometheus之后展示和告警就是Grafana的活。配置数据源的时候填Prometheus的HTTP地址比如http://prometheus:9090然后导入一个Mycat相关的Dashboard JSON或者自己从零建Panel。我习惯把核心Panel分三块顶上放数据源心跳状态和连接数中间放QPS/TPS曲线和SQL统计下面放JVM堆内存和系统资源。这样一屏扫下来可用性、性能、容量三个维度基本都能覆盖。告警规则比Dashboard更优先。用PromQL写几个关键规则比如连接数接近上限mycat_front_connections 3000心跳异常mycat_heartbeat_status 0JVM堆内存使用率过高(jvm_memory_bytes_used{areaheap} / jvm_memory_bytes_max{areaheap}) 0.8配上Alertmanager之后可以把告警推到钉钉、企业微信或邮件。这里有个容易被忽略的问题指标命名不统一会导致告警规则维护困难。textfile方案里不同机器的指标名称、label设计最好提前约定好比如都叫mycat_front_connections而不是这一台叫mycat_front_count、另一台叫mycat_active_conn不然每加一个节点就要改一套规则后面会很痛苦。针对“grafana生成pdf监控报告”这个需求Grafana有图形渲染服务grafana-image-renderer可以配合定时任务生成仪表盘截图或PDF我们团队就是用它每周自动出一份Mycat节点健康报告用于大促前检查比人工截图省事很多。不过这属于锦上添花先把告警跑通更重要周报做得再漂亮该告警的时候没告警那监控体系就是失效的。4. 典型故障排查连接爆满、心跳假死、热加载失败4.1 连接数被打满先分清前端连接和后端连接运行期间最常见的故障就是连接数报警。应用报错一般是“too many connections”或者连接超时这时候第一反应应该是连9066执行show connection和show backend先把到底是前端还是后端连接满了搞清楚然后才能决定是调应用连接池还是调Mycat的dataHost连接参数。如果是前端连接很高且大量Idle说明应用侧连接池没有正确释放连接常见的坑包括应用忘记归还连接、连接池的maxActive配置过大、连接池的minIdle设置太高导致空闲连接不回收。这种情况光在Mycat里kill没用治标不治本得让开发去查连接池的获取归还逻辑或者给连接池加空闲回收时间。如果是后端连接满要检查dataHost上针对这个MySQL实例的maxCon配置是否够用同时看后端MySQL的max_connections是否被顶满。大促场景下我习惯提前把预警阈值调到池上限的80%并且给连接数面板单独开一个告警避免真正满了才被动处理。还有一个细节Mycat的后端连接是按dataNode维度建的如果某个分片数据集中到了同一个物理库那这个库的后端连接压力会明显高于其他节点这种情况只调全局maxCon是不行的需要针对单个dataHost单独调。4.2 心跳失败导致数据源被判下线心跳是Mycat判断后端数据源是否可用的核心机制。常见现象是某一时刻开始所有指向某个dataHost的请求都报错但直接连后端MySQL却是好的。此时先看show heartbeat的输出正常情况下status应该是1如果出现心跳失败或长时间没有心跳再逐个排查原因。我碰到过的原因有这几种后端MySQL重启后账号权限没加载、心跳语句select user()被防火墙拦了、MySQL的max_allowed_packet设置太小导致心跳包异常、网络抖动触发连续失败。排查时先在后端MySQL上手动执行心跳语句确认返回正常再检查dataHost的heartbeat间隔配置。心跳间隔设置太短会频繁触发网络探测太长又会延迟故障感知一般环境设置在5到10秒比较稳妥。还有一个容易踩的坑Mycat的心跳状态判断是连续失败几次才真正把数据源标记为不可用还是单次失败就切换取决于配置里对writeType和readBalance的处理逻辑。所以收到心跳告警不要急着切主备先观察一段时间确认是瞬时抖动还是持续异常否则可能因为一次网络波动就引发不必要的切换切换本身又会带来连接中断的连锁反应。4.3 reload失败与配置回滚配置热加载失败通常不会直接弹一个“失败”的红色提示反而是业务侧先出现路由异常。比如某个分片表查询突然报找不到表或者查询结果明显是只走了部分分片。这个时候先检查最近有没有人执行过reload config再逐项核对schema.xml和rule.xml。常见问题包括新增分片表时rule.xml里的分片函数或分片字段写错、逻辑表和物理表数量不一致、多个逻辑库引用了同一个重复的dataNode名称。如果确认配置有问题最快的恢复手段是rollback config它会回滚到Mycat保存的上一次有效配置。回滚之后还要重新梳理变更内容不要直接在同一份有问题的配置上反复reload那样只会反复触发同样的路由错误。这里说一个很实用的流程每次改配置前先把show version记一下回滚后对比版本号能快速确认是否真的回滚成功了。另外热加载后不要立刻把所有流量都切过去可以先在测试环境执行同样的变更确认路由结果符合预期再上生产。毕竟线上环境出问题最贵的不是修复本身而是排查过程中消耗的窗口期。4.4 监控数据不更新或采集失败的小问题监控链路本身也会出问题而且因为监控不是业务主链路往往是被动发现。比如Mycat-web页面数据停在几个小时前或者Prometheus target显示down。前者要先检查Mycat-web和ZooKeeper的连接很多老版本在ZooKeeper会话失效后不会自动重连需要重启Mycat-web服务。后者如果是Prometheus抓取失败要看是采集脚本挂了还是target地址配置错了。如果用的是textfile方案先确认采集脚本有没有定时执行、输出目录权限是否正确、Prometheus配的job路径是否指向了textfile目录。这些排查其实都有固定的自检顺序先看进程再看端口再看日志最后看数据。我的做法是给采集脚本本身也加一个简单的历史输出每次执行记录一下时间戳这样Prometheus上能直接看到mycat_export_timestamp这个指标一旦数据停更马上能区分是采集端挂了还是展示端挂了不用每次都跑到服务器上手动跑一遍脚本。还有一种情况是收集机换了IPPrometheus的scrape配置里还是旧地址target显示down但服务其实没问题。这种基本都是变更管理不完善造成的建议IP变更流程里强制带上监控配置更新的检查项否则监控反而会成为误报源。我个人在实际操作中体会很深的一点管理命令练熟了能救命监控指标看懂了能预防这两件事千万别只做一件。如果只熟悉命令、不搭监控出了问题靠人肉盯大促时根本忙不过来如果只搭了监控、不熟悉命令告警来了也不知道下一步该敲什么。最后的建议是无论选哪种采集方案先把9066端口保护起来再给心跳和连接数配上告警剩下的细节等到真正出事的那一天你会感谢自己提前做了这些。