为什么mycat读服务器没有日志，mycat日志缺失咋排查？

Mycat读服务器没有日志，多数情况下不是日志“丢了”，而是日志级别没开、SQL根本没路由到读库，或者读库自身的general_log、slow_log处于关闭状态。 先分清“谁的日志”，再按配置、路由、连接三层排查，通常比盲目重启更有效。

先分清三种“没日志”，别一上来就改配置

“读服务器没有日志”这句话，在Mycat场景里至少对应三种不同现象，现象不同，排查路径完全不一样。

第一种：mycat.log里看不到读库相关记录

Mycat默认日志级别通常是info,启动信息、连接异常会记录，但每条SQL是否发往读库，未必会完整打印，尤其是SQL量不大时，日志文件看起来“很干净”，容易让人误以为读库没工作。

验证方法很直接：

• 进入Mycat安装目录,执行tail -f logs/mycat.log，同时发起一条明确的查询。
• 如果日志没有任何新增,先检查日志级别，而不是怀疑读库。
• 如果日志有SQL但看不到读库标识,说明当前日志粒度不够。

第二种：读库本地日志空白

这里的“日志”指MySQL从库自己的general_log、slow_query_log或错误日志，据MySQL官方文档，general_log和slow_query_log默认都是关闭状态，不会因为Mycat连上来就自动开启。

在从库执行：

SHOW VARIABLES LIKE 'general_log';
SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'log_error';

如果general_log是OFF,业务SQL再多也不会出现在日志里，临时开启可以执行SET GLOBAL general_log=ON;，但要注意磁盘增长，排查完及时关闭。

第三种：日志有记录，但没有“读”的痕迹

这种情况最容易被忽略：Mycat日志正常，从库日志也有，但所有SQL都落在主库，问题不在日志，而在读写分离规则没有生效。

Mycat读写分离读库没有日志怎么排查

下面按从外到内的顺序走一遍,基本能覆盖大部分生产场景。

第一步：确认日志框架和日志级别

Mycat 1.6常用Log4j2，配置文件在conf/log4j2.xml；Mycat 2.x的日志配置有调整，具体文件以版本目录为准，打开配置文件，先看Root级别：

• 如果Root是info，把与SQL路由、后端连接相关的logger调到debug，再复现一次查询。
• 改完后不需要重启的情况较少,多数版本需要重启Mycat或重新加载配置。
• 观察logs/mycat.log是否出现读库连接、SQL转发相关记录。

这一步的目的是确认“Mycat有没有尝试把SQL发往读库”，如果debug级别下仍然没有任何读库连接记录，直接进入第二步。

第二步：确认读节点是否真的被使用

打开schema.xml，检查dataHost里的balance和writeType，业内常见的读写分离配置是balance="1"、writeType="0"，如果balance="0"，读请求不会分流到readHost，从库自然没有日志。

同时确认：

• readHost的host、port、user、password是否与从库实际信息一致。
• 从库账号是否允许Mycat所在主机连接,执行SELECT host,user FROM mysql.user;核对。
• 防火墙、安全组是否放行从库端口。

改完配置后,通过Mycat管理端口执行reload @@config;，再观察日志，管理端口默认9066，具体命令随版本不同会有差异。

第三步：确认连接池是否建立到从库的连接

连接池通常是懒加载,业务量小、读请求少时，从库连接可能还没建立，日志里看不到属于正常现象，可以在Mycat管理端口执行：

show @@datasource;
show @@heartbeat;

重点看读库数据源的状态和心跳结果,如果心跳失败，mycat.log里一般会有连接异常，这时问题在账号、网络或从库状态，不在日志配置。

也可以在Mycat服务器上直接用命令行连从库：

mysql -h 从库IP -P 3306 -u 用户名 -p -e "select 1"

命令行都连不上,就不用继续查Mycat日志了。

第四步：确认从库自身日志开关和输出位置

从库能连上、Mycat也转发了SQL，但本地日志仍为空，就看两个参数：

• log_output：决定日志写文件还是写表，写表时要去mysql.general_log查，不要盯文件。
• general_log_file：确认文件路径，别在错误目录里找。

生产环境更推荐用慢查询日志做长期观察,把long_query_time调到业务可接受的值，比长期开general_log更稳妥，行业共识认为，general_log适合短时间定位问题，不适合长期常开。

Mycat 1.6和2.0日志配置区别

不同版本的日志行为差异,是很多“换了版本就读库没日志”的根源，下面这张表按常见情况整理，具体以实际安装包为准。

版本升级后读库没日志,先对比日志配置文件和schema配置是否完整迁移，再查路由。

生产环境Mycat日志排查的常见坑

坑一：只看Mycat日志，不看从库日志

Mycat记录的是“我转发了什么”，从库记录的是“我收到了什么”，两边对不上，才能判断是转发失败还是执行失败。

坑二：开了general_log忘了关

general_log记录所有语句,写放大明显，排查完执行SET GLOBAL general_log=OFF;，并确认log_output设置符合预期。

坑三：容器化部署找错日志位置

容器里Mycat日志可能输出到stdout,用docker logs看，而不是进容器找logs/mycat.log，Kubernetes环境则要查对应Pod日志。

坑四：日志轮转把现场覆盖了

高并发下日志增长快,轮转策略过激进会冲掉关键时间段，排查期间临时调大保留份数，复现后再恢复。

坑五：只改配置不验证路由

改完balance后没有发起读请求，也没有看show @@datasource，就认为问题解决了，读库日志依然为空，是因为读请求根本没发生。

读库日志缺失背后的成本账

日志问题看似小,实际影响故障定位效率，生产环境一次读写分离异常，如果没有读库侧记录，排查时间可能从几分钟拉长到数小时，自建团队需要投入DBA和中间件运维人力；采购商业支持服务则涉及年度服务费用，具体价格随厂商和服务范围差异较大，公开报价并不统一，对中小企业来说，先把日志级别、general_log、balance这三项纳入日常巡检，往往比事后买服务更划算，本地部署Mycat的团队，还可以把日志目录、轮转策略、磁盘告警写成固定检查项，减少重复踩坑。

关于Mycat读服务器没有日志的常见问答

Q1：Mycat读服务器没有日志，是不是读库坏了？

不一定,先看Mycat管理端口的show @@heartbeat和show @@datasource，心跳正常、数据源在线，说明读库本身可用，问题更可能在日志级别或路由规则，心跳异常再查网络、账号和从库进程。

Q2：为什么调了debug级别，mycat.log还是没有读库SQL？

常见原因是读请求没有命中读节点,或者连接池尚未建立到从库的连接，检查schema.xml中balance是否为1、readHost是否配置正确，再发起多次查询观察，若使用Mycat 2.x，还要确认数据源配置已正确加载。

Q3：从库general_log开了，为什么还是看不到Mycat发来的SQL？

先确认log_output是FILE还是TABLE，TABLE模式要去mysql.general_log表里查；再确认Mycat实际连接的是不是这台从库，可通过show @@datasource核对IP和端口；最后检查从库账号权限和连接来源限制，三处都一致时，general_log会如实记录收到的语句。