简介这份资源是 MyCat 2 的安装模板压缩包版本为 1.21面向需要快速搭建分布式数据库中间件的 Java 开发者与运维人员。MyCat 2 作为开源数据库分片工具可实现数据分片、读写分离与 SQL 路由而该模板将部署所需的配置与脚本预先整理好降低了初学者的上手门槛。压缩包共 52 个文件约 1.19MB以 sql 初始化脚本、json 配置、各平台 wrapper 动态库so、dll、jnilib、a 等以及 xml、properties、bat 启动脚本为主覆盖 Linux、Windows、macOS、AIX 等多系统运行环境。conf 目录下包含 schemas、clusters、datasources、users 等配置模块lib 目录提供 wrapper.jar 与各平台本地库bin 目录则放置 mycat 与 mycat.bat 启停入口。目前已有 640 人学习下载适合希望快速验证 MyCat 2 分片方案、对照配置文件理解 server.json 与 schema 结构的读者参考使用。1. 从 mycat2-install-template-1.21.zip 说起为什么离线部署总在模板这一步翻车手里拿到mycat2-install-template-1.21.zip的人多半不是来研究分布式数据库中间件概念的而是被一个很具体的问题卡住了内网环境没有外网、依赖拉不下来、官方脚本跑一半报错最后只能靠一个离线模板包把 mycat2 跑起来。这个 zip 本质上是把 mycat2 的运行骨架、启动脚本、配置目录和依赖 jar 预先打好的一个安装模板解压之后按目录约定放好改几个配置就能起进程。它解决的不是mycat2 是什么而是在不能联网的机器上怎么让 mycat2 第一次成功启动。适合读这篇的人有三类一是要在隔离网络里搭读写分离或分库分表中间件的运维二是本地想快速验证 mycat2 行为、不想被 Maven 拉包折磨的后端三是已经解压了模板但启动就报错、不知道从哪查的开发者。下面按模板里到底有什么 → 怎么改配置 → 怎么启动验证 → 坑在哪的顺序讲命令和参数都能直接抄。2. 拆开 install-template目录结构、依赖和它替你省掉的活先把模板包解压到目标路径别急着启动先看清楚它给了什么。mycat2 的安装模板通常是一个自包含的目录树核心是bin、conf、lib三块加上一个启动入口脚本。理解这三块的分工后面改配置才不会改错地方。2.1 解压后先确认三件事目录、JDK、启动脚本# 假设包放在 /opt/soft解压到 /opt/mycat2 mkdir -p /opt/mycat2 unzip mycat2-install-template-1.21.zip -d /opt/mycat2 cd /opt/mycat2 # 看目录层级确认是不是多套了一层 ls -la # 确认 JDK 版本mycat2 对 JDK 有硬要求 java -version解压后第一件要确认的是目录层级。很多模板包解压后会多出一层同名目录比如/opt/mycat2/mycat2-install-template-1.21/...如果你直接把bin路径写死成/opt/mycat2/bin启动脚本就会找不到主类和配置。第二件是 JDKmycat2 基于较新的 Java 运行时java -version输出如果是 1.8 早期小版本启动阶段就可能抛UnsupportedClassVersionError。第三件是启动脚本本身bin下一般有start、stop、restart这类脚本先cat一下看它引用的MYCAT_HOME是怎么算的。# 看启动脚本怎么定位家目录和主类 cat bin/start.sh 2/dev/null || cat bin/mycat # 确认 lib 下依赖是否齐全 ls lib | head -30 ls lib | wc -llib目录是模板包最值钱的部分。联网安装时这些 jar 由构建工具从仓库拉取离线模板则把它们全部预置好。你要做的是确认数量对得上、没有明显缺失而不是去逐个研究每个 jar。常见做法是看lib里有没有 mycat 自身的核心包、连接池、日志实现这几类缺了日志实现会在启动时静默失败只留一个空日志文件这种黑匣子式故障最耗时间。2.2 配置目录里真正要动的只有几个文件conf目录下文件不少但第一次跑通只需要关心三类服务自身配置、数据源配置、以及日志配置。其余的分片规则、序列号配置可以等基础连通后再补。配置类别典型文件第一次必改作用服务配置server 相关配置文件是端口、字符集、线程数数据源数据源/集群配置文件是后端真实库地址与账号日志日志配置文件建议日志级别与输出路径分片规则规则类配置文件否分库分表逻辑后置序列号序列配置文件否全局 ID 生成后置第一次部署的原则是最小可用只配一个后端数据源只开一个逻辑库先把进程拉起来、能连上、能转发一条 SQL再去加分片。很多人一上来就把分片规则全配好结果启动失败时分不清是数据源问题还是规则问题排查成本翻倍。2.3 数据源配置把后端真实库接进来数据源配置决定了 mycat2 把 SQL 转发给谁。下面是一个单数据源的最小配置示例字段名以你模板里的实际文件为准重点是理解每个参数的含义。# 数据源配置示例字段名请对照模板内实际文件 datasource: name: ds0 # 数据源逻辑名后面逻辑库要引用 url: jdbc:mysql://127.0.0.1:3306/demo_db?useSSLfalseserverTimezoneAsia/Shanghai user: demo_user # 后端库账号不是 mycat 自己的账号 password: demo_pass maxPoolSize: 20 # 连接池上限按后端库承受能力设 minPoolSize: 2 # 常驻连接太小会有冷启动延迟 connectionTimeout: 3000 # 毫秒网络差的环境适当放大url里的serverTimezone必须显式指定否则在部分 JDK 与驱动组合下会报时区解析异常表现为连接测试直接失败。maxPoolSize不要一上来就设几百mycat2 作为中间件会放大连接数后端库的连接上限才是真正的瓶颈。connectionTimeout设太小在网络抖动时会把本可重试的连接直接判死建议不低于 3000 毫秒。2.4 逻辑库与账号让客户端连的是 mycat 而不是后端库数据源配好后还要告诉 mycat2 对外暴露哪个逻辑库、用什么账号登录。这一步是把后端物理库映射成客户端看到的逻辑库。# 逻辑库与用户示例 schema: name: logic_db # 客户端连接时写的库名 dataSource: ds0 # 引用上面的数据源逻辑名 user: name: app_user # 客户端登录 mycat 用的账号 password: app_pass schema: logic_db # 该账号可见的逻辑库这里最容易混的是两套账号app_user是客户端连 mycat2 用的demo_user是 mycat2 连后端库用的两者可以不同权限也应当分开。把后端库的高权限账号直接暴露给客户端是很多事故的起点。配完后用客户端工具连logic_db能连上说明账号和逻辑库映射没问题连不上先查 mycat 日志里的鉴权记录。3. 启动、验证与最小可用链路从进程起来到 SQL 转发成功配置改完进入启动和验证阶段。这一步的目标不是看到进程在而是确认一条 SQL 真的被转发到后端并返回了正确结果。进程在但转发不通等于没部署成功。3.1 启动命令与日志观察点# 进入安装目录用模板自带脚本启动 cd /opt/mycat2 # 前台启动便于看日志生产再改后台 bash bin/start.sh # 另开一个终端跟踪日志 tail -f logs/mycat.log启动脚本一般会做几件事检查MYCAT_HOME、拼装 classpath、指定主类、传 JVM 参数。前台启动的好处是异常直接打在终端不用去日志里翻。观察日志时重点看三类信息JVM 启动参数是否合理、数据源初始化是否成功、监听端口是否绑定成功。如果日志停在初始化数据源就不动了多半是后端库连不上或驱动缺失。# 确认端口监听 ss -lntp | grep -E 8066|9066 # 8066 通常是数据端口9066 通常是管理端口mycat2 一般有两个端口一个对外提供数据服务一个用于管理命令。两个都监听成功才说明服务完整起来了。只起了一个检查配置里对应端口是否被注释或写错。3.2 用管理端口做连通性自检管理端口是排查问题的第一入口很多状态不用连业务库就能看到。# 连管理端口执行状态类命令 mysql -h127.0.0.1 -P9066 -uapp_user -papp_pass # 进入后查看数据源状态 show datasource; # 查看逻辑库 show schemas;show datasource返回的状态能直接告诉你后端库通不通。如果显示连接失败回到数据源配置检查url、账号、网络白名单。这一步比直接连业务端口试 SQL 更快定位问题因为管理命令不经过完整的 SQL 解析链路。3.3 跑通第一条转发 SQL-- 连数据端口走逻辑库 -- mysql -h127.0.0.1 -P8066 -uapp_user -papp_pass logic_db SELECT 1; -- 再查一张后端真实存在的表 SELECT COUNT(*) FROM demo_table;SELECT 1成功只说明 mycat 自身活着不代表转发链路通。真正有意义的是查一张后端库里的真实表返回的行数和直接连后端库查出来一致才算转发成功。如果SELECT 1通、查真实表报表不存在说明逻辑库到物理库的映射或默认数据源没配对。3.4 参数怎么调三个影响稳定性的关键项参数作用建议起点调大/调小的后果连接池上限控制到后端库的并发连接20过大压垮后端库过小高并发排队连接超时建连等待上限3000ms过小误判抖动过大故障感知慢线程数处理客户端请求的并发度按 CPU 核数×2过大上下文切换开销高这三个参数没有万能值取决于后端库能力和业务并发。我的习惯是先按保守值上线用管理端口观察连接数和慢查询再逐步放大而不是一次配到理论最大值。4. 避坑与排查install-template 部署里最常见的五类翻车这一章按现象 → 原因 → 解决写都是离线模板部署里反复出现的具体问题不是泛泛而谈。现象一启动脚本报找不到主类或 classpath 为空。原因通常是解压多了一层目录MYCAT_HOME指向了错误层级脚本拼出来的lib路径不存在。解决是先ls确认bin、lib、conf是否在同一层把安装目录调整到正确层级或在脚本里显式修正家目录变量。现象二进程起来了但日志里数据源一直初始化失败。原因多为后端库地址写成了localhost而实际库在另一台机器或账号没有从 mycat 所在主机登录的权限。解决是用mysql -h后端IP -u账号 -p从 mycat 主机直接验证连通性再检查后端库的账号授权主机范围。现象三客户端能连上但执行 SQL 报时区或字符集异常。原因是 JDBC URL 缺少serverTimezone或客户端、mycat、后端库三者的字符集不一致。解决是在数据源 URL 显式指定时区并统一三端字符集为同一编码避免中文乱码和排序异常。现象四高并发下大量连接超时但后端库负载并不高。原因是连接池上限设得过大mycat 把连接数放大后打满了后端库的连接上限或者连接超时设得过小导致正常建连被误杀。解决是下调连接池上限、放大连接超时并用管理端口观察实际连接占用。现象五改了配置重启不生效。原因是模板里存在多份同名或备份配置文件启动时加载的不是你改的那份。解决是启动前确认实际加载路径清理或明确备份文件命名避免配置改了但没被读。注意离线模板部署时任何改了没生效的问题先怀疑加载路径再怀疑配置内容这个顺序能省掉大量无效排查。5. 进阶把模板变成可复用部署单元的几个技巧第一次跑通只是起点真正省时间的是把mycat2-install-template-1.21.zip这套东西沉淀成可复制的部署单元。我一般会做三件事。第一件是配置外置。不要把改好的配置留在解压目录里而是抽到一个独立的配置目录启动时通过参数或环境变量指定。这样升级模板包时配置不会被覆盖回滚也只需换回旧配置目录。# 启动时指定外部配置目录的思路 export MYCAT_CONF_DIR/etc/mycat2/conf bash bin/start.sh第二件是启动前自检脚本化。把JDK 版本、目录层级、端口占用、后端库连通这几项写成一个检查脚本每次部署先跑一遍把问题挡在启动之前。#!/usr/bin/env bash # 部署前自检任一项失败即退出 set -e java -version 21 | grep -q version || { echo JDK 异常; exit 1; } [ -d lib ] || { echo lib 目录缺失; exit 1; } ss -lntp | grep -q :8066 { echo 端口已被占用; exit 1; } echo 自检通过第三件是验证脚本固定化。每次部署后用同一组 SQL 验证转发链路而不是靠记忆临时敲。把SELECT 1、查真实表、查管理端口状态这三步固定下来部署质量就有了统一标准。-- 固定验证集部署后必跑 SELECT 1; SELECT COUNT(*) FROM demo_table; -- 管理端口show datasource; show schemas;最后说个我自己的习惯每次动配置前先备份整个conf目录命名带上时间戳。离线环境里没有后悔药一次误改可能让整个中间件起不来而备份只要几秒钟。这套模板包的价值不在于它多复杂而在于它把能跑起来这件事变得可复制剩下的就是把它变成你自己的标准动作。希望帮到你。本文还有配套的精品资源点击获取