sharding-proxy分表配置过程记录

本文介绍如何使用Sharding-Proxy实现分库分表,包括软件下载、配置及测试过程。通过具体实例展示了如何配置分表规则及主键生成策略。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

之前研究过通过mycat进行分库分表的配置,最近发现很多项目上用的都是sharding-proxy来实现,所以也来进行一个学习。下面来简单记录一下搭建的过程。

下载

首先自然是去官网下载软件,这里我下载的是最新版5.1.2,下载地址如下:

https://www.apache.org/dyn/closer.lua/shardingsphere/5.1.2/apache-shardingsphere-5.1.2-shardingsphere-proxy-bin.tar.gz

直接在centos虚拟机上用 wget命令进行下载即可,下载完成后,输入 tar -zxvf apache-shardingsphere-5.1.2-shardingsphere-proxy-bin.tar.gz进行解压,最终解压出来一个文件夹,进行下一步。

配置

进入文件夹,可以看到一个十分眼熟的文件结构,非常像tomcat。可能apache家的软件都是这个结构?(笑)

进入conf,首先我们修改 server.yaml这个配置文件,这个配置文件主要是用来设置一个虚拟的登录用户以及密码。

进去之后我们可以看到官方已经提供了样例配置,都被注释掉了。我们只需要放开需要修改的注释,并进行修改即可。这里我主要修改的内容如下:

rules:
  - !AUTHORITY
    users:
      - root@%:123456
      - sharding@:sharding
props:
  proxy-default-port: 3333

这里的配置,是开放了两个用户,root和sharding,作为连接我们sharding-proxy的用户。以及修改了应用启动的端口号,默认使用的是3307,但我还有其他的应用占用了3307,所以这里改成了3333。

接着我们修改config-sharding.yaml这个配置文件,这个文件就是我们分库分表的主要配置文件了。

这个文件也是官方提供了样例配置,我们同样只需要放开注释,进行修改:

######################################################################################################
#
# If you want to connect to MySQL, you should manually copy MySQL driver to lib directory.
#
######################################################################################################

databaseName: aki_sharding

dataSources:
  ds_0:
    url: jdbc:mysql://127.0.0.1:3306/aki_ds_0?serverTimezone=UTC&useSSL=false
    username: root
    password: 123456
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
    minPoolSize: 1
#  ds_1:
#    url: jdbc:mysql://127.0.0.1:3306/aki_ds_1?serverTimezone=UTC&useSSL=false
#    username: root
#    password: 123456
#    connectionTimeoutMilliseconds: 30000
#    idleTimeoutMilliseconds: 60000
#    maxLifetimeMilliseconds: 1800000
#    maxPoolSize: 50
#    minPoolSize: 1

rules:
- !SHARDING
  tables:
    t_order:
      actualDataNodes: ds_0.t_order_${0..1}
      tableStrategy:
        standard:
          shardingColumn: order_id
          shardingAlgorithmName: t_order_inline
      keyGenerateStrategy:
        column: order_id
        keyGeneratorName: snowflake
    t_order_item:
      actualDataNodes: ds_0.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:

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

  keyGenerators:
    snowflake:
      type: SNOWFLAKE

这个配置文件比较长,我们挑一些重要的来看看。

首先是开头,可以看到是配置了虚拟的数据库名称,以及数据源。这里可以看到我注释掉了第二个数据源,因为这里的多个数据源实际上对应着多个数据库,是一个分库的概念。这里我们先只探究分表的玩法。

再往下是一些分库分表的规则,这里可以配置数据按什么规则来进行分表,以及哪些表需要进行分表、主键生成策略等等,这里采用的是雪花id。

最后,还有一点需要注意,就是sharding-proxy本身并没有mysql的连接jar包,所以这里我们需要自己去准备一个,然后放到lib文件夹中。这里我用的mysql版本是8.x的,所以connector jar包也用了8.x的。

测试

配置完成后,程序启动方法也很简单。进入bin目录,执行start.sh即可。日志会自动输出到logs/stdout.log中

在启动之前,还需要注意,我们需要在真实的数据源中建立对应的数据库,否则启动会报错

我们用navicat连接进行测试

可以看到,在3333端口连接成功了。

然后,我们在这个aki_sharding库中,建立2张表:t_order,aki_test。这两张表,一个是在前面的配置文件中配置的要进行分表的表,一个则是完全无关的表。我们来看看会是什么样的结果:

可以看到,在宿主库中,sharding-proxy帮我们把t_order表进行了分表,分成了2张。而对于aki_test表,则是普通的创建。

下面我们试着往t_order表中插入几条数据进行测试:

然后我们去宿主库进行查看:

可以看到,主键id是用雪花id生成的,并且按照规则分配到了2张表中。这样我们就完成了分表的基本操作。

经过测试,基本的查询、修改、删除、插入等操作,对用户来说都是无感知的,可以把sharding-proxy虚拟出来的这个数据库,当成真正的数据库来进行使用。

### Nginx 文件名逻辑漏洞(CVE-2013-4547) #### 漏洞概述 Nginx 文件名逻辑漏洞(CVE-2013-4547)允许攻击者通过精心构造的 URL 请求来绕过访问控制并读取或执行受限资源。此漏洞的根本原因在于 Nginx 错误地解析了带有特定编码字符的 URL,从而导致文件路径处理不当[^1]。 #### 影响范围 该漏洞影响多个版本的 Nginx,在某些配置下可能导致未经授权的文件访问甚至远程代码执行。具体受影响的版本包括但不限于: - Nginx 1.4.x 版本系列 - Nginx 1.5.x 版本系列 (部分) 当 Web 应用程序部署于上述版本之上时,可能存在潜在风险[^3]。 #### 复现过程 为了验证这一漏洞的存在,可以通过上传一个看似无害但实际上包含恶意 PHP 代码的图片文件 `phpinfo.jpg` 来测试。一旦成功上传,攻击者能够修改 HTTP 请求中的参数使服务器错误解释文件扩展名,进而触发命令注入行为[^4]。 ```bash curl -X POST http://example.com/upload.php \ -F "file=@/path/to/phpinfo.jpg" ``` 随后发送如下请求可尝试利用漏洞: ```http GET /uploads/phpinfo.jpg%00.php?cmd=id HTTP/1.1 Host: example.com ``` 如果存在漏洞,则返回的结果会显示当前用户的 ID 信息。 #### 安全修复措施 针对 CVE-2013-4547 的防护手段主要包括以下几个方面: - **升级至最新稳定版**:官方已发布更新解决此问题,建议立即应用最新的安全补丁以消除隐患[^2]。 - **手动修补源码**:对于无法即时升级的情况,可以从官方网站下载专门为此漏洞准备的安全补丁,并按照指引完成编译安装流程。 - **加强输入校验**:无论何时都应严格过滤用户提交的数据,特别是涉及文件操作的部分,防止非法字符进入内部处理环节。 - **启用 WAF 防护**:Web Application Firewall 能够识别异常模式并阻止可疑流量到达应用程序层面上游位置。 综上所述,及时采取适当行动可以有效降低遭受此类攻击的风险。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值