maxwell遇到的一则问题

结论和原因maxwell的元数据库里面没有存储全部的schema数据(就是少数据了),导致相关表的DDL校验失败。PS:我这里maxwell的作用只是采集库表修改情况的统计粗粒度指标,因为之前maxwell在运行报错的时候,直接修改了pos

maxwell遇到的一则问题

结论和原因

maxwell的元数据库里面没有存储全部的schema数据(就是少数据了),导致相关表的DDL校验失败。

PS:我这里maxwell的作用只是采集库表修改情况的统计粗粒度指标,因为之前maxwell在运行报错的时候,直接修改了positions表跳过了报错的部分,久而久之maxwell的元数据的差异比较大了。

报错现象

以下内容已脱敏。

上游业务MySQL上执行了如下的DDL语句:

代码语言:txt复制
use sbtest;
alter table sbtest111 
add `quantity` varchar(10) DEFAULT NULL COMMENT '数量1', 
add `quantity2` varchar(10) DEFAULT NULL COMMENT '数量2';

maxwell进程异常退出,日志显示:

代码语言:txt复制
1818840939 [INFO] AbstractSchemaStore: storing schema @Position[BinlogPosition[binlog.001682:799373984], lastHeartbeat=0] after applying "alter table sbtest111 add `quantity` varchar(10) DEFAULT NULL COMMENT '数量1', add `quantity2` varchar(10) DEFAULT NULL COMMENT '数量2'" to sbtest, new schema id is 4742
1818874988 [ERROR] BinlogConnectorReplicator: Unable to cast 0.00 (java.math.BigDecimal) into column sbtest.sbtest111.quantity (type 'varchar')
1818874999 [INFO] BinlogConnectorReplicator: Binlog disconnected.
1818875002 [ERROR] Maxwell: checking for schema inconsistencies in sbtest.sbtest111
1818875371 [ERROR] Maxwell: `sbtest`.sbtest111`.`quantity` has a position mismatch, 90 vs 91 in new
1818875371 [ERROR] Maxwell: `sbtest`.sbtest111`.`quantity2` has a position mismatch, 91 vs 92 in new
1818875371 [ERROR] Maxwell: `sbtest`.sbtest111` is missing column pay_amount in old
1818875371 [ERROR] Maxwell: `sbtest`.sbtest111`.`quantity` has a position mismatch, 91 vs 90 in old
1818875372 [ERROR] Maxwell: `sbtest`.sbtest111`.`quantity2` has a position mismatch, 92 vs 91 in old

如何发现这个根因的

    从maxwell的日志看起来是列顺序问题或者列缺失导致的。 因此先去看下业务库这个报错的表有多少列,再去看下maxwell的元数据库里面有没有存储这个schema的数据,如果有的话,看下maxwell里面这个表有多少列。

    结果发现maxwell里面虽然有这个表,但是列缺失了很多(可能是某个maxwell异常,我粗暴的修改positions表跳过了)。

解决办法

case1、每个maxwell实例都有独立的元数据库

这种情况很容易处理,直接把库drop了重建下,然后启动maxwell会自动去mysql上获取所有schema,然后存储到maxwell的元数据库中。

case2、多个maxwell实例公用一个元数据库

这种情况下,稍微复杂点,只能去每个表里去删除对应的数据。大致的步骤如下:

代码语言:txt复制
-- 我这里先查过了报错的maxwell对应server_id=29 client_id=12579 (client_id是在config.properties配置文件里面指定的)

delete from `positions` where server_id=29 and client_id=12579;
delete from `heartbeats` where server_id=29 and client_id=12579; 
delete from `databases` where schema_id= 4742;   -- 4742 这个值可以从maxwell的日志里面获取,也可以根据database的列表清单去databases表里面查(一个MySQL实例下的库的schema_id都是一样的)
delete from `tables` where schema_id= 4742;
delete from `columns` where schema_id= 4742;
delete from `schemas` where server_id= 29;

清理完元数据后,再次启动maxwell,它会自动去mysql上获取所有schema,然后存储到maxwell的元数据库中。

看起来,还是case1这种场景处理起来比较简单。因此个人观点是后续部署maxwell的时候,给maxwell实例都创建一个独立的元数据库。

发布者:admin,转转请注明出处:http://www.yc00.com/web/1747564192a4654622.html

相关推荐

  • maxwell遇到的一则问题

    结论和原因maxwell的元数据库里面没有存储全部的schema数据(就是少数据了),导致相关表的DDL校验失败。PS:我这里maxwell的作用只是采集库表修改情况的统计粗粒度指标,因为之前maxwell在运行报错的时候,直接修改了pos

    4小时前
    10

发表回复

评论列表(0条)

  • 暂无评论

联系我们

400-800-8888

在线咨询: QQ交谈

邮件:admin@example.com

工作时间:周一至周五,9:30-18:30,节假日休息

关注微信