简介：mycat2基础安装包定位为开源数据库中间件Mycat第二版的轻量部署套件，面向需要搭建分布式数据库访问层的开发与运维人员。包内提供了服务端核心jar包、schema.xml/server.xml等配置模板、SQL初始化脚本，以及支持Linux、Windows、macOS等平台的wrapper启动与动态链接库文件。通过解压并配合Java环境，即可在本地或服务器上启动一个Mycat2实例，用于实践数据分片、读写分离与SQL路由等核心功能。整个资源仅51个文件、1.2MB，非常精简，适合快速实验或在已有项目中嵌入集成。截止目前已有1049人学习下载，对于希望以最小成本体验Mycat2的初学者来说，是一份实用且易上手的入门工具包。 Mycat2折腾了一下午，总算把基础环境理清楚了。网上关于Mycat2的教程确实不少，但大多是照着文档念一遍，真正到了部署这一步，哪些配置是必须的、哪些可以后面再改、哪些组合会导致启动失败，说清楚的真不多。尤其是如果你和我一样，目标是先把基础安装包跑起来，后面还要往多节点扩展，那前期的安装方式选择和目录规划就更重要了。
这篇文章我就把从零部署Mycat2的过程完整拆开讲，重点放在版本选型、目录结构、核心配置和启动验证上，最后再聊一下为多节点部署需要提前做好的准备。适合第一次接触Mycat2、想快速搭一个能跑能用的环境、又不想在文档里大海捞针的同学。
1. 版本选型与运行环境，这些搭配最容易出问题
Mycat2和很多人印象里的Mycat1.x在配置方式上差别非常大。1.x时代是XML配置为主，2.0全面转向了SQL管理和文件配置结合的方案。很多老教程还在用1.6的思维教你改server.xml，放到2.x上根本对不上，这是新手最容易被误导的地方。
目前Mycat2的稳定发布版本其实迭代得不算快，社区活跃度也比前几年低了一些，但作为学习分库分表中间件、或者中小规模业务做读写分离和垂直分片，它依然是个能打的选择。我这里用的是1.6.1.5这个版本，它对应的是mycat2-release标签下的安装包，也是目前比较多人验证过的组合。
先看环境要求，这个真的很关键：
硬件方面：内存建议至少4G。Mycat2本身是Java应用，启动后JVM加上连接池、SQL解析引擎的开销，2G内存跑起来勉强，但如果你同时还要在本机跑MySQL实例，很容易把内存吃满。我本地是8G内存的机器，开了一个Mycat2加两个MySQL实例（一个主库一个从库），整体还算宽裕。
JDK版本：Mycat2要求JDK8以上，实测JDK8和JDK11都能正常跑。这里有个小坑，如果你用的是JDK17，某些版本可能会遇到反射相关的警告甚至报错，建议稳妥起见用JDK8，网上绝大多数的部署案例也都是基于JDK8验证的。
MySQL兼容性：Mycat2作为数据库中间件，前端连接的是你的业务应用，后端连接的是真实MySQL实例。它对MySQL 5.7和8.0都支持，但要注意8.0默认的认证插件是caching_sha2_password，老版本的Mycat驱动可能不兼容。解决方法是把MySQL用户的认证插件改成mysql_native_password，或者在Mycat连接后端数据库的账号配置上做适配。这个问题在验证读写分离的时候特别容易暴露，后面细说。
这里我要特别提醒一下：如果之前装过Mycat1.x，建议把两个版本彻底分开。它们不仅配置格式不同，目录结构也有差异，混在一起很容易造成文件混淆。我最早就是在一台已经装过Mycat1.6的机器上直接解压Mycat2，结果看日志看了半天才发现是加载了旧的配置文件。
2. 部署方式对比与基础安装，Docker和二进制包我都试过了
Mycat2的部署方式主要有两种：Docker镜像和二进制压缩包。这两种我都实际跑过，说下亲身体验。
Docker方式：优点是上手快，一条命令就能拉起容器，适合快速体验功能。缺点是容器里的配置修改不够直观，尤其是你要改分片规则、调整连接池参数时，得进容器或者挂载配置文件，对后面多节点部署来说，多了一层镜像分发的成本。另外官方Docker镜像的更新和维护情况也要留意，镜像版本和release包版本可能会存在滞后。
二进制包方式：这也是我最终采用的方式。下载tar.gz压缩包解压即用，所有配置文件都在本地目录里，改起来直接，排查问题也能直接看文件，对于后面做多节点扩展和配置同步来说更顺手。
官方下载地址可以从Mycat2的GitHub仓库的Release页面找到，文件名一般是mycat2-1.6.x-release-xxx-linux.tar.gz。注意区分官方release和第三方打包的版本，优先选择官方发布的。
下面是具体安装步骤，我以CentOS 7/8或Ubuntu 20.04这类Linux环境为例。
第一步，确认Java环境：
java -version如果没装JDK8，先装上。CentOS可以用yum install java-1.8.0-openjdk-devel，Ubuntu用apt install openjdk-8-jdk。装完验证一下，确保默认java命令指向的是JDK8。
第二步，创建独立用户（强烈建议）：
不要直接用root跑Mycat2。虽然能跑起来，但后续管理文件权限、配置多节点互访时会有麻烦。我的习惯是单独建一个用户：
useradd -m -s /bin/bash mycat第三步，解压安装包：
mkdir -p /opt/mycat cd /opt/mycat tar -zxvf mycat2-1.6.1.5-release-linux.tar.gz -C /opt/mycat chown -R mycat:mycat /opt/mycat解压后目录结构是这样的，我强烈建议你花两分钟把每个目录的作用搞清楚，这会让你后面排错快很多：
| 目录/文件 | 作用 |
|---|---|
| bin/ | 启动脚本，startup.sh是主入口 |
| conf/ | 所有配置文件所在目录，最关键的地方 |
| lib/ | 依赖的jar包，一般不用动 |
| logs/ | 运行日志，排查问题第一个要看这里 |
| mycat.yml | 主配置文件，相当于Mycat2的全局配置 |
| cluster.yml | 集群相关配置，多节点部署时核心文件 |
| prototype/ | MySQL服务器原型配置目录 |
| catalog/ | 逻辑库、逻辑表和分片规则配置目录 |
注意，1.6.x版本的配置目录结构和更早的1.6.0、1.6.1有一些差别。旧版本里prototype和catalog下的配置可能分散在多个子目录，新版本做了整合。所以你在网上看到的教程，如果别人的目录和你不一样，先看版本。
第四步，启动前的环境检查：
启动前要先确认一件事：Mycat2启动时会连接配置里指定的MySQL服务器原型（prototype），如果连不上，启动会失败或者报错。所以要么先把prototype的配置改成你实际的MySQL地址，要么确保本机有一个可用的MySQL实例。
这一点非常关键。我遇到不少人在启动Mycat2时直接报连接超时，就是因为没注意Mycat2本身并不强制要求后端MySQL在启动时就可用，但它的启动脚本会尝试加载prototype配置，如果长时间连不上，状态检查就会异常。
第五步，启动：
cd /opt/mycat bin/startup.sh启动后看logs目录下的wrapper.log和mycat.log，正常启动会看到类似“Mycat Server startup successfully”的日志。
第六步，验证进程和端口：
ps -ef | grep mycat netstat -tlnp | grep 8066Mycat2默认的代理端口是8066，管理端口是9066。如果8066端口在监听，说明基础服务已经起来了。
3. 配置文件逐项拆解，搞懂它才算真正装完
Mycat2的配置核心在conf目录下的mycat.yml，这个文件替代了旧版的server.xml。打开后你会看到一堆配置项，不要慌，我挑必须理解的几个讲清楚。
先看最基础的一段，boootstrap配置：
boootstrap: # 加载配置的方式，local表示本地文件，相当于旧的server.xml loadFile: local user: username: root password: 123456这里定义的user就是你业务应用连接Mycat2时用的账号密码，不是后端MySQL的账号。前端连接串长这样：
jdbc:mysql://mycat主机IP:8066/逻辑库名?useSSL=false&serverTimezone=Asia/Shanghai注意这个“逻辑库名”，它不等于物理库名。Mycat2中逻辑库的概念来自catalog配置，对应真实MySQL里的物理库。也就是说，你在业务代码里连接的数据库名，是Mycat2给你抽象出来的虚拟库，真正落库的时候，数据会被路由到不同的物理节点上。
再看prototype配置。mycat.yml里会有protoType相关的配置段，它定义了Mycat2默认连接后端MySQL的方式。简单理解，prototype就是Mycat2的“默认数据库路由模板”，你新建的每一个逻辑库，默认都会映射到prototype指定的物理MySQL上。所以prototype的targets配置要指向你真实的MySQL实例地址：
prototype: targets: prototype: url: jdbc:mysql://127.0.0.1:3306/mysql?useSSL=false username: root password: yourpassword maxCon: 10 minCon: 1这里的url、username、password是Mycat2连接后端MySQL用的连接信息。MaxCon是最大连接数，minCon是最小连接数。这里我要多说一句，连接池的初始大小和上限要根据实际并发调整，默认值在测试环境够用，生产环境如果并发量高，maxCon设太小会导致连接等待和超时。
然后是catalog配置，它决定了逻辑库长什么样。在conf/catalog目录下，每一个逻辑库对应一个配置文件，比如你要创建一个叫testdb的逻辑库，在catalog目录下就有个testdb.schema.json文件。打开后会看到类似这样的内容：
{ "schemaName": "testdb", "targetName": "prototype", "normalTables": {}, "shardingTables": {}, "globalTables": {} }这里的schemaName是逻辑库名，targetName指向后端的物理MySQL原型，normalTables是普通表（不参与分片），shardingTables是分片表（涉及分库分表规则），globalTables是全局表（所有分片节点都冗余一份）。这些概念在Mycat2里非常重要，理解不了它们，配置分片规则会一头雾水。
再补充一个容易踩坑的点：Mycat2默认开启了数据库保护模式。什么意思呢？就是在没有配置任何分片规则和可通过审核的SQL情况下，它是拒绝执行一些危险操作的，比如不带where条件的delete、update。这是为了安全考虑，但本地测试时你可能会觉得烦。如果需要关闭，可以在mycat.yml里找到相关配置，把保护模式的enabled改为false。具体键名不同版本略有差异，你可以在配置文件里搜“protect”或“firewall”关键字。
最后是cluster.yml。单节点部署时，这个文件里的配置基本保持默认就行，但你要知道它是为多节点准备的。多节点部署时，每个节点需要配置集群名称、节点ID、组员信息，节点之间会同步配置和状态。后面专门讲多节点时再展开。
4. 分片与读写分离实测，验证配置到底生效没有
基础配置搞定后，我建议你做一个最小化的功能验证，确保Mycat2不只是“启动了”，而是真的能代理SQL请求。这里我们做两件事：一是验证最基本的查询能通，二是验证读写分离的走向。
这一步非常重要。很多教程到“启动成功”就结束了，但实际使用中，Mycat2的很多问题都是在真实SQL请求下才暴露出来的。
验证一：基本查询通路
用MySQL客户端直接连Mycat2的8066端口：
mysql -h127.0.0.1 -P8066 -uroot -p123456连上后先看逻辑库：
SHOW DATABASES;如果能看到你配置的逻辑库（比如testdb），说明前端连接正常。继续执行：
USE testdb; CREATE TABLE test_user ( id BIGINT PRIMARY KEY, name VARCHAR(64) ) ENGINE=InnoDB; INSERT INTO test_user (id, name) VALUES (1, 'zhangsan'); SELECT * FROM test_user;如果这些操作都能成功，说明Mycat2已经成功把逻辑库testdb映射到了后端MySQL的物理库上，SQL也能正常路由执行。
验证二：读写分离走向
读写分离是Mycat2最常用的核心功能之一。要在Mycat2中配置读写分离，你需要在prototype或catalog的targets里定义多个后端数据源，并指定写源和读源。配置的大致思路是：定义一个读写组，组里面先列出写库（writeHost），再列出读库（readHost）。
例如，在后端MySQL实例中，有一个主库（192.168.1.10:3306）和一个从库（192.168.1.11:3306），在Mycat2的targets配置里可以这样组织：
targets: prototype: writeHost: url: jdbc:mysql://192.168.1.10:3306/mysql?useSSL=false username: root password: yourpassword readHost: url: jdbc:mysql://192.168.1.11:3306/mysql?useSSL=false username: root password: yourpassword balance: 0这里要特别注意balance参数，它决定了读写分离的负载均衡策略。Mycat2里整数型balance的取值代表不同的均衡级别，我简单归纳：
| balance值 | 作用 |
|---|---|
| 0 | 不启用读写分离，所有请求都走写库 |
| 1 | 启用读写分离，读请求在多个读库间轮询 |
| 2 | 读请求在主从库间随机分发，兼顾读多写少场景 |
| 3 | 读请求只在读库间随机分发，主库不承担读压力 |
我第一次配置时就因为balance保持默认的0，结果发现查询日志全走了写库，读写分离根本没生效。这里要提醒你，配置完之后一定要实测观察一下。
怎么观察呢？在主库和从库上分别执行：
SHOW STATUS LIKE 'Com_select';查看两边的SELECT计数。在Mycat2上跑几条SELECT语句，然后对比两边Com_select的增长情况。如果主库增长了，从库没变化，说明balance配置有问题或者没生效。更直观的方法是看Mycat2的SQL日志，日志里会记录SQL路由到了哪个数据源。
还有一个我经常用的验证技巧：在从库中手动创建一个只在从库存在的表，然后通过Mycat2执行对该表的查询。如果能查出来，说明读请求确实路由到了从库；如果报“表不存在”之类的错误，那很可能读请求压根没有走从库。这个方法在测试环境非常高效，比看日志直观得多。
读写分离配置到这里，其实还有一个重要的前置条件：后端MySQL的主从复制必须正常运行。如果主从同步本来就断了，读写分离配置得再好，从库查到的也是旧数据。所以在做读写分离验证前，先确保主从复制状态是正常的，这个环节很多人忽略，出了数据不一致的问题又回头怀疑Mycat，其实中间件本身没问题。
5. 多节点部署前的规划，以及三节点同步的实操经验
热搜词里提到“mycat2部署多节点”，这意味着很多人在单机跑通之后，还想往前一步，把Mycat2从单点变成集群。我个人的建议是：如果你的业务对中间件的可用性有要求（比如生产环境），多节点是必须的，因为单机Mycat2一挂，所有走中间件的业务全部瘫痪。但如果还处于学习阶段，我更建议先把单机的分片读写分离吃透，再去搞集群，不然环境一复杂，出了问题都不知道该从哪里排查。
真正的多节点部署，核心不是把Mycat2装到多台机器上，而是解决三个问题：配置一致、状态同步、流量入口统一。
第一，配置一致。Mycat2的配置文件（mycat.yml、cluster.yml、catalog下的分片规则）在集群中所有节点上必须保持一致，否则同一个SQL在不同的Mycat节点会路由到不同的物理库，这是绝对不能接受的。我的经验是在基础安装包跑通后，把conf目录整体作为基线版本，放到Git里管理，然后所有节点从Git拉取同一份配置。不要手动在每台机器上改配置，人工同步迟早出错。
第二，状态同步。Mycat2的多节点集群模式中，节点之间会通过cluster.yml里配置的组播或单播地址进行通信，同步元数据和配置变更。这里要注意网络环境是否支持组播，如果不支持，要配置为单播模式，也就是在cluster.yml中显式列出集群中所有节点的IP和端口。这个细节很关键，我见过因为组播不通导致节点间一直处于“disconnected”状态的案例。
第三，流量入口统一。多节点的目的不是让应用连多个Mycat地址，而是对外暴露一个虚拟IP（VIP），后面挂多个Mycat节点。当某个Mycat节点挂了，VIP自动漂移到另一台存活节点上，应用无感知。这是标准的高可用架构，需要用keepalived或者云厂商的负载均衡器实现。
以一个三节点Mycat集群为例，架构大概是这样：
- 3台机器，各自部署一份完全相同的Mycat2（版本一致、配置一致）。
- 3个Mycat节点通过cluster.yml互相发现，组成一个集群。
- 对外提供1个VIP，比如192.168.1.100，通过keepalived把这3台机器关联起来。
- 应用连接串里只需要写jdbc:mysql://192.168.1.100:8066，不需要关心后端具体是哪台机器在提供服务。
keepalived的配置比较简单，核心是定义一个VRRP实例，把3个节点绑定到同一个虚拟路由器上，设置不同的优先级。正常时优先级最高的节点持有VIP；它挂了，其他节点通过心跳发现主节点失联，优先级次之的节点接管VIP。这个过程对Mycat2本身来说是无感的，因为Mycat2节点之间本来就在跑集群同步，所以即使某个节点突然掉线，只要另一个节点还在，VIP漂移过去后，业务连接就能继续走。
这里我要多讲一个我踩过的坑。当时我部署了两台Mycat2，配置是从同一份拷贝过去的，启动后节点之间也能互相ping通，但业务请求时好时坏。排查了很久发现，问题出在Mycat2内部的“元数据刷新”上。Mycat2的catalog配置变更后，不是即时对所有节点生效的，节点之间通过集群同步元数据需要一个时间窗口。如果你在节点A上新建了一个逻辑库，立刻去节点B查询，有可能会报逻辑库不存在。解决方法是：所有配置变更都通过Mycat2的管理端口或者集群命令来执行，让它自己同步，不要直接改文件后重启单个节点。直接改文件的方式会把集群中的元数据搞乱，导致节点之间状态不一致。
另外，多节点部署还有一个容易忽略的问题：Mycat2的状态实际上有一部分存在后端MySQL中。Mycat2的配置管理用的是一套内部机制，它会在prototype指向的MySQL中维护一些元数据表。这意味着如果你的所有Mycat节点指向的是同一个prototype MySQL，那么元数据天然就是共享的；如果prototype指向了不同MySQL，那就会各自为政，集群形同虚设。多节点部署时一定要确认所有节点的prototype配置指向同一个后端MySQL（或同一套MySQL集群）。
6. 从基础包到生产环境，我的几点使用心得
安装包能跑通只是第一步，真正把Mycat2用起来，有几个习惯我觉得值得养成。
日志是你最好的朋友。Mycat2的日志目录logs下，有mycat.log（主日志）和wrapper.log（JVM启动日志）。遇到问题时，先看wrapper.log有没有异常堆栈，再看mycat.log里的SQL路由信息。很多看似玄学的问题（比如连接被拒、超时、路由错误），日志里都写得明明白白。养成先看日志再动手的习惯，能省掉大量瞎猜的时间。
版本升级要慎重。Mycat2的不同小版本之间，配置文件和SQL管理语句可能有细微差别。如果你已经用1.6.1.x跑了一段时间，升级前一定要看官方Release Notes，重点关注配置变更和不兼容项。我一般会在测试环境先把升级流程走一遍，确认分片规则和读写分离都正常，再动生产。
新版本踩过坑后，我对Mycat2的态度是这样的：它是一个学习分库分表中间件原理的好工具，也是一个中小型项目快速落地读写分离和垂直分片的选择。但它毕竟不像一些商业中间件那样有完善的技术支持和长期保障，使用前要做足风险预案，比如后端MySQL本身的主从高可用要完备，Mycat节点的健康检查和VIP漂移要提前演练，这些基础工作做到位了，Mycat2才能在一套可靠的体系里发挥价值。
最后再分享一个小技巧，是我在部署多节点时摸索出来的：把Mycat2的启动脚本做成systemd服务，而不是裸用startup.sh。这样即使Mycat进程异常退出，systemd也能自动帮你拉起，节点的可用性会高很多。systemd服务文件也很简单，核心就是定义ExecStart和ExecStop，指定运行用户和WorkingDirectory，再把启动后的健康检查做成一个脚本，通过HTTP或MySQL协议去探活。有了这一层，多节点里的每个节点才真正算得上“可自愈”。
本文还有配套的精品资源，点击获取
