分布式 | dble元数据更新同步

爱可生云数据库
English

作者:吴金玲

爱可生 dble 项目团队成员,主要负责 dble 相关的日常测试工作,擅长对 dble 中出现的问题进行排查。热爱测试工作,余生欲将测试工作进行到底。

本文来源:原创投稿

*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。


同步元数据,reload @@config_all or reload @@metadata ?

一、本文以 dble 3.21.06.0 版本为例,首先让我们来看看社区经常遇到的几类找不到表或者表字段的问题
sharding.xml的关键配置如下:

问题1:启动 dble 后,在所有后端节点都建立了表 sharding_2_t1 ,然后在 dble 管理端执行 reload @@config_all 命令,查询表 sharding_2_t1 数据及向表 sharding_2_t1 中插入数据,均报找不到表的 metadata 信息(如下图所示),为什么?

问题2:在后端节点对表 sharding_4_t1 增加一个 age 字段,且已确保所有后端节点都增加了这个字段,然后执行 reload @@config_all ,对表进行查询使用新增的字段没问题,但使用 order by 就提示找不到这个字段(如下图所示),为什么?

二、在回答出现以上问题的原因之前,首先让我们来看看 reload @@config_all 和 reload @@metadata 的使用说明(具体可参见 dble 官方文档:https://github.com/actiontech...),这样能够使我们更好的理解问题

1.reload @@config_all(2.19.09.0 版本之后功能完全等同于reload @@config )

重新加载所有配置,涉及3个 xml 配置文件( user.xml,db.xml,sharding.xml ),同时 reload @@config_all 还有3个可选参数的形式:reload @@config_all [-s] [-f] [-r];

-s 跳过测试后端链接,默认不加此参数会对配置中的后端链接进行测试,测试失败将返回 ERROR ;

-f 关闭所有变更的 dbGroup(同时加-r参数则所有 dbGroup 都会被视为变更)相关的处于事务中的前端链接,如果无此参数默认仅将相应后端链接放入旧链接池。

-r 不做智能判断,将所有后端连接池全部重新加载一遍。不加此参数时,将对新配置进行智能判断,只会对增删改的连接池做变更,不影响未作变更的连接池。

相关影响:当执行此命令时,表的配置信息发生变更时,涉及到的表的 meta 信息才会被重载,否则保持原有表 meta 信息。另外,如果包含 -r 参数则不做上述判断,全部重新加载 meta 数据。如果不包含 -r 但是包含 -s 参数,则对 metadata 是否需要重新加载的计算时,忽略所有 dbGroup/dbInstance 的变更。注意,不能在配置变更中体现的某些变化是无法重新加载 metadata 的,比如一个带有默认 shardingNode 的 schema 尝试通过删除配置将拆分表或者 global 表变成非拆分表是不符合规范的。应当避免这种操作。

2.reload @@metadata

reload @@metadata 的作用是重新加载所有元数据信息,同时还有两种扩展的过滤表达式的形式:

reload @@metadata where schema=? [ and table=? ]:重新加载指定 schema 中所有表或指定表的元数据信息。

reload @@metadata where table in ('schema1.table1' ,'schema2.table2','schema1.table3',...):重新加载 schema1 中 table1,table3 和 schema2 中 table2 的元数据信息。

从以上 reload @@config_all 和 reload @@metadata 的使用说明可以看出,二者在加载元数据时的主要区别为:reload @@config_all 只会对配置中的变更项进行重新加载 metadata ,对配置未做变更的项需要手动执行 reload @@metadata 同步变更的元数据。

三、理解了 reload @@config_all 及 reload @@metadata 的区别后,我们再来分析出现前面两个问题的原因。

不难看出,问题1和问题2的报错都是由于在配置没有发生变更的情况下,在后端节点建表或修改表结构后,认为可以通过执行 reload @@config_all 同步到变更的表的元数据导致的。这里使用者有一个常见的误区,认为所有场景下执行 reload @@config_all 都会触发重新加载元数据,但实际上只有当配置同时发生变更时才会同步更新元数据,其他场景都需要手动执行 reload @@metadata 将后端表的元数据同步到 dble 中。

另外,问题2中为什么 select age from sharding_4_t1 能够查询成功,这是因为此查询属于简单查询,直接下发语句到后端节点执行即可,dble 内部不需要用到 age 字段,而后端节点存在 age 字段,所以执行成功。

四、为了便于排查元数据相关的错误,可以使用 check full @@metadata 查看当前 dble 中所有表的元数据信息。

check full @@metadata 还支持按多种条件过滤(具体可参见 dble 的官方文档:https://github.com/actiontech...

通过以上查询结果不难发现,表 sharding_2_t1 和表 sharding_4_t1 的元数据均未同步到更新。

执行 reload @@metadata 后,再次执行 check full @@metadata 查询元数据信息:

通过以上结果可以看到表sharding_2_t1和表sharding_4_t1已经同步到正确的元数据信息,此时可以对表进行常规操作而不会报错:

阅读 499

MySQL分布式中间件DBLE
DBLE是一个基于MySQL的高可扩展性的分布式中间件,适用于高并发及TB级海量数据处理场景。

中国领先的企业数据处理技术整体解决方案提供商,开源数据库领域优秀企业。为大型行业用户的特定场景提...

275 声望
149 粉丝
0 条评论

中国领先的企业数据处理技术整体解决方案提供商,开源数据库领域优秀企业。为大型行业用户的特定场景提...

275 声望
149 粉丝
文章目录
宣传栏