MySQL Bugs: #118116: HA_ERR_CORRUPT_EVENT on replication from datetime -> datetime(6)

Bug #118116	HA_ERR_CORRUPT_EVENT on replication from datetime -> datetime(6)
Submitted:	5 May 17:41	Modified:	19 Jun 13:19
Reporter:	Matthew Kent	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S1 (Critical)
Version:	8.0.41	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
We're trying to convert our app to use fractional seconds precision in datetime fields.

After updating a table on the replica from datetime to datetime(6), the next insert on the primary to a datetime field will stop GTID replication with:

LAST_ERROR_NUMBER: 1105
LAST_ERROR_MESSAGE: Worker 1 failed executing transaction 'bf8df0ed-d2c7-11ef-a399-525400f179d8:98160031' at source log binlog.009306, end_log_pos 1001942070; Could not execute Write_rows event on table tadalist_production.demo; Unknown error, Error_code: 1105; handler error HA_ERR_CORRUPT_EVENT; the event's source log binlog.009306, end_log_pos 1001942070

This event corresponds to the datetime insert attempt on the replica. I can pull the exact binlog event if that's useful.

We have @@replica_type_conversions set to ALL_NON_LOSSY, so during replication I'd expect the datetime(6) timestamps on the replica to just not have fractional seconds precision, eg: '2025-05-05 16:57:31.000000'. 

How to repeat:
# With GTID ROW based replication already established
#
# On the primary

CREATE TABLE `demo` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `created_at` datetime NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

insert into demo (created_at) values (now());
insert into demo (created_at) values (now());
insert into demo (created_at) values (now());

# On the replica

set sql_log_bin = 0;
ALTER TABLE `demo` CHANGE `created_at` `created_at` datetime(6) NOT NULL;

# Back on the primary

insert into demo (created_at) values (now());

# Replication halts with a error code 1105

Suggested fix:
Allow replication from datetime -> datetime(6) by setting the missing fractional seconds to 0.

Hello Matthew Kent,

Thank you for the report and test case.
I'm able to reproduce the reported issue but it looks like an expected behaviour i.e When replica_type_conversions or slave_type_conversions is not set, no attribute promotion or demotion is permitted; this means that all columns in the source and target tables must be of the same types. 

Please see https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-features-different-...

Could you please share exact configuration from both source and replica? Thank you.
I'll be joining the test results shortly for your reference.

regards,
Umesh

Test results

Attachment: 118116.results.txt (text/plain), 16.78 KiB.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".