Data decrease in shard-mode when change auto-increment in downstream

[XuJianxu]

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. What did you do? If possible, provide a recipe for reproducing the error.
   200 upstream mysql, 200* dm worker, 3*dm master, 200K QPS+TPS in upstream.
   Upgrade dm cluster from 2.0.1 to nightly。

2. What did you expect to see?
   After upgrade process completed, data will go on to migrate to downstream tidb.

3. What did you see instead?
   The data in specified table decreased.
   

4. Versions of the cluster

   • DM version (run dmctl -V or dm-worker -V or dm-master -V):

     nightly
     

   • Upstream MySQL/MariaDB server version:

     mysql5.7/5.8
     

   • Downstream TiDB cluster version (execute SELECT tidb_version(); in a MySQL client):

     4.0.10
     

   • How did you deploy DM: DM-Ansible or manually?

     DM-Ansible
     

   • Other interesting information (system version, hardware config, etc):

5. current status of DM cluster (execute query-status in dmctl)

6. Operation logs

   • Please upload dm-worker.log for every DM-worker instance if possible
   • Please upload dm-master.log if possible
   • Other interesting logs
   • Output of dmctl's commands with problems

7. Configuration of the cluster and the task

   • dm-worker.toml for every DM-worker instance if possible
   • dm-master.toml for DM-master if possible
   • task config, like task.yaml if possible
   • inventory.ini if deployed by DM-Ansible

8. Screenshot/exported-PDF of Grafana dashboard or metrics' graph in Prometheus for DM if possible

[lance6716]

This is caused by after changing the table structure in downstream, user didn't tell DM so DM will generate DELETE DML in safemode like

DELETE FROM `db_test`.`table_shard` WHERE `primary_id` = 123456 LIMIT 1

which matches many rows in downstream since it's a shard merging task.

[GMHDBJD]

In this case, should we support operate-schema before sync start?

[lance6716]

currently, we have almost no practical action to operate-schema set a correct schema before sync unit starts, so there's a change that in this sharding merge the WHERE clause of UDPATE and DELETE will modify unexpected records.

[GMHDBJD]

currently, we have almost no practical action to operate-schema set a correct schema before sync unit starts, so there's a change that in this sharding merge the WHERE clause of UDPATE and DELETE will modify unexpected records.

I think if we have no error when task starts, user usually don't know they need to set the schema manually.

[lance6716]

currently, we have almost no practical action to operate-schema set a correct schema before sync unit starts, so there's a change that in this sharding merge the WHERE clause of UDPATE and DELETE will modify unexpected records.

I think if we have no error when task starts, user usually don't know they need to set the schema manually.

yes, that proposal can only work with guiding from document.

[lance6716]

closed by #1915