DM部署好之后。mysql远端使用gh-ost在线增加索引，发现同步失败，
看了文档可以加上参数： online-ddl，他会把gh-ost的转变成create index。
我想把这个参数加上，然后在增加一个过滤掉create index
这个参数可以在线增加吗？
online-ddl: true
sql-pattern: [“^CREATE\s+DEFINER”,“^DROP\s+EVENT”,“^CREATE\s+INDEX”]
这个就是对task的修改了。不能在线加。
但是你stop task的时候，dm_meta里面记录的binlog位置还在。
所以同一个任务，你stop task 修改好，再start task就可以了。
task name不变的话，应该是可以接着同步的。
这就相当于从dm_meta里面记录的binlog位置开始同步。
不需要重启
1 个赞
我的task-name里面的binlog本来就是已经指定的一个时间，如果stop在start，那他是不是就会从指定好的日期开始同步，这不就重复了么，
按你说的他会从那个里面记录位置开始，那如果把task任务里面的binlog信息删掉呢？会不会自动查找dm_meta自动同步呢
那怎么改？不需要重启。DM是5.3.0版本的。
按你说的他会从那个里面记录位置开始，那如果把task任务里面的binlog信息删掉呢？会不会自动查找dm_meta自动同步呢
会，我就是这个意思。
好多工具没有亲自动手用过
没试过，但这种做法连数据源（source）都一起导入导出了。我感觉动作可能比上面说的那个还大。
你是担心的点在哪里？是怕dm停机时间长？数据不一致？
https://docs.pingcap.com/zh/tidb/stable/dm-open-api#更新同步任务
即便是使用dm openapi更新task，仍然有如下注意事项。
注意
更新同步任务配置时，须确保该任务处于暂停状态，并已经运行到增量同步的阶段，且仅有部分字段可以更新。
怕更新是从之前写的pos’值又重新同步，或者stop之后再start中间会不会漏数据，最近已经停了两次了。业务影响了两次了。 
三分钟内没啥问题，。按照你说的stop在start就怕少数据
dm_meta库里面的内容不变，只要你不在task配置里面强行指定binlog 位置，就不必有这个担心。
里面本来有的 不修改就没问题？还是把他删掉这两行
删掉保险一点，我这边所有task的配置都是全量同步。
在不删掉dm_meta库中对应task的元数据表的情况下，再次start task都是从增量且从停掉的位置开始。不会再走全量的流程。
增量我没试过，但是我感觉你没有必要指定。
我目前的就是已经指定的了。本来的dm已经挂了，在新服务器搭建了一套。指定从之前的dm挂掉的那个binlog和pos值开始。如果按你的这个意思。stop一下，那我这里面指定的要不要删掉？还是不管？，感觉要删掉
你这个写的让我非常不好理解。
本来的dm已经挂了，在新服务器搭建了一套。
是dm-worker挂了，重新扩容了一个worker？还是你直接建立了一套新的dm集群。从master到worker都变了？
之前的dm-worker挂了，老的是1.0.6版本，修复不了。新打了一套服务器安装了DM5.3版本呢，新的master和worker。task任务里面增加了之前挂掉的时刻的binlog和pos值
- source-id: “db31”
block-allow-list: “bw-rule-1”
filter-rules: [“filter1”]
meta:
binlog-name: “mysql-db31-bin.019590”
binlog-pos: 436561655
看看dm_meta下有没有一个{taskname}_syncer_checkpoint 的表。打开那看内容是不是有类似上面这种记录。
有的话，task配置里面的binlog 位置可以不用指定。
没有，就需要了。
1 个赞
对应任务名有这几个表有binlog信息。那不需要的意思就是输。我要把之前写的binlog信息删掉是吗？如果要成功起的话。
我再部署一套测试。试一下看看
那就不需要，反正我配置一直是全量更新，只要这几个表还在，实际stop task 之后start task并不会导致从全量同步开始，都是增量开始。
1 个赞
恩恩。我的不是全量的，所以不好估计，根据你的这个，我的sotp之后肯定要把binlog信息配置删掉才行。
我两个方案都试试吧。
一个修改配置文件。stop之后start
一个有个导出导入。我试试看看两个效果
谢谢了兄弟
1 个赞