Mycat2基础安装包详解：从目录结构到多节点部署实战

简介：Mycat2基础安装包是一份面向数据库中间件学习者与运维部署人员的离线部署压缩包，用于在服务器上快速搭建Mycat2分布式数据库访问层，解决数据分片、读写分离与SQL路由等场景下的安装配置问题。包体共51个文件，压缩包大小仅1.2MB，涵盖核心配置、SQL初始化脚本、跨平台动态库（.so/.dll/.jnilib/.a）、JSON配置、启动脚本及JAR依赖等，可覆盖Linux、Windows、macOS多系统环境。目前已有1049人学习下载。搭建后用户可基于内置的9份SQL脚本及数据源等配置快速理解分片规则、连接池与全局序列的默认设定；目录按conf、sql、lib、bin模块划分，便于结合官方文档核对部署步骤并开展二次配置。借助这一安装包，刚接触Mycat2的开发者能以最小成本获得可运行实例，并进一步深入分库分表机制。 接手过几套数据库中间件，最后在这套基础安装包上花的时间最多。如果你手里正好拿到一份mycat2基础安装包，第一反应可能和我一样——“接下来干什么？”解压完，一堆配置文件，连个像样的说明都没有，属实劝退。但把目录结构、配置逻辑、启动方式理顺之后，你会发现它其实不复杂，而且把单节点跑通后，再扩展到多节点部署，整个数据库中间件那层就打通了。

这篇文章就围绕mycat2基础安装包，从目录结构、环境准备、核心配置，到多节点部署的完整链路，把能落地的步骤和踩过的坑一次性讲清楚。适合刚接触mycat2、准备在生产环境验证读写分离或分库分表方案的同学参考。

1. 拿到mycat2基础安装包，先认识目录结构

1.1 安装包是什么，为什么能“开箱即用”

mycat2是Java语言编写的数据库中间件，底层基于Java NIO实现，整体是绿色免安装形态。基础安装包解压后就是一个完整的可运行目录，不需要执行安装脚本，也不需要注册系统服务。只要机器上有对应版本的JDK，改完核心配置就能直接启动。

这一点和很多老牌中间件不一样——不是那种需要执行configure、make、make install三步走的源码包，也不是需要额外装依赖的rpm包。它把运行所需的jar包全部收在lib目录里，把配置模板放在conf目录里，启动脚本放在bin目录里。你拿到手的是“已经组装好的成品”，要做的只是告诉它“数据库在哪、逻辑库怎么映射、连接账号密码是多少”。

提示：我说的是“基础安装包”，不是源码包。如果你看到下载页面同时提供了源码包和安装包，生产环境请选择安装包，省去编译环节，减少不必要的麻烦。

1.2 解压后各目录的职责

解压之后，你会看到大概这样的结构：

mycat/ ├── bin/ │ ├── mycat │ ├── init_mycat2.sh │ ├── rehash.sh │ └── startup_nowait.sh ├── conf/ │ ├── server.json │ ├── user.json │ ├── datasource.json │ ├── schema.json │ ├── replica.json │ └── ... ├── lib/ │ ├── mycat2-xxx.jar │ ├── mysql-connector-java-xxx.jar │ └── ... ├── logs/ │ ├── mycat.log │ ├── wrapper.log │ └── ... └── version.txt

• bin目录：启动、停止、查看状态的脚本都在这里。日常用得最多的就是./mycat start、./mycat stop、./mycat status这三个命令。startup_nowait.sh用于快速启动场景，rehash.sh是处理SQL解析缓存刷新的，一般用不到。
• conf目录：这是整个安装包的核心，也可以说是“灵魂”。mycat2的配置和mycat1.x最大的区别是全面JSON化，不再是那一堆XML文件。server.json、user.json、datasource.json、schema.json、replica.json这五个文件各管一摊，把服务端口、连接账号、物理数据源、逻辑库表结构、读写分离集群关系全部拆开，互不干扰。这个设计让配置管理清爽很多，但也意味着你每次改动都要有清晰的目标——改哪个文件、影响哪一层，心里要有数。
• lib目录：存放mycat2主程序jar包和各类数据库驱动。里面自带mysql-connector-java，基本覆盖MySQL 5.7和MySQL 8.0。如果你要连其他数据库，比如PostgreSQL或者Oracle，需要把对应驱动jar包丢进这个目录再重启。
• logs目录：运行时日志输出目录。mycat.log记录核心运行日志，wrapper.log记录JVM启动和守护进程日志。排错时这两个文件就是第一手线索。
• version.txt：记录当前版本的版本号。看版本是否匹配环境，直接cat version.txt即可。

1.3 配置文件的“依赖关系”

这五个JSON配置文件不是孤立的，它们之间存在明确的引用关系。我画一张简单的逻辑关系图帮你理解（用文字描述）：

• server.json：定义mycat服务本身，比如监听端口8066、各模块开关、JVM相关参数引用。
• user.json：定义连接mycat时使用的用户名、密码、可访问的逻辑库、权限级别。
• datasource.json：定义真正连接后端MySQL实例的连接池信息，包含主机、端口、用户名、密码、最大连接数等。
• replica.json：定义读写分离集群，一个replica对应一组datasource，区分写库和读库。
• schema.json：定义逻辑库和逻辑表，把一张逻辑表映射到物理库的物理表，并指定分片规则或对应replica。

当你通过user.json里配置的账号连接mycat时，请求链路是这样的：客户端 → mycat（server层鉴权）→ schema找到逻辑库 → 判断SQL涉及哪张逻辑表 → 通过replica找到对应的datasource → 真正执行在物理MySQL上。理解这条链路，后面无论配置哪个文件，都不会再迷路。

2. 环境准备与单节点启动

2.1 基础环境清单

单节点启动前，先检查三样东西：JDK、MySQL客户端工具、端口占用情况。

• JDK版本：mycat2要求JDK 8及以上。建议直接用JDK 8的较新版本，比如8u202以上，这个组合在大多数生产环境里稳如老狗。用JDK 11也行，但实践中没觉得有额外收益，反而有个别驱动在某些JDK版本下出现奇怪问题。
• MySQL客户端：验证mycat服务是否正常，最直接的方式就是用mysql命令连接9066或8066端口。如果你本机没装mysql命令，用任意一个能走MySQL协议的GUI工具也行。
• 端口检查：mycat2默认服务端口是8066，管理端口是9066。启动前先确认这两个端口没被占用。Linux下可以用netstat -tlnp | grep -E '8066|9066'快速检查。

2.2 启动命令与日志观察

我的习惯是第一次启动用控制台模式，前台运行，日志直接打在终端上，能第一时间看到启动进度和报错。等确认配置无误，再改成后台守护进程模式。

控制台方式：

cd mycat ./bin/mycat console

看到类似Mycat Server startup successfully的日志说明启动成功。但生产环境没人会一直开着一个终端，所以确认无误后切回后台模式：

./bin/mycat start ./bin/mycat status

status返回mycat is running就代表进程活着。不过我提醒一句：进程活着不代表服务可用，一定要做一次真实的连接测试。我见过太多人说“启动成功了，但连不上8066”——原因多半是服务起来后自检某个配置失败，进程异常退出，或者端口被防火墙拦了。

2.3 首次连接测试

用MySQL客户端连接mycat，命令如下：

mysql -uroot -p123456 -h127.0.0.1 -P8066

这里root和123456是mycat的认证账号，不是后端MySQL的账号。mycat的认证账号在user.json里配置，和后端MySQL账号是两套体系。能连上并执行show databases;看到逻辑库列表，说明整个基础链路已经通了。

注意：如果连接时报Access denied for user，先检查user.json里的密码是否改过；如果密码没问题，再看用户是否对该逻辑库有访问权限。这两个点是最常见的“连不上”原因。

3. 核心配置文件的实战解读

3.1 server.json：服务层配置

server.json是mycat2服务的基础配置，定义了监听端口、I/O线程数、系统参数等。最小化配置里，最常改的就是端口和JVM参数。默认端口8066，如果和业务已有端口冲突，就改成8067或其他未占用端口。

{ "server": { "name": "mycat", "ip": "0.0.0.0", "port": 8066, "maxCon": 2048 }, "system": { "defaultSqlParser": "druid", "charset": "utf8mb4" } }

maxCon是mycat自身允许的最大客户端连接数，不是后端连接池的max。如果你预期连接数大，这里要提前调大，否则客户端会被拒之门外。

3.2 user.json：逻辑账号

user.json配置的是客户端连接mycat时的账号，它和后端MySQL账号完全解耦。一个典型的配置如下：

{ "users": [ { "username": "root", "password": "123456", "ip": "0.0.0.0", "transactionType": "xa", "maxCon": 100, "schemas": ["testdb"] } ] }

• username/password：客户端认证凭据。
• schemas：允许该用户访问的逻辑库列表。这个数组必须和schema.json里定义的逻辑库名保持一致，否则即使连上也没法操作。
• transactionType：事务类型，可选xa或proxy。跨多节点分布式事务用xa，单节点纯代理用proxy就够。如果只是读写分离，用proxy性能更好，因为少了XA的事务协调开销。

3.3 datasource.json：物理数据源

这是mycat和后端数据库之间的连接通道。一个datasource配置对应后端MySQL的一个实例。看下面的示例：

{ "datasources": [ { "name": "ds1", "dbType": "mysql", "dbDriver": "mysql-connector-java", "url": "jdbc:mysql://192.168.1.101:3306/testdb?useUnicode=true&characterEncoding=utf8mb4", "user": "mycat_user", "password": "mycat_pass", "maxCon": 100, "minCon": 10, "maxRetryCount": 3 } ] }

重点说两个容易踩坑的字段：

• dbDriver：默认是mysql-connector-java，对应lib目录下那个MySQL驱动。不要随意改成别的名字，驱动找不到会导致初始化失败。
• maxCon/minCon：就单个数据源而言，maxCon不是越大越好。如果多个replica指向同一个物理实例，每个数据源都是独立的连接池，这些连接数会叠加到后端MySQL上。后端MySQL的max_connections默认只有151，你在mycat侧把maxCon调到500，后端直接被压垮。刚开始跑，maxCon给50、minCon给5就够。

3.4 schema.json：逻辑库与逻辑表

schema.json负责把逻辑库映射到物理库。最简单的场景是全库映射，不管哪张表都落在同一个物理库上：

{ "schemas": [ { "schemaName": "testdb", "targetName": "prototype", "normalTables": {} } ] }

这里的targetName指向一个数据源或replica的名字。先别急着配分片——第一步把全库映射跑通，再逐步引入分片规则。一个常见误区是新手一上来就配置分片规则，结果分片字段、分片算法还没搞明白，SQL执行直接报错，最后连日志都不知道从哪里查起。

3.5 replica.json：读写分离集群

replica.json定义读写分离组。一个replica包含写库和读库，mycat会把写操作路由到writeHost，把读操作按负载均衡策略路由到readHost。

{ "replicas": [ { "name": "r1", "writeHost": { "name": "w1", "datasource": "ds1" }, "readHosts": [ { "name": "r1-1", "datasource": "ds2", "balance": "balance" } ] } ] }

这个配置的含义是：写库走ds1，读库走ds2。balance字段控制读写负载均衡策略，balance表示读写分离且读流量在多个读库间轮询。读写分离能不能生效，验证方法很简单——在写库和读库上分别执行show global status like 'Com_select'，然后连接mycat执行几条select，观察读库的Com_select计数增长，写库的不变，就说明路由对了。

4. 从单节点到多节点：mycat2部署多节点实战

4.1 为什么要部署多节点

基础安装包把单节点跑通只是第一步。生产环境只要QPS上来，单节点的瓶颈很快就会显现。mycat2本身是一个Java进程，不管你给它多少内存、多少CPU核心，单进程的处理能力总有上限。更关键的是，如果这个节点挂了，所有数据库访问全部瘫痪——这不叫高可用。

多节点部署的目标有两个：一是横向扩展吞吐量，二是实现高可用。多个mycat2节点同时对外提供服务，前面加一层负载均衡器分发流量，任何一台挂了，负载均衡器会自动把流量切到其他节点。对业务方来说，它始终访问一个虚拟入口，无感知后端变化。

4.2 多节点的架构选型

部署多节点时，前端负载均衡的方案通常有两种：

• Nginx（stream模块）：配置简单，性能好，团队普遍熟悉，适合中小规模部署。
• HAProxy：比Nginx更专注四层负载均衡，健康检查机制更丰富，适合对可用性要求更高的场景。

如果你刚起步，我建议先用Nginx stream模块，配置直观，排错也方便。HAProxy虽然专业，但多一层学习成本，而且在这个场景下优势并不悬殊。

无论选哪个，整体架构都是这样：客户端 → 负载均衡器（虚拟IP或域名） → 多台mycat2节点 → 后端MySQL集群。

4.3 多节点部署的实施步骤

第一步：准备节点机器

至少准备两台服务器，每台分别部署一份mycat2基础安装包。两台的JDK版本、mycat版本尽量保持一致，避免因版本差异导致的SQL路由行为不一致。

第二步：保证配置一致性

这是多节点部署中最微妙的一环。所有mycat2节点必须使用完全相同的配置，否则同一个SQL在不同节点上的路由结果可能不同。我的做法是：先把第一台机器的conf目录完整配置好，验证通过后，用scp把整个conf目录同步到其他节点，而不是一台一台手改。手改必然会出现“这台改漏了一个字段、那台多了一个空格”的问题。

scp -r /opt/mycat/conf/* root@192.168.1.12:/opt/mycat/conf/

同步完配置后，所有节点重启一次，确保配置全部加载生效。

第三步：逐个启动并验证

每台节点都执行：

./bin/mycat start ./bin/mycat status mysql -umycat_user -pmycat_pass -h127.0.0.1 -P8066 -e "select 1"

这里强调一下，逐个节点验证非常重要。有些问题只有在某个节点上才会暴露，比如内存较小导致JVM启动失败、端口被其他进程占用等。不要假设“第一台没问题，其他台肯定也没问题”。

第四步：配置负载均衡

Nginx侧配置一个TCP层的stream负载均衡：

stream { upstream mycat_backend { server 192.168.1.10:8066 max_fails=2 fail_timeout=10s; server 192.168.1.11:8066 max_fails=2 fail_timeout=10s; } server { listen 8066; proxy_pass mycat_backend; proxy_connect_timeout 5s; proxy_timeout 30s; } }

这段配置的作用是：客户端连负载均衡器的8066端口，Nginx把TCP流量轮流转发到后端两台mycat节点的8066端口。某台节点连续两次连接失败后，会被暂时移出可用列表，10秒后再尝试恢复。

配置完成后重载Nginx：

nginx -t nginx -s reload

第五步：通过负载均衡入口做全链路验证

此时客户端只需要连接负载均衡器的IP和端口，不需要关心后端到底有几台mycat。全链路验证建议分三步走：

1. 连接负载均衡入口，执行select 1，确认链路通。
2. 执行一次建表、插入、查询操作，确认读写路由正常。
3. 停掉其中一台mycat节点，再次执行操作，确认请求可以自动切换到存活节点。

第三步特别重要，高可用到底高不高可用，不是看配置，而是看故障状态下业务是否无感。

4.4 多节点部署必须注意的“隐藏坑”

多节点部署有几个问题，单节点时永远不会遇到，但一旦上多节点就成了拦路虎：

配置漂移。这是多节点部署最大的敌人。某天你在节点A上临时改了一个参数，忘记同步到节点B，一段时间后，两个节点的行为就开始分叉。要解决这个问题，配置文件的变更必须有一个统一发布通道，比如每次改动后强制用脚本同步，或者直接把conf目录纳入版本管理。

全局序列号一致性。如果你的分片表使用全局序列号生成主键，不同的mycat2节点必须使用同一个序列发生成器的配置，否则会出现主键冲突。mycat2的全局序列号支持数据库方式、文件方式、时间戳方式，多节点部署时推荐用数据库方式，它天然支持多实例协同。

后端连接数放大效应。每个mycat节点都会维护自己的连接池。假设你部署了2个节点，每个节点对后端MySQL配置了50个最大连接，那后端MySQL就要承受100个连接。多节点数量越多，连接数放大越明显。部署前一定要核算后端MySQL的max_connections，给连接池的maxCon留出足够的余量。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

我在部署和排障过程中，整理了一份高频问题清单，直接对照排查：

5.2 我踩过的最深的坑：驱动不匹配

有一次部署到一台新机器，mycat2能正常启动，客户端也能连接，但执行任何一条SQL都直接报驱动错误。查了很久，最后发现问题出在lib目录下的MySQL驱动jar包版本太老，不支持后端MySQL 8.0的caching_sha2_password认证插件。

我当时的处理方案是：从MySQL官网下载对应版本的mysql-connector-java，替换lib目录下的旧驱动，然后重启mycat2。这之后一切正常。

经验：如果你的后端MySQL是8.0版本，建议提前确认lib目录自带的驱动是否支持。最简单的验证方式是看驱动的release note，或直接换一个较新的mysql-connector-j版本。这个坑在mycat1.x时代也存在，属于“中间件连MySQL 8.0”的经典问题。

5.3 排查日志的技巧

mycat2的日志是排错的第一现场。我的经验是，遇到问题时按以下顺序看：

• wrapper.log：看JVM是否正常启动，有没有OutOfMemoryError、ClassNotFoundException这类基础错误。
• mycat.log：看SQL执行链路，里面会记录每一条SQL走了哪个数据源、路由结果是什么，以及具体的异常堆栈。
• 后端MySQL的general_log：当mycat日志显示正常、但数据不对时，开启MySQL的general_log确认SQL是否真正到了指定节点，以及节点返回了什么错误。

很多时候，问题不在mycat本身，而在后端数据库账号权限、网络连通性、SQL语法兼容性。用日志把问题边界框定住，再逐一排查，效率最高，也不会在无关的方向上浪费时间。

最后再分享一点心得

如果让我给刚接触mycat2基础安装包的人一个建议，我会说：不要一上来就奔着多节点部署去。先在单节点上把配置文件之间的引用关系彻底吃透，特别是schema.json和datasource.json的对应关系。单节点的链路理清楚了，多节点无非就是配置复制加一个负载均衡层，难度会降一个量级。我当初多节点部署折腾最久的，恰恰不是负载均衡本身，而是两台节点配置不一致导致的路由行为分叉。所以每改一次配置，多花一分钟做同步校验，后面能省下好几个小时的排障时间。这套基础安装包本身不复杂，复杂的是你如何理解并掌控它。

本文还有配套的精品资源，点击获取