MySQL Bugs: #105346: Replication Failures in 5.7.32

Bug #105346	Replication Failures in 5.7.32 - Unknown Consequences
Submitted:	27 Oct 2021 17:35	Modified:	15 Dec 2021 14:17
Reporter:	David Cosgrove	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: Row Based Replication ( RBR )	Severity:	S2 (Serious)
Version:	5.7.32	OS:	CentOS (CentOS Linux release 7.9.2009 (Core))
Assigned to:	MySQL Verification Team	CPU Architecture:	Other (8 Processors)

Description:
When trying to operate row-based replication between our commercial application backed by a single "Source" MySQL instance and replicated to a single "Replica", the replication periodically fails with the following 2 errors.  Worth noting, there seems to be no evidence of these errors on the "Source" instance (the errors only appear in the .err file of the "Replica).

Below are the following 2 errors.  What is most important for us to understand as soon as possible is whether these errors indicate a corruption of the Replica's state or are these 2 errors benign and can be safely ignored/skipped.  

>>>>>>>

Last_SQL_Errno: 1517

               Last_SQL_Error: Error 'Duplicate partition name p20211022' on query. Default database: 'em'. Query

: 'ALTER TABLE `event_identifiers` REORGANIZE PARTITION pMAX INTO (PARTITION p20211022 VALUES LESS THAN (16349472

00), PARTITION pMAX VALUES LESS THAN MAXVALUE)'

 

2021-10-21T15:22:20.770067Z 5 [Note] Slave SQL for channel '': Could not execute Query event. Detailed error: Duplicate partition name p20211022;, Error_code: 1517

 

>>>>>>

(Error Code 1677)

Last_Error: Column 3 of table 'netqosportal.temp_highest' cannot be converted from type 'varchar(765(bytes))' to type 'varchar(255(bytes) latin1)'

>>>>>>

How to repeat:
Install our commercial product and enable row-based replication between a single Source and single Replica. my.cnf files for Source and Replica can be furnished upon request.

Periodically, we are receiving the errors above (either of which stop replication from processing).  Worth noting, if these errors are ignored by the replica, replication appears to stay running for days while our application is being utilized.

This reported bug seems to be related to one of the two I have reported:

https://bugs.mysql.com/bug.php?id=83461

Hi David,

Wrt your report:1517, how often do you do this reorganize partition and does it fail every time or only sometimes? Can you share the full config from both master and slave.

Wrt your report:1677 this looks like netqosportal is utf8 on one side and latin1 on other side or something similar. What does 
SHOW CREATE TABLE netgosportal\G 
show on both master and slave? What is the default character set for the schema these tables are in on master and on slave?

This part of the bug seems to be duplicate of Bug#83461 

Thanks

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".