把分库分表这个词放到技术社区里一搜你会发现两拨完全不同的声音一拨人把ShardingSphere当成数据库的万能解药库表还没拆就先想着怎么螺旋升天另一拨人恰恰相反被跨库事务和分布式ID折磨过之后逢人就劝退。我自己的态度一直没变过——分库分表不是为了炫技而是当单库真的撑不住的时候最可控的一条出路。这篇文章我准备用一个接近真实业务的例子把ShardingSphere从选型到落地、从分库分表到读写分离的完整链路捋一遍。适合两类人看一类是数据量已经到了千万级、每天被慢查询和锁等待折磨的后端开发另一类是虽然项目还在早期但想提前把数据架构的基本盘打好的架构师。全程用ShardingSphere 5.x配置以Spring Boot JDBC模式为主该说清楚原理的地方我尽量说透该给配置的地方直接贴可用的YAML坑也会单独拉出来讲。1. 先聊明白你的业务到底需不需要分库分表很多人一上来就把分库分表挂在嘴边但真实情况是大部分系统连单库的优化都没做完。我见过最典型的场景一张订单表3000万行索引建得不差但业务方每天都在凌晨跑全量统计把CPU吃满白天接口跟着遭殃。这种问题靠分库分表是解决不了的它属于计算与存储没有分层的问题应该先去考虑汇总表、离线数仓或分析型数据库。所以第一步不是配置ShardingSphere而是先做一场业务体检。对照下面这几种情况判断一下单表数据量超过5000万行并且持续增长即使加了索引带分页和排序的查询仍然频繁超时单库写入TPS长期高于3000主库的binlog同步和磁盘IO已经吃紧你已经在靠归档表、冷热分离来维持核心表的体积但归档逻辑越来越难维护团队对再买一台更高的机器已经没有预期因为单机配置已经堆到很高。上面任何一条踩中那么分库分表才是一个值得考虑的方向。而读写分离则更多是读多写少的典型场景一个订单系统80%以上的请求在查询主库明明压力不大但从库可以分流大量的报表、详情和后台查询。需要注意的是读写分离和分库分表是两个正交的能力你可以只做读写分离也可以先做分库分表再叠加读写分离优先级上我更建议先把分库分表的路由规则搞定再考虑从库分流因为分片之后的主从结构天然会变得更复杂。说回选择了ShardingSphere之后的预期管理。一个拆成4库12表的订单系统如果连表查询都带着分片键读写性能会有明显提升但如果后台运营想根据用户名、时间范围裸查全库这类查询会路由到所有分片然后归并性能反而不如单库。这不是中间件的问题而是分布式查询的代价。你得在架构设计上承认这一点并给运营、报表类查询单独规划通道。2. ShardingSphere的架构与选型JDBC模式还是Proxy模式ShardingSphere的前身是Sharding-JDBC很多人从1.x开始就在用了。现在它是Apache顶级项目能力也早就超出了分库分表本身读写分离、数据加密、影子库、分布式事务等模块都包含在内。理解这一点对于选型很重要因为你后面可能不只是想要分片能力还想要一个能统一处理数据安全、流量治理的方案。当前主要两种接入形态。JDBC模式相当于一个增强版的DataSource嵌入在你的应用进程里。应用拿到的连接就是ShardingSphere包装过的逻辑连接SQL发出去之后由它解析、路由、改写、归并。对业务代码几乎零侵入Spring Boot项目引入依赖、写配置即可。额外开销多发生在SQL解析和连接路由这一层整体性能损耗可控。它只支持Java因为JVM内运行的原理决定了它天然和Java生态深度绑定。Proxy模式一个独立部署的代理服务对外兼容MySQL或PostgreSQL协议。你的应用不用做任何代码改动把连接地址改成代理地址就行多语言客户端比如PHP、Go也能直接使用。代价是多一层网络转发延迟比JDBC模式略高而且运维上要单独维护Proxy集群的高可用。总结成一个对比表格方便决策对比项JDBC模式Proxy模式部署形态应用内嵌跟随服务部署独立进程需单独维护代码侵入低换数据源即可几乎为零改连接地址即可性能损耗较低无网络转发略高多一跳语言限制仅Java支持MySQL/PostgreSQL协议的所有客户端运维成本低不需要额外集群中高需考虑Proxy自身高可用适合场景Java微服务团队、对延迟敏感的业务多语言团队、不想改动应用的存量系统如果你问我的建议Java技术栈、业务又在快速发展期我一般推荐JDBC模式。原因很直接它和Spring Boot的集成最顺出错时可以直接在应用日志里看到路由结果排障心智负担小。Proxy适合那种客户端语言很杂、或者DBA团队想统一管控数据访问的场景但你需要额外搭一套基础设施。另外提醒一句5.x版本对Java版本是有要求的基于Java 8或Java 11的项目用起来最稳。3. 环境准备与依赖引入从零搭建一个可运行的工程我假设你已经有一组MySQL实例至少两个库用于分片演示比如order_db_0和order_db_1每个库里预先建好三张结构完全相同的订单表。表结构我就不贴完整建表语句了核心字段包括id、order_id、user_id、amount、status、create_time几个索引按order_id建唯一索引按user_id建普通索引。Maven项目引入下面这些依赖dependency groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-jdbc-core-spring-boot-starter/artifactId version5.3.2/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId version8.0.33/version /dependency版本号你按自己的Spring Boot版本调整5.3.x对Java 8和Spring Boot 2.x兼容性很好如果项目已经在Spring Boot 3建议用更新的5.4.x或以上。我见过一些老项目Starter版本和Spring Boot版本脱节启动时报一堆DataSource初始化错误那种问题查起来特别耗时。接下来是最小可运行的分库分表配置。我先把读写分离放一边只保留分库分表这样拆开讲更容易理解spring: shardingsphere: mode: type: Standalone repository: type: File props: path: .sharding/ datasource: names: ds0, ds1 ds0: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://127.0.0.1:3306/order_db_0 username: root password: root ds1: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://127.0.0.1:3306/order_db_1 username: root password: root rules: sharding: tables: t_order: actual-data-nodes: ds$-{0..1}.t_order_$-{0..2} key-generate-strategy: column: id key-generator-name: snowflake database-strategy: standard: sharding-column: order_id sharding-algorithm-name: db-hash table-strategy: standard: sharding-column: order_id sharding-algorithm-name: table-hash binding-tables: - t_order, t_order_item sharding-algorithms: db-hash: type: HASH_MOD props: sharding-count: 2 table-hash: type: HASH_MOD props: sharding-count: 3 key-generators: snowflake: type: SNOWFLAKE props: worker-id: 1 props: sql-show: true看着长但拆开就是三块datasource告诉中间件真实数据源有哪些rules定义分片规则props是全局参数。其中sql-show: true强烈建议在测试环境打开它会在日志里打印每一次SQL的路由结果比如Actual SQL: ds1 ::: select * from t_order_1这个信息在你验证分片策略是否正确时是排查利器能直接确认一条查询到底打到了哪个库哪张表。启动工程后不要急着写业务代码先写一个插入订单的接口和按order_id查询的接口发几个请求观察日志。你会看到插入时id字段被自动填上了雪花IDorder_id是业务传入的订单号查询时SQL被路由到正确的分片。这里有个关键点ShardingSphere不会替你自动建表它只负责路由。表结构必须提前在每个真实库中建好数据库连接的用户也需要有对应的读写权限。不少人第一次跑通报表不存在基本都是忘记了这一步。4. 分库分表核心规则配置拆解表、绑定表与分片算法实际项目里分库分表的配置不会只有一张表所以理解每个配置项背后的意图比照抄配置更重要。分片键的选择是所有设计的前提。我用order_id做分片键而不是数据库自增主键原因很现实业务上我们几乎所有的查询都是根据订单号查详情、根据订单号查关联明细订单号天然适合作为路由依据。如果按id分片那么按order_id查询时ShardingSphere不知道去哪找数据只能全库扫描性能无法接受。分片键一定是从高频查询条件里选出来的这一点要刻在脑子里。库策略和表策略是两个独立的路由决策。数据库层决定这条SQL进ds0还是ds1表层面决定进t_order_0还是t_order_2。两者可以使用相同或不同的分片键数量也可以不同。比如我这里是2库3表order_id经过db-hash算法得到0或1决定库经过table-hash算法得到0、1、2决定表。最终一个订单会落在6种组合中的某一个整体数据分布是均匀的。这里不要用2库3表正好等于6张物理表的思路去反推算法它们各自取模组合就是6种。分片算法不是越多越好选对才是核心。ShardingSphere自带不少算法最常见的三个需要理解它们的边界算法类型支持SQL类型特点MOD等值查询、IN数值直接取模分布均匀但对字符串分片键支持不好HASH_MOD等值查询、IN先哈希再取模对字符串和数值都友好最常用INLINE等值查询、IN基于行表达式写法直观但字符串分片键需要配置分区键和表达式容易出错我项目里默认优先HASH_MOD因为订单号的形态可能是雪花ID的大整数也可能是带业务前缀的字符串HASH_MOD能统一处理。范围查询比如create_time between是分片算法的天然短板没有哪个取模算法能优雅支持范围路由这类查询最终都会走全分片扫描。如果业务确实有强范围查询需求可以考虑INTERVAL时间分片那是另一个话题一般放在日志流水、交易流水这类数据上更合适。绑定表是JOIN性能的关键。配置里我写了t_order, t_order_item。这两张表是主表和明细表的关系它们的父子关系都用order_id关联。配置绑定表之后ShardingSphere在路由时会确保父表和子表进了同一个分片——也就是说一个订单的主记录和明细记录永远在同一个库的同一张关联物理表里。这样JOIN查询不需要跨库、跨表归并而是退化成普通的物理表JOIN。这个配置看起来不起眼但对带明细查询的订单系统来说性能差距可以达到一个数量级。绑定表的核心约束是关联字段必须是分片键否则下推逻辑会失效。分布式主键的生成方式值得多花一分钟。ShardingSphere默认内置了SNOWFLAKE算法来生成主键它会根据worker-id做机器区分。真实生产环境里每个应用实例都要配置不同的worker-id否则不同实例可能生成相同的主键这一条非常重要。如果你的服务超过1024个实例或者对ID生成有更高的可控要求建议提前换成号段模式比如美团的Leaf思路ShardingSphere支持通过自定义KeyGenerator接入这类方案。这个后面踩坑环节我再细说。还有一条必须强调不带分片键的SQL默认是全路由。比如select * from t_order where user_id ?因为user_id不是分片键ShardingSphere会在所有分片执行同样的查询再把结果归并起来。这条SQL在数据量大了之后一定慢因为它是物理上六倍的查询开销。合理做法是给这类查询单独设计一个路由索引表比如user_id到order_id的映射表或者直接把它送进分析库不让它在在线链路上裸奔。5. 读写分离配置与实践主从延迟问题的处理思路读写分离的前提是MySQL主从复制已经正常。这里不展开主从搭建的细节只强调两个基础设施层面的点一是binlog格式建议用ROW因为分片环境下多个库的结构一致性要求较高二是从库的复制延迟要有监控ShardingSphere只负责流量分发不会替你解决主从延迟本身。读写分离的配置逻辑也很清楚把主库和从库组合成一个逻辑数据源写入路由到主读取路由到从。还是用order场景举例假设现在有两个分片库order_db_0和order_db_1每个分片下面各有一主一从配置如下spring: shardingsphere: datasource: names: ds0, ds0_replica, ds1, ds1_replica ds0: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://127.0.0.1:3306/order_db_0 username: root password: root ds0_replica: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://127.0.0.1:3307/order_db_0 username: root password: root ds1: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://127.0.0.1:3306/order_db_1 username: root password: root ds1_replica: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://127.0.0.1:3307/order_db_1 username: root password: root rules: readwrite-splitting: >
把分库分表这个词放到技术社区里一搜你会发现两拨完全不同的声音一拨人把ShardingSphere当成数据库的万能解药库表还没拆就先想着怎么螺旋升天另一拨人恰恰相反被跨库事务和分布式ID折磨过之后逢人就劝退。我自己的态度一直没变过——分库分表不是为了炫技而是当单库真的撑不住的时候最可控的一条出路。这篇文章我准备用一个接近真实业务的例子把ShardingSphere从选型到落地、从分库分表到读写分离的完整链路捋一遍。适合两类人看一类是数据量已经到了千万级、每天被慢查询和锁等待折磨的后端开发另一类是虽然项目还在早期但想提前把数据架构的基本盘打好的架构师。全程用ShardingSphere 5.x配置以Spring Boot JDBC模式为主该说清楚原理的地方我尽量说透该给配置的地方直接贴可用的YAML坑也会单独拉出来讲。1. 先聊明白你的业务到底需不需要分库分表很多人一上来就把分库分表挂在嘴边但真实情况是大部分系统连单库的优化都没做完。我见过最典型的场景一张订单表3000万行索引建得不差但业务方每天都在凌晨跑全量统计把CPU吃满白天接口跟着遭殃。这种问题靠分库分表是解决不了的它属于计算与存储没有分层的问题应该先去考虑汇总表、离线数仓或分析型数据库。所以第一步不是配置ShardingSphere而是先做一场业务体检。对照下面这几种情况判断一下单表数据量超过5000万行并且持续增长即使加了索引带分页和排序的查询仍然频繁超时单库写入TPS长期高于3000主库的binlog同步和磁盘IO已经吃紧你已经在靠归档表、冷热分离来维持核心表的体积但归档逻辑越来越难维护团队对再买一台更高的机器已经没有预期因为单机配置已经堆到很高。上面任何一条踩中那么分库分表才是一个值得考虑的方向。而读写分离则更多是读多写少的典型场景一个订单系统80%以上的请求在查询主库明明压力不大但从库可以分流大量的报表、详情和后台查询。需要注意的是读写分离和分库分表是两个正交的能力你可以只做读写分离也可以先做分库分表再叠加读写分离优先级上我更建议先把分库分表的路由规则搞定再考虑从库分流因为分片之后的主从结构天然会变得更复杂。说回选择了ShardingSphere之后的预期管理。一个拆成4库12表的订单系统如果连表查询都带着分片键读写性能会有明显提升但如果后台运营想根据用户名、时间范围裸查全库这类查询会路由到所有分片然后归并性能反而不如单库。这不是中间件的问题而是分布式查询的代价。你得在架构设计上承认这一点并给运营、报表类查询单独规划通道。2. ShardingSphere的架构与选型JDBC模式还是Proxy模式ShardingSphere的前身是Sharding-JDBC很多人从1.x开始就在用了。现在它是Apache顶级项目能力也早就超出了分库分表本身读写分离、数据加密、影子库、分布式事务等模块都包含在内。理解这一点对于选型很重要因为你后面可能不只是想要分片能力还想要一个能统一处理数据安全、流量治理的方案。当前主要两种接入形态。JDBC模式相当于一个增强版的DataSource嵌入在你的应用进程里。应用拿到的连接就是ShardingSphere包装过的逻辑连接SQL发出去之后由它解析、路由、改写、归并。对业务代码几乎零侵入Spring Boot项目引入依赖、写配置即可。额外开销多发生在SQL解析和连接路由这一层整体性能损耗可控。它只支持Java因为JVM内运行的原理决定了它天然和Java生态深度绑定。Proxy模式一个独立部署的代理服务对外兼容MySQL或PostgreSQL协议。你的应用不用做任何代码改动把连接地址改成代理地址就行多语言客户端比如PHP、Go也能直接使用。代价是多一层网络转发延迟比JDBC模式略高而且运维上要单独维护Proxy集群的高可用。总结成一个对比表格方便决策对比项JDBC模式Proxy模式部署形态应用内嵌跟随服务部署独立进程需单独维护代码侵入低换数据源即可几乎为零改连接地址即可性能损耗较低无网络转发略高多一跳语言限制仅Java支持MySQL/PostgreSQL协议的所有客户端运维成本低不需要额外集群中高需考虑Proxy自身高可用适合场景Java微服务团队、对延迟敏感的业务多语言团队、不想改动应用的存量系统如果你问我的建议Java技术栈、业务又在快速发展期我一般推荐JDBC模式。原因很直接它和Spring Boot的集成最顺出错时可以直接在应用日志里看到路由结果排障心智负担小。Proxy适合那种客户端语言很杂、或者DBA团队想统一管控数据访问的场景但你需要额外搭一套基础设施。另外提醒一句5.x版本对Java版本是有要求的基于Java 8或Java 11的项目用起来最稳。3. 环境准备与依赖引入从零搭建一个可运行的工程我假设你已经有一组MySQL实例至少两个库用于分片演示比如order_db_0和order_db_1每个库里预先建好三张结构完全相同的订单表。表结构我就不贴完整建表语句了核心字段包括id、order_id、user_id、amount、status、create_time几个索引按order_id建唯一索引按user_id建普通索引。Maven项目引入下面这些依赖dependency groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-jdbc-core-spring-boot-starter/artifactId version5.3.2/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId version8.0.33/version /dependency版本号你按自己的Spring Boot版本调整5.3.x对Java 8和Spring Boot 2.x兼容性很好如果项目已经在Spring Boot 3建议用更新的5.4.x或以上。我见过一些老项目Starter版本和Spring Boot版本脱节启动时报一堆DataSource初始化错误那种问题查起来特别耗时。接下来是最小可运行的分库分表配置。我先把读写分离放一边只保留分库分表这样拆开讲更容易理解spring: shardingsphere: mode: type: Standalone repository: type: File props: path: .sharding/ datasource: names: ds0, ds1 ds0: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://127.0.0.1:3306/order_db_0 username: root password: root ds1: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://127.0.0.1:3306/order_db_1 username: root password: root rules: sharding: tables: t_order: actual-data-nodes: ds$-{0..1}.t_order_$-{0..2} key-generate-strategy: column: id key-generator-name: snowflake database-strategy: standard: sharding-column: order_id sharding-algorithm-name: db-hash table-strategy: standard: sharding-column: order_id sharding-algorithm-name: table-hash binding-tables: - t_order, t_order_item sharding-algorithms: db-hash: type: HASH_MOD props: sharding-count: 2 table-hash: type: HASH_MOD props: sharding-count: 3 key-generators: snowflake: type: SNOWFLAKE props: worker-id: 1 props: sql-show: true看着长但拆开就是三块datasource告诉中间件真实数据源有哪些rules定义分片规则props是全局参数。其中sql-show: true强烈建议在测试环境打开它会在日志里打印每一次SQL的路由结果比如Actual SQL: ds1 ::: select * from t_order_1这个信息在你验证分片策略是否正确时是排查利器能直接确认一条查询到底打到了哪个库哪张表。启动工程后不要急着写业务代码先写一个插入订单的接口和按order_id查询的接口发几个请求观察日志。你会看到插入时id字段被自动填上了雪花IDorder_id是业务传入的订单号查询时SQL被路由到正确的分片。这里有个关键点ShardingSphere不会替你自动建表它只负责路由。表结构必须提前在每个真实库中建好数据库连接的用户也需要有对应的读写权限。不少人第一次跑通报表不存在基本都是忘记了这一步。4. 分库分表核心规则配置拆解表、绑定表与分片算法实际项目里分库分表的配置不会只有一张表所以理解每个配置项背后的意图比照抄配置更重要。分片键的选择是所有设计的前提。我用order_id做分片键而不是数据库自增主键原因很现实业务上我们几乎所有的查询都是根据订单号查详情、根据订单号查关联明细订单号天然适合作为路由依据。如果按id分片那么按order_id查询时ShardingSphere不知道去哪找数据只能全库扫描性能无法接受。分片键一定是从高频查询条件里选出来的这一点要刻在脑子里。库策略和表策略是两个独立的路由决策。数据库层决定这条SQL进ds0还是ds1表层面决定进t_order_0还是t_order_2。两者可以使用相同或不同的分片键数量也可以不同。比如我这里是2库3表order_id经过db-hash算法得到0或1决定库经过table-hash算法得到0、1、2决定表。最终一个订单会落在6种组合中的某一个整体数据分布是均匀的。这里不要用2库3表正好等于6张物理表的思路去反推算法它们各自取模组合就是6种。分片算法不是越多越好选对才是核心。ShardingSphere自带不少算法最常见的三个需要理解它们的边界算法类型支持SQL类型特点MOD等值查询、IN数值直接取模分布均匀但对字符串分片键支持不好HASH_MOD等值查询、IN先哈希再取模对字符串和数值都友好最常用INLINE等值查询、IN基于行表达式写法直观但字符串分片键需要配置分区键和表达式容易出错我项目里默认优先HASH_MOD因为订单号的形态可能是雪花ID的大整数也可能是带业务前缀的字符串HASH_MOD能统一处理。范围查询比如create_time between是分片算法的天然短板没有哪个取模算法能优雅支持范围路由这类查询最终都会走全分片扫描。如果业务确实有强范围查询需求可以考虑INTERVAL时间分片那是另一个话题一般放在日志流水、交易流水这类数据上更合适。绑定表是JOIN性能的关键。配置里我写了t_order, t_order_item。这两张表是主表和明细表的关系它们的父子关系都用order_id关联。配置绑定表之后ShardingSphere在路由时会确保父表和子表进了同一个分片——也就是说一个订单的主记录和明细记录永远在同一个库的同一张关联物理表里。这样JOIN查询不需要跨库、跨表归并而是退化成普通的物理表JOIN。这个配置看起来不起眼但对带明细查询的订单系统来说性能差距可以达到一个数量级。绑定表的核心约束是关联字段必须是分片键否则下推逻辑会失效。分布式主键的生成方式值得多花一分钟。ShardingSphere默认内置了SNOWFLAKE算法来生成主键它会根据worker-id做机器区分。真实生产环境里每个应用实例都要配置不同的worker-id否则不同实例可能生成相同的主键这一条非常重要。如果你的服务超过1024个实例或者对ID生成有更高的可控要求建议提前换成号段模式比如美团的Leaf思路ShardingSphere支持通过自定义KeyGenerator接入这类方案。这个后面踩坑环节我再细说。还有一条必须强调不带分片键的SQL默认是全路由。比如select * from t_order where user_id ?因为user_id不是分片键ShardingSphere会在所有分片执行同样的查询再把结果归并起来。这条SQL在数据量大了之后一定慢因为它是物理上六倍的查询开销。合理做法是给这类查询单独设计一个路由索引表比如user_id到order_id的映射表或者直接把它送进分析库不让它在在线链路上裸奔。5. 读写分离配置与实践主从延迟问题的处理思路读写分离的前提是MySQL主从复制已经正常。这里不展开主从搭建的细节只强调两个基础设施层面的点一是binlog格式建议用ROW因为分片环境下多个库的结构一致性要求较高二是从库的复制延迟要有监控ShardingSphere只负责流量分发不会替你解决主从延迟本身。读写分离的配置逻辑也很清楚把主库和从库组合成一个逻辑数据源写入路由到主读取路由到从。还是用order场景举例假设现在有两个分片库order_db_0和order_db_1每个分片下面各有一主一从配置如下spring: shardingsphere: datasource: names: ds0, ds0_replica, ds1, ds1_replica ds0: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://127.0.0.1:3306/order_db_0 username: root password: root ds0_replica: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://127.0.0.1:3307/order_db_0 username: root password: root ds1: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://127.0.0.1:3306/order_db_1 username: root password: root ds1_replica: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://127.0.0.1:3307/order_db_1 username: root password: root rules: readwrite-splitting: >
