简介Mycat2基础安装包面向需要构建分布式数据层的中高级后端开发与数据库运维人员解决单机数据库在高并发、海量数据场景下的扩展瓶颈。压缩包共收录51个文件主要涵盖Mycat Server启动脚本、schema.xml等核心配置、SQL初始化脚本、多平台运行库so/dll/jnilib以及日志与状态管理模块整体仅1.2MB轻量且便于快速分发部署。包内还附带wrapper.jar与跨平台守护进程组件可帮助读者在Linux、Windows或macOS环境搭建完整的Mycat2服务实例。通过部署该安装包使用者可逐步掌握数据分片、读写分离、SQL路由等关键机制并结合server.json、state.json等配置理解Mycat2的动态扩展与高可用设计思路。目前已有1056人学习浏览该资源适合正在调研数据库中间件选型或准备自建分布式数据层的开发者参考使用。1. 为什么一个基础安装包值得专门讲Mycat2 到底解决了什么问题MySQL 单实例表数据量冲到几千万甚至上亿行以后索引优化开始失效读写延迟肉眼可见地变高分库分表基本是绕不开的坎。但让业务团队把 DAO 层 SQL 全部改一遍成本高、风险大更常见的做法是引入 Mycat2 这样的数据库中间件用一套“假装自己还是 MySQL 服务”的协议端口把分片、读写分离、分布式序列都挡在应用后面业务连接串只改一个端口就能接入。本文要做的是把我经手的 mycat2 基础安装包从下载、解压、配置到第一次连上 8066 数据端口的完整过程讲透。适合正在做分库分表选型或者被 Mycat1.x 的 XML 配置折腾过的人。2. 先把包看明白再动手mycat2 基础安装包的目录结构与前置环境2.1 发行包形态tar.gz 和 zip 里到底装了什么拿到安装包后最忌讳的就是“解压即跑”我见过不少人把包解压后直接执行 bin 下的脚本结果报错然后对着屏幕发愁。实际上Mycat2 的发布包结构非常传统继承了老 Mycat 的布局主要目录就那么几个每个目录的职责在安装前花十分钟搞清楚能省下后面很多排查时间。以 Linux 服务器上的 tar.gz 发行包为例解压后通常长这样tar -zxvf mycat2-xxx.tar.gz ls -l mycat/解压完成后我一般会按下表逐项核对目录和文件。这也是基础安装包“基础”二字的含义——它不包含业务配置只给你一套能跑起来的中间件骨架剩下的数据源、逻辑库、分片规则都要在这个骨架上长出来。目录/文件作用首装时我重点看什么bin/启动、停止、状态检查脚本是否可执行console 模式是否可用conf/端口、日志级别、数据源相关配置默认端口是否有示例配置lib/中间件自身依赖 jar是否自带 MySQL 连接驱动logs/运行日志输出目录wrapper.log 是否存在version.txt版本标识文件确认实际小版本与发行说明一致bin 目录是入口Linux 下最常见的启动命令是./bin/mycat startWindows 下对应bin\mycat.bat。conf 目录里放着 yml 格式的配置文件是基础安装包里面最需要动手的地方。lib 目录在安装阶段几乎不用碰但如果你后续要接入非 MySQL 数据库、发现缺驱动最终还是要回来往这个目录放 jar 包。logs 目录平时没人看一旦连不上 8066它就是你唯一的抓手后面避坑章节会反复提到它。这里有个容易忽略的细节基础安装包自带的是 MySQL 连接驱动如果你要连 PostgreSQL 或 Oracle得另外找对应驱动放进 lib 目录。我一般会先查包的 README 或发行说明确认它内置了哪些驱动而不是盲目按网络教程操作。另外下载完压缩包后花十几秒做一次完整性校验是值得的常见做法是用 sha256sum 和发布页给出的校验值比对这一步能过滤掉下载中断导致的包损坏。2.2 JDK 版本是第一道门槛装之前先确认两件事Mycat2 是纯 Java 服务所以“装好了以后跑不起来”的最常见原因不是安装包坏了而是 JDK 环境不对。不同时期的 Mycat2 对 JDK 版本要求不一样早期版本在 JDK 8 上运行是主流后期的版本因为依赖升级会要求 JDK 11 甚至 17。这意味着你在下载基础安装包之前应该先确认服务器上装的是哪个版本而不是等到启动报错再回来补课。检查命令非常简单下面这组命令是我每台新机器上都会跑一遍的which java java -version echo $JAVA_HOME $JAVA_HOME/bin/java -version第一条看系统默认 java 的位置第二条看默认 JVM 版本第三条看环境变量是否指向 JDK 根目录第四条最关键——如果这条命令报错说明 JAVA_HOME 没生效如果第三条和java -version输出的版本不一致说明 PATH 和 JAVA_HOME 指向了不同 JDK。这种“系统命令正常但服务起不来”的情况在中间件场景里最迷惑人。启动脚本最终用的是$JAVA_HOME/bin/java而不是 PATH 里的 java。所以如果你发现java -version正常但中间件启动失败请先检查echo $JAVA_HOME的输出。改完 JAVA_HOME 后要么重开一个 ssh 会话要么执行source /etc/profile让它生效否则变量值不会自动刷新。提示如果服务器上装了多个 JDK可以用update-alternatives --config javaDebian 系或手动调整环境变量来切换默认版本但启动脚本读的是 JAVA_HOME两个位置必须对齐不能只改其中一个。2.3 Windows 与 Linux 启动脚本的差异很多人在 Windows 上用 zip 包做本地验证在 Linux 上跑生产。两个平台脚本文件不同坑也有区别。Linux 上最常见的问题是解压后没有给脚本加执行权限直接./bin/mycat start会报 Permission denied。这不是安装包的问题是文件权限位没设置执行下面两条命令即可chmod x bin/* ./bin/mycat startWindows 上我用的是bin\mycat.bat start一般不会缺权限。但 Windows 有个特殊问题JAVA_HOME 路径里如果带空格比如装在C:\Program Files\Java\jdk8或者环境变量末尾多了一个分号mycat.bat 在解析路径时会得到错误结果轻则提示找不到 java重则把一串乱码塞进 classpath。这是因为 Windows 批处理对引号和分号的错误容忍度比 Linux 差很多属于一踩一个准的“血泪经验”。我自己的习惯是本地开发装 JDK 时直接用不带空格的目录比如D:\jdk8服务器上则统一用/usr/local/jdk这样的路径配合 symlink 指向实际安装目录。另外还有一类真实存在的坑服务器上解压了多个基础安装包两个实例抢同一个 8066 端口。第二个启动的会报端口被占用但它可能只打印一条错误就悄悄退出日志很难第一时间看到。排查时用ss -lntp | grep 8066看清占用端口的进程路径账就一目了然了。3. 解压到连上 8066mycat2 基础安装包的最小启动步骤3.1 先改哪两个配置再启动第一次启动我的经验是能不改的东西尽量不改。基础安装包自带的默认配置通常可以让你先把服务拉起来确认包是好的。需要优先检查的是端口和 JVM 堆内存这两项其他配置等验证完再慢慢调。端口方面Mycat2 对外提供数据端口默认值沿用 Mycat 时代的 8066应用连接的是它。如果你的服务器上已经有其他服务占了 8066启动会报绑定失败。所以在启动之前我习惯先扫一遍配置里的端口值grep -rn 8066 conf/ | head -20找到端口配置后如果 8066 被占用就把所有出现 8066 的地方统一改成比如 8067。注意不要只改一处数据端口和管理端口可能同时存在漏改会导致连上去之后行为很怪比如能连上却拿不到逻辑库列表。JVM 堆内存方面基础安装包默认堆大小一般是给开发场景用的生产环境必然要调。但第一次启动我建议保持默认先把流程跑通再回头调。如果机器内存很小比如只有 2GB那就需要把启动脚本里-Xmx的值调小一点否则 JVM 可能因为申请不到内存直接退出。内存参数我一般直接在启动脚本或 conf 下的 JVM 参数文件里找-Xms、-Xmx。开发机场景下把-Xmx设成 512m 足够跑通流程生产环境按每个物理库连接数去估算起步给 1g 到 2g后续用 jstat 监控 GC 情况再继续调。注意 Mycat2 的 JVM 参数可能不集中在同一个文件里用grep -rn Xmx bin/ conf/全局搜一下最保险别凭记忆去翻某一个文件。3.2 前台启动看日志console 模式是第一选择第一次启动我不建议用后台方式因为后台模式下日志被写进文件出错时你只能去翻日志文件。更高效的做法是用前台模式让日志直接打到终端CtrlC 可以随时停掉方便边看边改这个模式下出错原因会直接在眼前展开。cd mycat ./bin/mycat console如果一切正常你会看到类似 server started 的日志然后终端卡在前台等待意思是服务已经在 8066 上监听。这个模式非常适合安装后的第一轮验证。等确认无误再退出、改用后台方式启动。有一点要注意console 模式不是所有发行版都提供如果你的包没有这个参数那就用./bin/mycat start启动然后用tail -f logs/wrapper.log实时跟踪日志。wrapper.log 是中间件运行的核心日志启动失败的原因、端口绑定的异常、SQL 路由的报错基本都在里面。前台日志里如果出现 NoClassDefFoundError 或 ClassNotFoundException多半是 lib 目录缺失依赖 jar或者 JDK 小版本不匹配。这两种情况不要急着重装先核对发行说明里要求的 JDK 确切版本再决定是换 JDK 还是换安装包。把日志当成第一信源而不是反复重启服务去猜。3.3 后台启动与端口连通性验证确认前台能正常起来之后就可以切到后台模式让服务常驻。后台启动后需要用命令确认状态而不是凭感觉认为 start 过了就完了。三条命令一起执行可以避免“脚本说启动成功实际端口没监听”的假阳性./bin/mycat start ./bin/mycat status ss -lntp | grep 8066第一条是后台启动第二条查看进程状态输出里应该能看到运行中的标识第三条检查端口监听确认中间件确实占住了 8066。如果ss -lntp看不到监听很可能服务起了但没绑定成功按下文避坑章节的思路查。端口确认后用 MySQL 客户端连上去做最基础的连通性测试mysql -h127.0.0.1 -P8066 -uroot -p123456默认账号密码以发行说明为准Mycat 系列的传统默认值是 root/123456很多基础安装包沿用这套组合。连上后如果能进入 MySQL 命令行提示符基础安装包的使命就完成了一大半。如果报错先去 logs 目录翻 wrapper.log 的最后几十行。连接成功之后第一件事是执行SELECT VERSION();——如果返回的版本字符串和中间件版本一致说明你连的是中间件而不是物理 MySQL。这个动作虽然简单但能立刻排除“中间件没启动、客户端偷偷直连了物理库”这种乌龙场景。4. 把逻辑库接到物理库Mycat2 数据源配置与透传验证4.1 Mycat2 的配置哲学文件配置退居二线管理 SQL 做主这是从 Mycat1 迁移过来的用户最不适应的一点。Mycat1.x 把分片规则、数据源、库表关系都写在 XML 文件里改完要重启才生效。Mycat2 换了一套思路配置文件仍然存在但更核心的配置动作是通过连上中间件执行管理 SQL 来完成的。数据源、逻辑库、分片表这些对象都可以在运行时动态创建和修改不需要重启。对基础安装包的使用者来说这意味着两件事第一你不再需要打开一堆 XML 去手写路由规则第二你要适应“用 SQL 管理配置”的新习惯。Mycat2 把持久化机制做成黑匣子你只管发 SQL它负责把配置落到元数据里。我不建议去纠结持久化文件的具体格式因为它在不同小版本里变化过把时间花在熟悉管理 SQL 上更值。老用户最容易卡在“配置文件写在哪儿”这个问题上。Mycat2 的答案是一部分配置仍然在 yml 里另一部分通过 SQL 运行后持久化为元数据对象。具体哪些走文件、哪些走 SQL各版本有各自的分工。我后来养成的习惯是凡是数据源、逻辑库这类运行时对象都用管理 SQL凡是端口、JVM、日志级别这类进程级参数都看 yml。这样在基础安装包阶段不会走偏。4.2 添加数据源先用 SHOW 看现状再决定用哪种写法连上 8066 后先看一下当前有哪些数据源SHOW DATASOURCES;如果输出为空或只有系统内置数据源说明还没有任何真实物理库接入。接下来要做的是把一个真实 MySQL 实例注册成中间件的数据源。Mycat2 在这块的语法在不同小版本里有差异我整理两种常见写法你可以在自己的版本上试-- 写法一注解形式 /* mycat:createDatasource{ name:ds0, url:jdbc:mysql://127.0.0.1:3306/testdb, user:root, password:123456 } */-- 写法二自然 SQL 形式 CREATE DATASOURCE ds0 WITH jdbc:mysql://127.0.0.1:3306/testdb, root, 123456;第一种写法是 Mycat2 特有的注解 SQL把数据源参数写成 JSON 结构第二种更接近用户习惯的 SQL 语法。两种都可能在某个版本收到“语法不支持”的报错遇到这种情况不要慌用SHOW HELP在当前版本上确认支持的命令列表。管理 SQL 语法跟小版本绑定这是事实不是玄学。无论用哪种写法几个参数是通用的name是数据源在逻辑层的名字url要写 JDBC 连接串user和password是物理库的账号密码。连接串里的 3306 指向真实 MySQL可别把 IP 写成 127.0.0.1 却指向了中间件自己那会形成循环连接连接池会被慢慢耗尽。如果SHOW DATASOURCES看不到你想找的数据源也不要急着再建一次先执行SHOW HELP看当前版本支持的命令清单网上教程的语法很可能已经过时了。4.3 透传验证执行一条真实 SQL 并确认路由分发数据源注册成功之后还要建逻辑库和逻辑表才能让业务 SQL 走到物理库。最小验证方式是创建一个逻辑库再执行一条真实 SQL看结果是不是从物理库查回来的。基础安装包阶段我不建议立刻上复杂的自定义分片算法先把全局表建起来做透传验证。CREATE DATABASE testdb; CREATE TABLE testdb.t_user ( id bigint primary key, name varchar(64) ); USE testdb; SELECT COUNT(*) FROM t_user;全局表意味着每个分片节点都有一份完整数据中间件负责写扩散和读聚合。它和普通分片表的区别在于你不需要指定分片键逻辑最简单适合安装阶段验证数据源连通性。如果SELECT COUNT(*)报“表不存在”说明中间件没有把逻辑表映射到物理表需要检查数据源配置里的物理库名和逻辑库名是否一致。想确认 SQL 真的被路由到预期节点可以用 EXPLAIN 类命令看执行计划EXPLAIN SELECT COUNT(*) FROM t_user;输出会显示这个 SQL 被路由到了哪个数据节点、命中了哪些分片。透传验证通过后业务连接串就可以从原来的 3306 换成 8066基础安装包的接入工作基本完成。至于分片键选择、分片算法这些更高阶的内容那是下一步的事不应该在安装阶段盲目铺开。5. 安装启动避坑清单五个常见翻车现场与修复路径下面五条是我在帮人排查和自己在测试环境里反复踩过的坑。每一条都按现象、原因、解决三步拆开写。5.1 启动脚本报错JAVA_HOME 明明配了脚本还是找不到现象执行./bin/mycat start后终端直接提示找不到 JAVA_HOME 或找不到 java但 ssh 里echo $JAVA_HOME能打印出路径。原因环境变量虽然在当前会话可见但启动脚本如果是通过 su、sudo 或 systemd 方式调用的子进程环境里不一定继承了你手动 export 的变量。另一个常见原因是 JAVA_HOME 末尾带了/bin脚本再拼一次/bin/java实际去执行的是一个不存在的路径。解决把环境变量写进/etc/profile或~/.bash_profile并保证指向 JDK 根目录而不是 bin 子目录然后用source /etc/profile刷新。如果是 systemd 管理服务在 service 文件里显式声明EnvironmentJAVA_HOME...不要依赖全局 profile。5.2 status 显示运行中但 8066 端口就是连不上现象./bin/mycat status输出显示进程在跑ss -lntp | grep 8066却看不到监听端口MySQL 客户端连接直接超时。原因最多见的情况是端口绑定失败但进程没有退出。JVM 已经起来但 Socket 绑定报错后进入异常状态脚本的状态检查只看进程是否存活不看端口是否监听。其次是防火墙或云安全组拦截了 8066 入站本地连接没事远程连接一直卡住。解决先看logs/wrapper.log搜索 bind 或 IOException 关键字再用ss -lntp确认监听。如果绑定失败改端口后重启如果是防火墙问题在安全组放行 8066。用tail -f logs/wrapper.log实时跟踪比反复重启脚本高效得多。5.3 把 Mycat1 的 schema.xml 直接搬到 Mycat2现象老项目从 Mycat1 升级把原来的 schema.xml、rule.xml、server.xml 复制到 Mycat2 的 conf 目录重启后配置完全不生效或者启动直接报错。原因Mycat2 的配置模型不是 Mycat1 的延续是重构过的。Mycat2 以数据源、逻辑库、分片表等运行时对象为核心配置文件以 yml 形式存在XML 式的 schema 和 rule 在 Mycat2 里没有对应位置。直接复制文件等于把旧钥匙插进新锁芯当然打不开。解决不要迁移配置文件要迁移配置语义。把 Mycat1 里的 schema 表结构、分片规则翻译成 Mycat2 的数据源加逻辑库加建表语句通过管理 SQL 重建。这个翻译过程确实琐碎但它能逼你把旧配置里含糊不清的规则重新捋一遍改完反而更清楚自己的分片逻辑到底是怎么设计的。5.4 连接中间件用的是 8066却看到一堆物理库的库名现象mysql -h127.0.0.1 -P8066 ...连上去之后SHOW DATABASES能看到物理 MySQL 里所有的数据库误以为中间件只是透传。原因连接串虽然写的是 8066但如果你用的账号和配置恰好绕过了中间件的库级权限控制中间件会把你直接带到原型数据源或默认绑定库上展示物理库全貌。这不一定代表配置错误但确实容易被误读为“中间件没有生效”。解决用SHOW DATASOURCES确认当前连接落在哪个数据源上再USE到具体逻辑库去验证。如果确实希望限制可见库列表需要在逻辑库和数据源映射上做权限收敛而不是只在 MySQL 侧改账号权限两边要同时收紧。5.5 JVM 堆内存不足导致启动后频繁 OOM现象服务能启动业务量稍大就卡顿日志里大量出现 OutOfMemoryErrorGC 线程占用 CPU 高居不下。原因基础安装包默认堆内存设置是按“能跑起来”标准给的不是按业务压力给的。生产环境连接数一多分片路由和 SQL 解析都会吃掉堆空间默认值不够用。解决调启动脚本里的-Xms和-Xmx建议把两者设成相同的值避免 JVM 动态扩容带来的停顿同时给 Metaspace 留足配额。改完重启用jstat -gc pid观察 GC 频率确认调参后堆使用曲线是否平稳。注意不要一次把堆开得太离谱超过物理内存反而会频繁 swap性能更差。6. 安装之后先做这组自检我常用的四个验证点6.1 进程、日志、数据源、路由四步确认包可用安装完成后很多人习惯直接拿业务 SQL 来试连不上就怀疑安装包有问题。我更倾向于先做一组自检把“包是好的、数据源是通的、路由是对的”三个结论逐个坐实再让业务代码进场。第一步确认进程与监听端口。./bin/mycat status和ss -lntp | grep 8066两条命令返回正常并且logs/wrapper.log末尾没有 ERROR 级别日志。第二步用 MySQL 客户端连 8066执行下面两条管理 SQLSHOW DATASOURCES; EXPLAIN SELECT COUNT(*) FROM t_user;第一条确认数据源是 ONLINE 状态第二条确认业务表确实被路由到了预期节点而不是在一个空逻辑库上打转。第三步执行一条真实的查询 SQL核对返回的行数与直接连物理库时一致。第四步在中间件日志里搜索这条 SQL 的路由关键字确认它走了中间件解析链路而不是客户端直连。我现在每换一个环境装 Mycat2都会先跑这套自检再决定要不要把业务流量切过来。尤其是不熟悉的服务器前两步能过滤掉八成环境类问题后两步才是中间件本身工作是否正常的证明。希望这一套自检习惯也能帮到你。本文还有配套的精品资源点击获取