你好，我这里有个task配置，需求是指同步do-dbs里的数据库，但需要将do-dbs库里的以_开头的_new结尾的数据表（比如sneaker._zzz_order_new）的所有操作全过滤掉，请问这个应该怎么配置
这里是 go 的正则规则，试下 ~^_(.+?)_new
https://docs.pingcap.com/zh/tidb-data-migration/stable/feature-online-ddl-scheme#概述
参数问题，可以在文档中自行检索哈
online-ddl-scheme功能已经测试完成,发现个问题,tidb对单纯的添加字段响应非常快,因此不会造成同步延迟,但是如果是添加字段并且对这个字段添加索引这个时候tidb会产生很大的延迟,具体延迟多久依赖于表的大小
你好,这个格式“~^_(.+?)_new”也不生效
~^_(.*)_new$ 试下，
此为预期行为，tidb ddl 执行时间具体可以看下 asktug sop 文章，
简单说明就是，tidb 对于不同的 ddl 做了优化，对于添加字段会比较快速返回，添加索引会根据具体情况进行处理。
额，sorry，看下 task 文件是否已经配置 `online-ddl-scheme: “pt”，如果已经配置，则不需要对 _tbl_old/new 进行过滤，辛苦调整下 task 在进行同步。
此正则范围比较宽泛，请谨慎配置，防止下游复制时少表，上面已经给出解决方案，仅仅使用 online-ddl-scheme: 'pt' 即可，不需要对 filter 进行单独的过滤
另外,online-ddl-scheme: “pt”这个参数我的测试结果是,针对于添加字段的操作效果比较好,不会太长时间的阻塞写操作,但是如果是添加索引或者添加字段然后给该字段添加索引的话延迟比较重
预期行为的，目前通过 filter 过滤了所有的 event 这个风险请评估下。
经过大量测试完全符合我们的需求,这个地方有个坑需要注意:
1、业务对tidb的数据实效性要求不能太高,该操作对于大表会有s级别延迟
2、要在业务低峰期上线
3、上线过程分为两步:
1)线上mysql上线
2)tidb上线
上线需要注意的地方:
mysql与tidb的上线间隔不要太大否则dm无法通过retry机制恢复数据同步
，针对业务进行定制化处理，或者可以对 mysql 和 tidb 进行同步大表 dll （添加索引），pt-osc 和 在 tidb 中执行 add index 同时进行，可以通过配置 task 任务，过滤掉 alter table add index 操作。带完成后，开启 task 任务亦可。
这个思路正是online-ddl-scheme功能设计的思路,但是有个问题被忽略了,alter table add column与alter table add index虽然都属于ddl操作,但是对数据表的影响不同,尤其是在tidb中,在tidb中add column基本秒完成,但是add index则需要很长时间,而add index操作是不会影响数据同步的所以这个时候没必要停止同步,当上游mysql库执行万add column的时候tidb这个时候一定会报错,但tidb对add column高效支持正好弥补这个问题,只要在mysql上线完成后立刻在tidb上线报错时间不会太长,(如果时间超过了dm的retry次数的时间则需要手动resume-task修复任务)所以到目前问题没有发现数据异常的现象
这个案例可以提供给你们做个案例样本,或者帮我们审核下是否有数据方面的风险