关于mycat:分布式-实战将业务从-MyCAT-平滑迁移到-dble

35次阅读

共计 2921 个字符，预计需要花费 8 分钟才能阅读完成。

作者：肖亚洲

爱可生 DBA 团队成员，负责我的项目中数据库故障与平台问题解决，对数据库高可用与分布式技术情有独钟。

本文起源：原创投稿

* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。

客户环境近期呈现了几次问题，通过探讨后决定进行架构变更，要将 mycat 迁徙到 dble。要求是：最小变动。

联合客户状况与要求列举了下须要思考的事件：

参数设置
分片函数
数据节点的数据
业务 SQL

1、参数设置

mycat 端参数如下:

<system>
<property name="defaultSqlParser">druidparser</property>
<property name="processors">4</property>
<property name="processorBufferPool">20480000</property>
<property name="processorBufferLocalPercent">100</property>
<property name="frontSocketSoRcvbuf">10485760</property>
<property name="frontSocketSoSndbuf">41943040</property>
<property name="frontSocketNoDelay">1</property>
<property name="backSocketSoRcvbuf">41943040</property>
<property name="backSocketSoSndbuf">10485760</property>
<property name="backSocketNoDelay">1</property>
<property name="maxPacketSize">2048576000</property>
<property name="memoryPageSize">100m</property>
</system>

针对该参数 DBLE 侧倡议如下：

defaultSqlParser、memoryPageSize、processorBufferLocalPercent 已于 dble 中被废除，可不用配置
processorBufferPool 参数名变更为 bufferPoolPageSize
其余的参数在 dble 中可在 server.xml 中与 mycat 保持一致配置信息，局部参数信息详情可见：https://github.com/actiontech…

留神：mycat 和 dble 的内存治理配置有较大不同。比方：没有 threadlocal 概念。倡议浏览以下文档：https://actiontech.github.io/…

2、分片函数

查看 mycat 分片规定：

<function name="mod-long" class="io.mycat.route.function.PartitionByMod">
<!-- how many data nodes -->
<property name="count">8</property>
</function>

间接采纳 DBLE 的 hash 算法测试发现局部数据查问报错：

查看表内数据状况：

样例数据：20210810143211157000000000036

字段：user_code 为 varchar(32)

查看 mycat 环境分片规定：采纳的分片算法为 mod-long。而 long 的取值范畴是 -9223372036854774808~9223372036854774807，查问出错的 20210810143211157000000000036 超过了 long 的取值范畴。所以能够得出 mycat 针对这一非凡状况做了非凡解决。

针对该状况 DBLE 侧倡议如下：

1、倡议分片算法换成 HashString

分片列值超过 Long 的最大值(9223372036854774807), 须要换成列为 String 型的分片算法；

留神：历史数据须要在更换完算法分片后从新导入

2、采纳 DBLE 的自定义算法

援用 mycat 的 PartitionByMod 算法，退出 [dble 的自定义算法 https://actiontech.github.io/…] 中。

最终配置如下：

<function name="test_func" class="com.actiontech.dble.custom.sharding.algorithm.PartitionByMod">
    <property name="count">8</property>
</function>

3、数据节点数据

通过引入 DBLE 的自定义拆分算法性能，兼容了原环境 mycat 上的拆分算法，因而原 mycat 环境的存储节点数据也不须要再做任何变动。这极大的缩小了咱们迁徙的工作量。

4、业务 SQL

通过几轮测试下来，咱们发现 mycat 在很多时候会将 SQL 间接下发到后端节点，这就造成了咱们在测试时碰到了很多问题，因为 DBLE 对多种状况做了细分。

为了最大水平保障业务查问数据的准确性 DBLE 砍了很多此类 SQL 的反对，但为了业务的变更最小，DBLE 也做了适当凋谢。

如下是局部记录：

对 insert into … select … 语法的反对

目前 DBLE 放开了垂直表该语法的反对。
对 rownum 透传的反对

目前 DBLE 放开了指定表 rownum 的透传。
UPDATE query with sub-query is not supported

1.update 多节点更新会触发分布式事务的问题，难以保障一致性

2. 依照目前的执行打算，mycat 对于 update+ 子查问采纳的是将源 sql 进行播送下发（下发至表关联的所有节点），这种机制在某些状况下是无奈保障正确性的

3. 多表关联更新不反对，dble 作为一个中间件产品，解决的某一类的 sql，对于这类 sql 正确的解决办法是须要先将子查问下发，回收后果后再拼接外层 sql 进行下发，目前对于这种解决形式解析、实现比拟艰难，而且性能问题也是须要考量。

4. 为了保障 update+ 子查问这类 sql 的正确性，必定不能用 mycat 这种播送下发来做，所以对于这类 sql 目前是不反对的
全局表 + 分片表类型 SQL 反对

ERROR 4004 (HY000): Unknown function FN_TREE_PATHNAME

1.dble 在 2.20.04.x 版本及其之后版本曾经做过优化能够间接执行这种状况的 sql.

2. 全局表 + 分片表之前没有解决是因为间接下发是可能存在问题，对于全局表 + 分片表中非凡的场景：全局表 + 垂直表，并未计算出来这些节点最初应用的是同一个节点。（其实能够计算，dble 在 2.20.04.x 版本及之后已优化）

3.mycat 会间接下发语句到节点中，全局表在每个配置的节点都会存储雷同的数据，如果将每个节点和拆分表 Left Join 的后果进行简略的 UNION ALL 合并，会造成数据的反复，不能保证数据的准确性。所以不能间接透传。