Mangled DML statements on 2nd level slave when enabling binlog checksums

In a two level replication setup that had originally been running with binlog_checksum=NONE enabling binlog_checksum=CRC32 DDL statements executed on the primary master caused SQL execution errors on 2nd level slaves, but not the intermediate master.

DDL statements (seen on CREATE TABLE and ALTER TABLE) failed as there were extra random characters added at the end of the SQL statement text.

Looking at the failing statement with "mysqlbinlog --hexdump" showed that in addition to the expected four checksum bytes (as seen in the binlog event header) four additional bytes had been added between the end of the statement and the checksum bytes.

So it looks as if the intermediate master somehow added a 2nd CRC32 checksum to these events instead of replacing it with a new checksum of its own.

Only DDL statements were affected, probably as only these are replicated as SQL text in ROW format.

Binlog configuration settings were (after binlog checksums were activated):

log-bin          = ../log/binlog

binlog_format    = ROW

sync_binlog      = 1

expire_logs_days = 7

log_slave_updates

max_binlog_size  = 100M

binlog_checksum = CRC32

binlog_ignre_db = ...one database that was not related to the failing statements ...

relay_log = ../log/relaylog

max_relay_log_size = 100M

slave_compressed_protocol = OFF

The failure only occurred in production and could not be reproduced in a local test setup yet ...