windows环境下使用ShardingSphere-Proxy 设置分库分表初体验

本文介绍了在Windows环境中使用ShardingSphere-Proxy进行数据库分库分表的配置与操作,包括下载安装、配置server.yaml和config-sharding.yaml,以及通过命令行和SpringBoot应用进行数据操作的体验。详细展示了如何创建分片规则,以及在实际操作中遇到的问题和解决方案。

windows环境下使用ShardingSphere-Proxy 设置分库分表初体验

前言:最近在学习数据库的分库分表的相关知识,当系统的数据库规模极其庞大时,单体库的性能、高可用性、容量都面临绝境难以扩展适应需求,为了解决这类问题,于是了有主从集群,读写分离,分库分表等相关技术支持。数据库的组从集群读写分离,解决了高可用性的问题和分摊读与写的压力,但是没有解决数据容量扩展的问题。分库分表的技术出现就很好的解决了容量的问题。ShardingSphereapache的开源分布式数据库生态项目,对上述的读写分离,分库分表提供了支持,这里记录下第一次学习使用ShardingSphere-Proxy的记录,为了方便就仅在windows下体验。

一、下载

在这里插入图片描述
  • 打开cmd 解压包: tar -zxvf apache-shardingsphere-5.0.0-alpha-shardingsphere-proxy-bin.tar.gz

二、前置准备

解压缩后修改 conf/server.yaml和以 config- 前缀开头的文件,如:conf/config-xxx.yaml 文件,进行分片规则、读写分离规则配置 。配置方式请参考配置手册。下面有给出我的配置示例

本示例预设将表t_order的数据分库 2个库 demo_ds_0, demo_ds_1,每个库分16个表 t_order_0 ~ t_order15 存放

  • 先创建好真实的库 demo_ds_0, demo_ds_1

数据库图

  • 进入conf目录配置好 server.yamlconfig-sharding.yaml
  • 启动 shardingsphere-proxy : start.bat 3316
在这里插入图片描述

(一)server.yml

# governance:
#  name: governance_ds
#  registryCenter:
#    type: ZooKeeper
#    serverLists: localhost:2181
#    props:
#      retryIntervalMilliseconds: 500
#      timeToLiveSeconds: 60
#      maxRetries: 3
#      operationTimeoutMilliseconds: 500
#  overwrite: true

authentication:
 users:
   root:
     password: 123456
#     sharding:
#       password: sharding 
#       authorizedSchemas: sharding_db

props:
 max-connections-size-per-query: 1
 acceptor-size: 16  # The default value is available processors count * 2.
 executor-size: 16  # Infinite by default.
 proxy-frontend-flush-threshold: 128  # The default value is 128.
   # LOCAL: Proxy will run with LOCAL transaction.
   # XA: Proxy will run with XA transaction.
   # BASE: Proxy will run with B.A.S.E transaction.
 proxy-transaction-type: LOCAL
 proxy-opentracing-enabled: false
 proxy-hint-enabled: false
 query-with-cipher-column: false
 sql-show: true
 check-table-metadata-enabled: false

(二)config-sharding.yml

# 虚拟库名称
schemaName: sharding_db

dataSourceCommon:
 username: root
 password: 123456
 connectionTimeoutMilliseconds: 30000
 idleTimeoutMilliseconds: 60000
 maxLifetimeMilliseconds: 1800000
 maxPoolSize: 5
 minPoolSize: 1
 maintenanceIntervalMilliseconds: 30000

# 映射真实数据源
dataSources:
 ds_0:
   url: jdbc:mysql://127.0.0.1:33061/demo_ds_0?serverTimezone=UTC&useSSL=false
 ds_1:
   url: jdbc:mysql://127.0.0.1:33061/demo_ds_1?serverTimezone=UTC&useSSL=false

#配置规则 库是 ds_0 ~ ds_1 表是 t_order_0 ~ t_order_15
rules:
- !SHARDING
 tables:
   t_order:
     actualDataNodes: ds_${0..1}.t_order_${0..15}
     tableStrategy:
       standard:
         shardingColumn: order_id
         shardingAlgorithmName: t_order_inline
     keyGenerateStrategy:
       column: order_id
       keyGeneratorName: snowflake
#   t_order_item:
#     actualDataNodes: ds_${0..1}.t_order_item_${0..1}
#     tableStrategy:
#       standard:
#         shardingColumn: order_id
#         shardingAlgorithmName: t_order_item_inline
#     keyGenerateStrategy:
#       column: order_item_id
#       keyGeneratorName: snowflake
# bindingTables:
#   - t_order,t_order_item

 defaultDatabaseStrategy:
   standard:
     shardingColumn: user_id
     shardingAlgorithmName: database_inline
 defaultTableStrategy:
   none:

# 数据库的路由规则策略是user_id % 2 意思是 user_id % 2=0 的到ds_0,user_id % 2= 1的到ds_1
# 表的路由策略是 order_id % 16 意思是 order_id % 16=0 的到t_order_0 ... order_id % 16= 15的到的到t_order_15

 shardingAlgorithms:
   database_inline:
     type: INLINE
     props:
       algorithm-expression: ds_${user_id % 2}
   t_order_inline:
     type: INLINE
     props:
       algorithm-expression: t_order_${order_id % 16}
#   t_order_item_inline:
#     type: INLINE
#     props:
#       algorithm-expression: t_order_item_${order_id % 2}

# 启用雪花算法
 keyGenerators:
   snowflake:
     type: SNOWFLAKE
     props:
       worker-id: 123

三、演示

(一)命令行体验

  • 另起一个cmd 连接ShardingSphere-Proxy: mysql -h 127.0.0.1 -P 3316 -uroot -p123456 -A
D:\mysql\mysql-8-master\bin>mysql -h 127.0.0.1 -P 3316 -uroot -p123456
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 7
Server version: 8.0.28-ShardingSphere-Proxy 5.0.0-RC1

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show schemas;
+-------------+
| Database    |
+-------------+
| sharding_db |
+-------------+
1 row in set (0.00 sec)

mysql> CREATE TABLE IF NOT EXISTS t_order (order_id BIGINT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL, status VARCHAR(50), PRIMARY KEY (order_id));
Query OK, 0 rows affected (1.26 sec)
  • 神奇的体验来了 执行 CREATE TABLE IF NOT EXISTS t_order (order_id BIGINT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL, status VARCHAR(50), PRIMARY KEY (order_id)); 时,会在demo_ds_0 和demo_ds_1同时创建16张表. 下图是ShardingSphere-Proxy 服务端的日志打印情况

在这里插入图片描述

  • 插入数据:insert into t_order(user_id,status) values(1,'ok'),(2,'fail'),(3,'hello world'),(4,'2022-04-21'),(5,'Hangzhou king of volume'),(6,'In learning sub - library sub - table');此时会根据user_id为奇数时路由使用ds_1, user_id 为偶数时使用ds_0,插入数据时的 order_id是更具配置的雪花算法自动生成的值对16取模,放到对应的t_orderX表里插入数据。

在这里插入图片描述

  • 查询数据:select * from t_order;执行该sql 未带条件,会从2个数据库里捞出所有数据合并返回。如果带的条件包含user_id,order_id则会根据配置的情况进行路由捞取数据。

在这里插入图片描述

在这里插入图片描述

(二)spring boot 内体验

四、踩坑

  • 启动shardingSphere-proxy服务失败,报找不到server.xml 根据输出的异常日志就是 所在目录下有空格转成 %27导致,该问题解决方式有2种: 1. 把服务放在不带空格的目录下启动。 2.用5.1版本的 shardingSphere-proxy

在这里插入图片描述

  • 用navicat 连接服务报错 10002:该问题是工具本身问题,通过命令行连接是正常的,不用在意。

在这里插入图片描述

参考资料

<think>好的,我现在需要帮助用户了解如何通过ShardingSphere-Proxy的日志验证分表路由的正确性。用户之前已经问过关于ShardingSphere-Proxy使用分表是否需要修改Spring Boot代码的问题,现在他根据我的回答,进一步询问如何通过日志验证分表是否正确。我需要结合用户提供的引用内容和之前的对话来给出详细的步骤和说明。 首先,用户提供的引用内容中,引用[3]提到他使用的是ShardingSphere-Proxy 5.5.1版本,并给出了下载和安装步骤。这可能对日志的位置和配置有帮助。引用[4]提到了分片算法,比如哈希取模和范围分片,这可能涉及到路由策略的具体实现,这些信息可能在日志中体现出来。引用[1]和[2]则更多是关于ShardingSphere-Proxy的配置和应用场景,可能对理解整体架构有帮助。 接下来,我需要回忆之前回答的内容。在之前的回答中,我提到验证分表路由的方法是通过Proxy执行SQL并观察日志,例如执行SELECT * FROM user WHERE id=5,然后查看Proxy日志中的实际路由到哪个物理表。现在用户希望更详细地了解这个过程,所以需要详细说明日志的位置、如何开启详细日志、具体的验证步骤以及常见问题处理。 首先,日志的位置可能根据安装路径不同而有所变化。用户安装路径是/ops/app/sharding-proxy,所以日志可能在logs目录下,比如stdout.log。然后,需要确认用户是否已经配置了日志级别为DEBUG,因为默认可能不是足够详细。需要指导用户如何修改logback.xml配置文件,调整日志级别。 接下来,具体的验证步骤需要分步骤说明:发送测试SQL,检查日志中的Actual SQL部分。这里需要给出具体的例子,比如插入和查询操作,对应的日志输出应该显示路由到哪个具体的分表。同时,要提醒用户注意分片键是否在SQL语句中出现,否则可能导致全路由,影响验证结果。 然后,常见问题处理部分需要涵盖没有分片键的情况,分片算法是否匹配,以及物理表是否存在。例如,如果用户漏掉了分片键,日志中会显示所有分表都被访问,这时候需要提醒用户检查SQL语句。如果分片算法配置错误,比如模数不对,路由结果就会出错,需要检查配置。另外,如果物理表不存在,即使路由正确也会报错,所以需要确认表结构是否已经正确创建。 最后,要确保回答结构清晰,分点说明,并参考用户提供的引用内容。比如引用[4]提到的分片算法,可以在解释分片算法类型时引用,说明不同算法在日志中的表现可能不同。同时,用户之前的问题中提到的分表规则配置,也需要在日志验证中对应起来,确保用户能够将配置和实际日志输出联系起来。 可能还需要考虑用户的实际操作环境,比如是否熟悉查看日志文件,是否有权限修改日志配置等。因此,在回答中需要给出具体的命令和配置示例,帮助用户一步步操作。例如,修改logback.xml的具体位置,如何重启Proxy服务等。这些细节能帮助用户减少操作中的障碍,顺利验证分表路由的正确性。 总结来说,我需要将整个过程分解为日志位置、开启详细日志、验证步骤、示例分析以及常见问题处理,每个部分都要详细且易于理解。同时,结合用户提供的引用内容,确保回答的准确性和相关性。</think>以下是基于引用内容并结合实际经验的详细解答,说明如何通过ShardingSphere-Proxy日志验证分表路由的正确性: --- ### 一、日志文件定位 1. **默认日志路径** Proxy的日志文件通常位于安装目录下的`logs`文件夹中(根据引用[3]的安装路径): ```bash /ops/app/sharding-proxy/logs/stdout.log # 标准输出日志 ``` 2. **关键日志标识** - **逻辑SQL**:业务代码中发送的原始SQL(使用逻辑表名) - **Actual SQL**:Proxy解析后实际执行的物理SQL(带分表后缀) - **Route**:分片路由结果(显示具体分库分表--- ### 二、验证步骤 #### 步骤1:开启DEBUG日志级别(若需更详细信息) 修改Proxy服务端`conf/logback.xml`,调整日志级别: ```xml <!-- 修改前 --> <logger name="org.apache.shardingsphere" level="INFO" /> <!-- 修改后 --> <logger name="org.apache.shardingsphere" level="DEBUG" /> # 输出详细路由信息 ``` 重启Proxy服务使配置生效: ```bash cd /ops/app/sharding-proxy && ./bin/stop.sh && ./bin/start.sh ``` #### 步骤2:执行测试SQL并观察日志 **示例场景**(基于引用[4]的分片算法): - **分表规则**:对`id`字段哈希取模(`sharding-count=4`) - **逻辑表名**:`user`,物理表名:`user_0`到`user_3` **测试用例1:精确分片键查询** ```sql -- 业务代码执行 SELECT * FROM user WHERE id = 7; ``` **日志验证**: ```log [DEBUG] [main] ShardingSphere-SQL - Logic SQL: SELECT * FROM user WHERE id = 7 [DEBUG] [main] ShardingSphere-SQL - Actual SQL: ds_0 ::: SELECT * FROM user_3 WHERE id = 7 # id=7 mod4=3 → user_3 ``` **测试用例2:无分片键查询** ```sql SELECT * FROM user WHERE name = 'Alice'; ``` **日志验证**: ```log [DEBUG] [main] ShardingSphere-SQL - Actual SQL: ds_0 ::: SELECT * FROM user_0 WHERE name = 'Alice' [DEBUG] [main] ShardingSphere-SQL - Actual SQL: ds_0 ::: SELECT * FROM user_1 WHERE name = 'Alice' [DEBUG] [main] ShardingSphere-SQL - Actual SQL: ds_0 ::: SELECT * FROM user_2 WHERE name = 'Alice' [DEBUG] [main] ShardingSphere-SQL - Actual SQL: ds_0 ::: SELECT * FROM user_3 WHERE name = 'Alice' # 广播全表 ``` --- ### 三、关键验证点 1. **分片键匹配性** 检查`Actual SQL`中的分表后缀是否与分片键值(如`id=7`)通过分片算法计算的结果一致[^4]。 2. **路由范围正确性** - **精确路由**:当SQL包含分片键时,应仅命中一个分表(如`user_3`) - **广播路由**:当SQL不包含分片键时,应命中所有分表(如`user_0`到`user_3`) --- ### 四、常见问题排查 | 问题现象 | 原因分析 | 解决方案 | |-----------------------------|--------------------------|------------------------------| | 实际SQL未替换分表后缀 | 分表规则未生效 | 检查Proxy配置`config-sharding.yaml` | | 分片结果与预期不符 | 分片算法类型或参数错误 | 验证分片算法实现(如HASH_MOD的`sharding-count`)[^4] | | 路由到不存在的物理表 | 物理表未实际创建 | 在数据库中手动创建`user_0`到`user_3`表 | --- ### 五、扩展验证方法 通过Proxy的`SHOW`命令直接查看路由结果: ```sql -- 执行解析SQL(不实际执行) PREVIEW SELECT * FROM user WHERE id = 7; -- 输出结果 +------------------+----------------+ | data_source_name | actual_table | +------------------+----------------+ | ds_0 | user_3 | +------------------+----------------+ ``` --- ### 六、示例分析 **引用[4]的分区段算法验证**: 若分表规则为范围分片(如`[0-255]→user_0`,`[256-511]→user_1`): ```sql SELECT * FROM user WHERE id = 300; # 应路由到user_1 ``` **预期日志**: ```log Actual SQL: ds_0 ::: SELECT * FROM user_1 WHERE id = 300 ``` ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值