Bug #111701 Binlog replication optimize

• Submitted: 9 Jul 2023 13:43
• Modified: 10 Jul 2023 5:38
• Reporter: alex xing (OCA)
• Status: Verified
• Category: MySQL Server: Replication
• Severity: S4 (Feature request)
• Version: 8.0.33
• OS: Any
• CPU Architecture: Any

[9 Jul 2023 13:43] alex xing

Description:
For binglog decompression, SQL thread is now responsible. However, this may slow binlog apply and increase the master/replica delay.

What do DBAs think about our online business scenarios:

1. If the replica machine has enough relay-log space  or the CPU is the bottleneck, you can set global relay_log_decompress=ON, to decompress binlog in the I/O thread.

2. If the replica machine has insufficient relay-log space, you can set global relay_log_decompress=OFF to decompress binlog in the sql thread, but this may cause the sql thread to slow down.

How to repeat:
just read the code

Suggested fix:
So I want to add a parameter relay_log_uncompress

1. Decompress binlog in the I/O thread: set global relay_log_decompress = ON
2. Decompress binlog in the sql thread: set global relay_log_decompress = OFF

If you think it makes sense, I'll provide a patch

[10 Jul 2023 5:38] MySQL Verification Team

Hello Alex Xing,

Thank you for the feature request.

regards,
Umesh

[10 Jul 2023 13:11] Frederic Descamps

Hi Alex, 

The current design for decompression using the applier worker threads gives us the possibility to perform this in parallel.

If this decompression would happen on the IO thread (coordinator or receiver thread), it won't be parallel and we loose performance.

It will also be more intensive and we will go back to have multi events per transaction that will be handed over the coordinator thread.

We would like to avoid both of these scenarios.

Now if you have more details on your needs, please add some comments. But as we understand it now, this goes to the opposite direction of what we really want: more parallelism and less communication between coordinator and applier threads.

Regards,