MySQL 8.0.18 Crash When Importing Large BLOBs with Semi‑Sync Replication and slave_compressed_protocol Enabled

Phenomenon

When executing a 10 MB+ create.sql on a MySQL 8.0.18 primary‑replica setup (one master and two slaves, with one master‑slave pair using semi‑sync replication), the server crashes, while the same script runs fine before the database management platform takes over.

Investigation Process

1. Reproduce in a controlled environment

The test environment mirrors the customer's my.cnf , MySQL version, replication topology, and the exact create.sql . The crash is consistently reproduced, and the error log shows messages such as:

2020-04-28T17:51:47.441886+08:00 0 [ERROR] [MY-013129] [Server] A message intended for a client cannot be sent there as no client-session is attached. ...
2020-04-28T17:51:47.447907+08:00 218 [ERROR] [MY-011161] [Server] Semi-sync master failed on net_flush() before waiting for slave reply.
/opt/mysql/base/8.0.18/bin/mysqld(handle_fatal_signal+0x323) ...

2. Eliminate the management platform’s influence

Disabling the platform’s high‑availability components (latency detection and status queries) stops the crash, indicating they are involved.

3. Identify the role of latency detection

With latency detection enabled, the import runs faster (milliseconds) but crashes; disabling it makes the import slower (~1 s per statement) but stable.

mysql> source /tmp/insert.sql
Query OK, 1 row affected (0.21 sec)
...

mysql> source /tmp/insert.sql
Query OK, 1 row affected (0.01 sec)
Query OK, 1 row affected (1.01 sec)
...

No group‑commit parameters are set, so the behavior resembles group commit but is not configured.

4. Longblob objects

Every crash‑inducing binlog transaction inserts data into the images table, which contains a LONGLOB column storing binary images:

CREATE TABLE `images` (
  `imageid` bigint(20) unsigned NOT NULL,
  `imagetype` int(11) NOT NULL DEFAULT '0',
  `name` varchar(64) NOT NULL DEFAULT '0',
  `image` longblob NOT NULL,
  PRIMARY KEY (`imageid`),
  UNIQUE KEY `images_1` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Extracting only the INSERT statements for this table still reproduces the crash.

5. Impact of slave_compressed_protocol

After extensive parameter testing, the root cause is identified as the replica’s slave_compressed_protocol=ON . When enabled, the replica’s IO thread repeatedly disconnects and reconnects to the master, flooding the master’s binlog dump threads and producing errors such as:

2020-04-29T10:34:42.361584+08:00 1998 [ERROR] [MY-010557] [Repl] Error reading packet from server for channel '': Lost connection to MySQL server during query (server_errno=2013)

Corresponding master logs also show semi‑sync failures.

Related bugs: PS-6876 , MySQL Bug 85382 .

Conclusion

Inserting LONGLOB data.

Using semi‑synchronous replication while other write traffic is present.

Having slave_compressed_protocol=ON .

The crash did not appear before the platform takeover because the database had no concurrent write traffic, effectively disabling the latency detection that mimics the problematic condition.

Solution

Set slave_compressed_protocol=OFF . The variable is deprecated as of MySQL 8.0.18 and will be removed in future releases.

Follow‑up

The team filed a private bug ( MySQL Bug 99607 ) which remains unresolved as of 2021‑12‑28.