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

[5 May 17:41] Matthew Kent
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.
[19 May 13:19] MySQL Verification Team
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
[19 May 13:19] MySQL Verification Team
Test results

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

[20 Jun 1:00] Bugs System
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".