Bug #100702 | There are compatibility issues with compression during MySQL5.7 master-slave syn | ||
---|---|---|---|
Submitted: | 1 Sep 2020 1:52 | Modified: | 16 Sep 2020 12:07 |
Reporter: | Wang Wei | Email Updates: | |
Status: | Can't repeat | Impact on me: | |
Category: | MySQL Server | Severity: | S3 (Non-critical) |
Version: | 5.7 | OS: | CentOS (7.2) |
Assigned to: | MySQL Verification Team | CPU Architecture: | x86 |
[1 Sep 2020 1:52]
Wang Wei
[2 Sep 2020 17:50]
MySQL Verification Team
Hi Wang, I do not see what is reported as a bug here. You have shown us an analysis of your system, but what you IMHO need is support from our MySQL Support team to help you properly tune your system. For start, you cannot expect maximum optimization in replication between 5.6 and 5.7 as we are at 8.0 these days. The first thing I would suggest there is to migrate everything to 5.7 or 8.0, but I'd leave our support team to discuss that with you. Also, using a proper tool like MySQL Enterprise Monitor you can see where this delay comes from. Simple replication setup 5.6 to 5.7 with table compression does not show any degradation in a test scenario so you really require system tuning unless you can create a repeatable test case showing we have a bug here. kind regards Bogdan
[3 Sep 2020 0:57]
Wang Wei
I have tested and many times the 5.6 upgrade to version 5.7 this delay problem, and also tried multiple minor versions of MySQL 5.7. This problem has existed for a long time and the root cause of the delay has not been determined, but as long as the master and slave libraries of the two versions are consistent , And the parameter ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8 is enabled in the table, version 5.6 is the master library, 5.7 is the slave library, there will be a lot of delays, and the 5.6 slave library synchronization 5.6 master library will not have a delay, I think The 5.7 version has a compression compatibility problem, which can be reproduced in the case of a large number of batch write operations.
[3 Sep 2020 1:02]
Wang Wei
This problem has appeared for a long time, and I have submitted this problem before (https://bugs.mysql.com/bug.php?id=96091 ), but your reply is no problem, but my recent test found that this delay has a lot to do with the parameter ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8. If you don’t use this, the 5.6 main library uses this parameter, and the 5.7 slave This problem will not occur if the table structure of the library is synchronized without this parameter.
[4 Sep 2020 9:36]
MySQL Verification Team
Hi, I'm not sure I follow. Have you tried both master and slave to be the latest 5.7 with compression turned on? I do not see any performance issues with 5.7 slave.
[16 Sep 2020 2:33]
Wang Wei
If the master and slave are both 5.7 are no problem, but the master is 5.6, this problem will occur when compression is enabled when the slave is 5.7.
[16 Sep 2020 12:07]
MySQL Verification Team
Hi, Replicating from latest 5.6.49 to latest 5.7.31 I cannot reproduce any issues. Anyhow, replicating betweeen 5.6 and 5.7 is not meant to be a permanent solution, you are supposed to use replication between major releases only as a temporary solution until you upgrade them both to same major release so a small performance tradeoff between two major releases is not something I'd consider a bug.