Bug #117660 MySQL 8.4.2: InnoDB Assertion Failure on ha_innodb.cc:11675 Due to strlen(m_remote_path) != 0 After Promoting Replica

• Submitted: 11 Mar 4:23
• Modified: 11 Mar 23:06
• Reporter: System Management
• Status: Can't repeat
• Category: MySQL Server: Replication
• Severity: S2 (Serious)
• Version: 8.4.2
• OS: Oracle Linux (8.10)
• Assigned to: MySQL Verification Team
• CPU Architecture: x86

[11 Mar 4:23] System Management

Description:
In a MySQL chain replication setup using non-GTID-based replication (8.0 → 8.4 → 8.4), promoting the first MySQL 8.4.2 server (8.4(A)) to master resulted in a critical assertion failure when executing TRUNCATE TABLE on a replicated table. The error suggests that the issue is related to an empty m_remote_path in ha_innodb.cc.

How to repeat:
Replication Setup:
- Primary (8.0) → Intermediate Replica (8.4(A)) → Replica (8.4(B)).
- Replication configured using binary logs (non-GTID).
After promoting 8.4(A) as the master, the issue occurred during table truncation.- 

Steps to Reproduce:
1. Set up chain replication.
   - 8.0 (Master) → 8.4(A) (Intermediate Replica) → 8.4(B) (Final Replica).
   - Replication configured using binary log position, not GTID.
2. Promote the intermediate replica (8.4(A)) to master by executing.
3. Attempt to truncate a replicated table.
   TRUNCATE TABLE customer_profile_change;
4. MySQL 8.4(A) crashes with the following assertion failure.

[ERROR] [MY-013183] [InnoDB] Assertion failure: ha_innodb.cc:11675:strlen(m_remote_path) != 0 thread 140076469708544
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace.

mysqld got signal 6;
Query (7f60840cb450): truncate table customer_profile_change
Connection ID (thread ID): 8
Status: NOT_KILLED

[11 Mar 23:06] MySQL Verification Team

Hi,

I need more details to reproduce this as setting the following replication

8.0.41 -> 8.4.4 -> 8.4.4

I create and fill tables using client connected to 8.0.41, everything works ok. I shutdown the 8.0.41, migrate connection to 8.4.4 and truncate few tables, everything works ok and replicates to second 8.4.4

So please help me make a reproducible test case as using general config and general data this is not reproducible.

Thanks