Replication regression with RBR and partitioned tables
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
MySQL Server |
Unknown
|
Unknown
|
||||
Percona Server moved to https://jira.percona.com/projects/PS | Status tracked in 5.7 | |||||
5.5 |
Invalid
|
Undecided
|
Unassigned | |||
5.6 |
Fix Released
|
High
|
Unassigned | |||
5.7 |
Fix Released
|
High
|
Unassigned |
Bug Description
There is a regression in replication performance in MySQL community 5.6 and 5.7 when using partitioned and large tables. Also, affects Percona Server 5.6 and 5.7.
In MySQL 5.5.35, large updates over partitioned and large tables are executed in slave instances at same speed than in master.
When executing same large updates in MySQL 5.6.35 or 5.7.17, replication performance slows down and slave instance gets behind master for a long time.
If I remove paritioning for this table in slave instance in MySQL 5.6 or 5.7, replication performance is the same as showed in MySQL 5.5.
I've attached a file with a procedure to reproduce this issue.
Requirements:
A) Master is using based row replication.
Procedure:
1) Create a partitioned and large table in MySQL 5.6, for example.
2) Insert random data in the table.
3) Execute large update in this table.
4) Check replication lag using show slave status. Compare replication performance with MySQL version 5.5 or with unpartitioned table.
Is there an upstream bug?