Wrong shared schema cause `delete event` loss

[hongyunyan]

1. execute these sqls in upstream cluster

DROP DATABASE IF EXISTS test_100;
CREATE DATABASE test_100;
USE test_100;
CREATE TABLE t1 (a INT, b INT);
INSERT INTO t1 VALUES (1, 2), (2, 3);
ALTER TABLE t1 ADD COLUMN site_code VARCHAR(64) NOT NULL DEFAULT '100';
INSERT INTO t1 VALUES (12, 13, '100');
ALTER TABLE t1 MODIFY COLUMN site_code VARCHAR(64) NOT NULL DEFAULT '';
ALTER TABLE t1 ADD PRIMARY KEY (a, site_code);

DROP DATABASE IF EXISTS test_200;
CREATE DATABASE test_200;
USE test_200;
CREATE TABLE t1 (a INT, b INT);
INSERT INTO t1 VALUES (1, 2), (2, 3);
ALTER TABLE t1 ADD COLUMN site_code VARCHAR(64) NOT NULL DEFAULT '200';
INSERT INTO t1 VALUES (12, 13, '200');
ALTER TABLE t1 MODIFY COLUMN site_code VARCHAR(64) NOT NULL DEFAULT '';
ALTER TABLE t1 ADD PRIMARY KEY (a, site_code);

2. execute these sqls in downstream cluster

DROP DATABASE IF EXISTS test_100;
CREATE DATABASE test_100;
USE test_100;
CREATE TABLE t1 (a INT, b INT, site_code VARCHAR(64) NOT NULL DEFAULT '', PRIMARY KEY (a, site_code));
INSERT INTO t1 VALUES (1, 2, '100'), (2, 3, '100'), (12, 13, '100');

DROP DATABASE IF EXISTS test_200;
CREATE DATABASE test_200;
USE test_200;
CREATE TABLE t1 (a INT, b INT, site_code VARCHAR(64) NOT NULL DEFAULT '', PRIMARY KEY (a, site_code));
INSERT INTO t1 VALUES (1, 2, '200'), (2, 3, '200'), (12, 13, '200');

3. create a changefeed

4. execute these sqls in upstrem cluster

USE test_100;
INSERT INTO t1 (a, b) VALUES (20, 21);
UPDATE t1 SET b = b + 10 WHERE a = 1 AND site_code = '100';
DELETE FROM t1 WHERE a = 2 AND site_code = '100';
UPDATE t1 SET b = b + 1 WHERE a = 12 AND site_code = '100';

USE test_200;
INSERT INTO t1 (a, b) VALUES (20, 21);
UPDATE t1 SET b = b + 10 WHERE a = 1 AND site_code = '200';
DELETE FROM t1 WHERE a = 2 AND site_code = '200';
UPDATE t1 SET b = b + 1 WHERE a = 12 AND site_code = '200';

then you may found data inconsistency in upstream and downstream clusters

[hongyunyan]

Currently, when calculating whether tables can share a schema, neither the calculation of hashTableInfo nor the supplementary validation of sameColumnsAndIndices considers the value of origin_default_value.

This leads to tables sharing the same schema incorrectly when other structures are the same but origin_default_value differs. Furthermore, when the value of this column needs to be decoded and assigned based on origin_default_value, the decoded value becomes incorrect (everyone uses the origin_default_value from one of the tables, instead of their own actual tableInfo's origin_default_value), resulting in unexpected SQL statements and inconsistencies between upstream and downstream data.