有这个列，我们已经重建tiflash了，这个表对应的库我们也不同步到tiflash了
这个表的索引特别多，有20多个索引，然后其中一个唯一索引包含这个列
非常感谢大佬
好的。
set tiflash replica 先设置 为0，再设置为1
特殊列导致不能被转成列把
重新生成tiflash
构建出最小复现 case 并定位到原因了：https://github.com/pingcap/tiflash/issues/8419 。 跟增删唯一索引无关，是跟把 nullable 列转为 not null 列的 DDL 有关。
是在一个原来为 nullable 列，而且默认值非 0 的情况下，存在一些 NULL 值的行。在对 NULL 值填充后，通过 DDL 把该列转化为 not null 。
这样情况下，在旧 schema 下带有 NULL 的行被 GC 之前，如果发生添加 tiflash 副本，或者因为 PD 调度而在 tiflash 节点之间产生 region 副本迁移的情况。tikv 会把当前 not null 列的新旧版本都发到 tiflash，tiflash 在解析旧版本的行中 NULL 值时会因为不符合最新的 schema 而解析出错。
我们会尽快修复这个问题，在后面发布的 patch 版本中修复。可以留意新版本的 release note。
2 个赞
现在有办法绕过这种错误，让tiflash能起来么？
在已经受影响的版本中避免触发该 bug 的方法：
- 业务避免进行 nullable 的列转为 not null 的操作
- 或者是手动在原表创建一个 not null 的列，将原来 nullable 的列的值通过 update 语句更新到 not null 的列上，然后再 drop 旧列，最后再对新列做重命名
发生这个情况后 workaround 拉起 tiflash 的方式：
把表的数据 copy 到另外没有 tiflash 副本的表 table_new 上。然后在原表 ALTER TABLE table_old DROP COLUMN denomination 。这样 tiflash 就不会去 decode 该列的数据，可以正常拉起继续对外提供服务
2 个赞
可以给每个历史版本发布一个避坑贴
比心，这个确实应该置顶，有workaround的方法就还好，至少还能有启动TiFlash的机会
您好 我们在修改表字段类型 有默认值也会报这种错误，不仅仅是null才报错的
我们自己测试中，这样可以触发
create table t (a int, b DECIMAL(20) NULL default 1.0, c int NOT NULL);
insert into t(a,b,c) values (1,NULL,1),(2,NULL,2),(3,NULL,3),(4,NULL,4);
insert into t(a,b,c) values (11,0.1,11),(12,0.2,12),(13,0.3,13),(14,0.4,14);
select * from t;
update t set b = 0 where b is null;
select * from t;
alter table t modify column b DECIMAL(20) NOT NULL;
select * from t;
alter table t set tiflash replica 1;
这样不会触发
create table alt2 (a int, b DECIMAL(20) NULL default 1.0, c int NOT NULL);
alter table alt2 set tiflash replica 1;
insert into alt2 (a,b,c) values (1,0.01,1),(2,0.02,2),(3,0.03,3),(4,0.04,4);
insert into alt2 (a,b,c) values (11,0.1,11),(12,0.2,12),(13,0.3,13),(14,0.4,14);
select * from alt2 ;
update alt2 set b = 0 where b is null;
select * from alt2 ;
alter table alt2 modify column b DECIMAL(20) NOT NULL;
select * from alt2 ;
alter table alt2 set tiflash replica 1;
能够具体描述下你进行了什么操作后，触发了类似的错误吗？
终于在
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。