Currently when primary column (or partial column from composite PK) changes via an UPDATE statement, Debezium creates two events in following order: a CREATE with the new key and DELETE with the old key. This is OK, because the message keys are different, so compaction (and stuff like that) won't result in data loss. But, in cases when actual table's primary key is artificial (in our case composite primary key stands just for keeping physical records in needed order – order by optimization) and there is another real primary key (represented as unique index) that is immutable and used everywhere. So, in this case Debeziums PK (that is derived from MySQL PK) doesn't correspond to real (immutable identifier) and CREATE/DELETE events simply wipe out data permanently.

Please, change order of originated Debezium events from CREATE->DELETE to DELETE->CREATE so downstream consumers won't erase data for database update actions.