
简介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-develUbuntu用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/逻辑库名?useSSLfalseserverTimezoneAsia/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?useSSLfalse 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) ) ENGINEInnoDB; 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?useSSLfalse username: root password: yourpassword readHost: url: jdbc:mysql://192.168.1.11:3306/mysql?useSSLfalse 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地址而是对外暴露一个虚拟IPVIP后面挂多个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.logJVM启动日志。遇到问题时先看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协议去探活。有了这一层多节点里的每个节点才真正算得上“可自愈”。本文还有配套的精品资源点击获取