Brandon Nesterenko added a comment - 2025-03-13 20:53 - edited monty Enums are also broken. That is, if the slave modified its table's enums to have different ordering than the master, the enums are picked based on index, rather than value. Modifying your skr.test to instead test enums shows this: --source include/have_innodb.inc --source include/have_binlog_format_row.inc --source include/master-slave.inc   CREATE TABLE t1 (a INT PRIMARY KEY, en ENUM('a','b','c')) ENGINE = innodb; INSERT INTO t1 VALUES(100,'a'), (200,'b');   --sync_slave_with_master   --connection slave alter table t1 modify column en enum ('a','d', 'b', 'c');   connection master;   INSERT INTO t1 VALUES(300, 'b');   --sync_slave_with_master select * from t1;   connection master;   update t1 set en='b' where A=100;   --sync_slave_with_master select * from t1;   connection master; --source include/rpl_end.inc The slave's result (where rows with a=100 and a=300 should both actually have value b , but show d because of the re-arrangement: a en 100 d 200 b 300 d Note too that binlog_row_metadata=FULL will also print the expectations for the ENUMs, so we can use this to reference the desired enum value. #250313 14:49:07 server id 1 end_log_pos 944 CRC32 0x2167fc1b Table_map: `test`.`t1` mapped to number 33 # Columns(`a` INT NOT NULL, # `en` ENUM('a','b','c') CHARSET latin1 COLLATE latin1_swedish_ci) # Primary Key(a)

Brandon Nesterenko added a comment - 2025-04-01 21:07 serg , elenst : I discussed this with Monty, and here is the summary of our chat: The use case is limited to multi-master, with a distributed dataset where different masters update the same table but work on distinct ranges of data. So if one node runs an ALTER TABLE which re-arranges the order of the columns to be inconsistent with its master, then when that node replicates insert/update row events that target its altered table from its master, there will indeed be data loss. This should be fixed in 10.6, as we have many users/customers that run this topology running in 10.6, and the fix should be relatively easy with low risk. That is, to populate the fields of table->record [0] during unpacking using column names, rather than column indices. The patch applied in 10.6 should be relatively small; and any complex edge cases (e.g. enums) should just report as errors in 10.6, with fixes to be handled in newer versions. The patch in 10.6 can leverage ideas from the ONLINE ALTER work, and then in some 11.4+, the code can instead leverage the actual ONLINE ALTER code. To the risk, this work will break functionality if a slave renames columns from its master. Currently, this use-case works as long as the column index is in the same location. With this patch, we will not be able to find the column on the slave-side table to write to. Monty says this is not a practical case though, and that users don't/wouldn't actually do this.