简介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.txtbin目录启动、停止、查看状态的脚本都在这里。日常用得最多的就是./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时请求链路是这样的客户端 → mycatserver层鉴权→ 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 statusstatus返回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?useUnicodetruecharacterEncodingutf8mb4, 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 多节点的架构选型部署多节点时前端负载均衡的方案通常有两种Nginxstream模块配置简单性能好团队普遍熟悉适合中小规模部署。HAProxy比Nginx更专注四层负载均衡健康检查机制更丰富适合对可用性要求更高的场景。如果你刚起步我建议先用Nginx stream模块配置直观排错也方便。HAProxy虽然专业但多一层学习成本而且在这个场景下优势并不悬殊。无论选哪个整体架构都是这样客户端 → 负载均衡器虚拟IP或域名 → 多台mycat2节点 → 后端MySQL集群。4.3 多节点部署的实施步骤第一步准备节点机器至少准备两台服务器每台分别部署一份mycat2基础安装包。两台的JDK版本、mycat版本尽量保持一致避免因版本差异导致的SQL路由行为不一致。第二步保证配置一致性这是多节点部署中最微妙的一环。所有mycat2节点必须使用完全相同的配置否则同一个SQL在不同节点上的路由结果可能不同。我的做法是先把第一台机器的conf目录完整配置好验证通过后用scp把整个conf目录同步到其他节点而不是一台一台手改。手改必然会出现“这台改漏了一个字段、那台多了一个空格”的问题。scp -r /opt/mycat/conf/* root192.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_fails2 fail_timeout10s; server 192.168.1.11:8066 max_fails2 fail_timeout10s; } server { listen 8066; proxy_pass mycat_backend; proxy_connect_timeout 5s; proxy_timeout 30s; } }这段配置的作用是客户端连负载均衡器的8066端口Nginx把TCP流量轮流转发到后端两台mycat节点的8066端口。某台节点连续两次连接失败后会被暂时移出可用列表10秒后再尝试恢复。配置完成后重载Nginxnginx -t nginx -s reload第五步通过负载均衡入口做全链路验证此时客户端只需要连接负载均衡器的IP和端口不需要关心后端到底有几台mycat。全链路验证建议分三步走连接负载均衡入口执行select 1确认链路通。执行一次建表、插入、查询操作确认读写路由正常。停掉其中一台mycat节点再次执行操作确认请求可以自动切换到存活节点。第三步特别重要高可用到底高不高可用不是看配置而是看故障状态下业务是否无感。4.4 多节点部署必须注意的“隐藏坑”多节点部署有几个问题单节点时永远不会遇到但一旦上多节点就成了拦路虎配置漂移。这是多节点部署最大的敌人。某天你在节点A上临时改了一个参数忘记同步到节点B一段时间后两个节点的行为就开始分叉。要解决这个问题配置文件的变更必须有一个统一发布通道比如每次改动后强制用脚本同步或者直接把conf目录纳入版本管理。全局序列号一致性。如果你的分片表使用全局序列号生成主键不同的mycat2节点必须使用同一个序列发生成器的配置否则会出现主键冲突。mycat2的全局序列号支持数据库方式、文件方式、时间戳方式多节点部署时推荐用数据库方式它天然支持多实例协同。后端连接数放大效应。每个mycat节点都会维护自己的连接池。假设你部署了2个节点每个节点对后端MySQL配置了50个最大连接那后端MySQL就要承受100个连接。多节点数量越多连接数放大越明显。部署前一定要核算后端MySQL的max_connections给连接池的maxCon留出足够的余量。5. 常见问题与排查技巧实录5.1 高频问题速查表我在部署和排障过程中整理了一份高频问题清单直接对照排查问题现象可能原因排查方向status显示未运行JDK版本不符或端口被占用查看logs/wrapper.log确认JDK版本检查8066/9066端口连接被拒用户配置错误或逻辑库名不匹配检查user.json中schemas字段和schema.json逻辑库名是否一致连接后执行SQL报“无效数据源”schema.json的targetName指向错误确认targetName对应datasource或replica名称是否存在所有SQL都报超时后端MySQL连接失败用datasource中的url和账号直连MySQL确认网络和账号权限启动成功但连接无响应9066管理端口被防火墙拦截检查管理端口连通性确认iptables/安全组放行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的对应关系。单节点的链路理清楚了多节点无非就是配置复制加一个负载均衡层难度会降一个量级。我当初多节点部署折腾最久的恰恰不是负载均衡本身而是两台节点配置不一致导致的路由行为分叉。所以每改一次配置多花一分钟做同步校验后面能省下好几个小时的排障时间。这套基础安装包本身不复杂复杂的是你如何理解并掌控它。本文还有配套的精品资源点击获取
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.txtbin目录启动、停止、查看状态的脚本都在这里。日常用得最多的就是./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时请求链路是这样的客户端 → mycatserver层鉴权→ 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 statusstatus返回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?useUnicodetruecharacterEncodingutf8mb4, 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 多节点的架构选型部署多节点时前端负载均衡的方案通常有两种Nginxstream模块配置简单性能好团队普遍熟悉适合中小规模部署。HAProxy比Nginx更专注四层负载均衡健康检查机制更丰富适合对可用性要求更高的场景。如果你刚起步我建议先用Nginx stream模块配置直观排错也方便。HAProxy虽然专业但多一层学习成本而且在这个场景下优势并不悬殊。无论选哪个整体架构都是这样客户端 → 负载均衡器虚拟IP或域名 → 多台mycat2节点 → 后端MySQL集群。4.3 多节点部署的实施步骤第一步准备节点机器至少准备两台服务器每台分别部署一份mycat2基础安装包。两台的JDK版本、mycat版本尽量保持一致避免因版本差异导致的SQL路由行为不一致。第二步保证配置一致性这是多节点部署中最微妙的一环。所有mycat2节点必须使用完全相同的配置否则同一个SQL在不同节点上的路由结果可能不同。我的做法是先把第一台机器的conf目录完整配置好验证通过后用scp把整个conf目录同步到其他节点而不是一台一台手改。手改必然会出现“这台改漏了一个字段、那台多了一个空格”的问题。scp -r /opt/mycat/conf/* root192.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_fails2 fail_timeout10s; server 192.168.1.11:8066 max_fails2 fail_timeout10s; } server { listen 8066; proxy_pass mycat_backend; proxy_connect_timeout 5s; proxy_timeout 30s; } }这段配置的作用是客户端连负载均衡器的8066端口Nginx把TCP流量轮流转发到后端两台mycat节点的8066端口。某台节点连续两次连接失败后会被暂时移出可用列表10秒后再尝试恢复。配置完成后重载Nginxnginx -t nginx -s reload第五步通过负载均衡入口做全链路验证此时客户端只需要连接负载均衡器的IP和端口不需要关心后端到底有几台mycat。全链路验证建议分三步走连接负载均衡入口执行select 1确认链路通。执行一次建表、插入、查询操作确认读写路由正常。停掉其中一台mycat节点再次执行操作确认请求可以自动切换到存活节点。第三步特别重要高可用到底高不高可用不是看配置而是看故障状态下业务是否无感。4.4 多节点部署必须注意的“隐藏坑”多节点部署有几个问题单节点时永远不会遇到但一旦上多节点就成了拦路虎配置漂移。这是多节点部署最大的敌人。某天你在节点A上临时改了一个参数忘记同步到节点B一段时间后两个节点的行为就开始分叉。要解决这个问题配置文件的变更必须有一个统一发布通道比如每次改动后强制用脚本同步或者直接把conf目录纳入版本管理。全局序列号一致性。如果你的分片表使用全局序列号生成主键不同的mycat2节点必须使用同一个序列发生成器的配置否则会出现主键冲突。mycat2的全局序列号支持数据库方式、文件方式、时间戳方式多节点部署时推荐用数据库方式它天然支持多实例协同。后端连接数放大效应。每个mycat节点都会维护自己的连接池。假设你部署了2个节点每个节点对后端MySQL配置了50个最大连接那后端MySQL就要承受100个连接。多节点数量越多连接数放大越明显。部署前一定要核算后端MySQL的max_connections给连接池的maxCon留出足够的余量。5. 常见问题与排查技巧实录5.1 高频问题速查表我在部署和排障过程中整理了一份高频问题清单直接对照排查问题现象可能原因排查方向status显示未运行JDK版本不符或端口被占用查看logs/wrapper.log确认JDK版本检查8066/9066端口连接被拒用户配置错误或逻辑库名不匹配检查user.json中schemas字段和schema.json逻辑库名是否一致连接后执行SQL报“无效数据源”schema.json的targetName指向错误确认targetName对应datasource或replica名称是否存在所有SQL都报超时后端MySQL连接失败用datasource中的url和账号直连MySQL确认网络和账号权限启动成功但连接无响应9066管理端口被防火墙拦截检查管理端口连通性确认iptables/安全组放行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的对应关系。单节点的链路理清楚了多节点无非就是配置复制加一个负载均衡层难度会降一个量级。我当初多节点部署折腾最久的恰恰不是负载均衡本身而是两台节点配置不一致导致的路由行为分叉。所以每改一次配置多花一分钟做同步校验后面能省下好几个小时的排障时间。这套基础安装包本身不复杂复杂的是你如何理解并掌控它。本文还有配套的精品资源点击获取