MySQL Bugs: #106438: Contribution by Tencent: Automatically execute relay log recovery in replica

Bug #106438	Contribution by Tencent: Automatically execute relay log recovery in replica
Submitted:	11 Feb 2022 4:50	Modified:	11 Feb 2022 7:05
Reporter:	Xiaodong Huang (OCA)	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S4 (Feature request)
Version:	8.0	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
After Replica crash and restart,  if Replica is with the option [relay_log_recovery= on](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_relay_log_...), it will automatically skip the relay log which haven’t been executed. At the same time, it have the risk of lossing data if Source start unsuccessfully after crash or communication failed between Source and Replica.

E.g: a Replica have the relay log: relay-bin.000001,relay-bin.000002,...,relay-bin.000022,relay-bin.000023. The Relay_Log_File and Relay_Log_Pos respectively are relay-bin.000002 and 1508 in the statement "show replica status" at Replica. if Source restart unsuccessfully and the Replica crash at the same time, the relay log from relay-bin.000002 to relay-bin.000023 will be skipped and the data that exist in the relay log will be lost.

How to repeat:
Description as above.

Suggested fix:
The main purpose of the option “relay_log_recovery" is in order to avoid read the partial binlog event and transaction that often appear in the end of last binlog file. So we can provide extra option "relay_log_recovery=auto" which means execute relay log recovery only if the relay log have partial binlog event and transaction otherwise not execute the recovery.

Hello Xiaodong,

Thank you for the feature request.

regards,
Umesh

the feature contributed by TXSQL Team of Tencent

The previous comment "the feature contributed by TXSQL Team of Tencent" is corrected as "the feature request contributed by TXSQL Team of Tencent".