[MDEV-5380] binlog row format and table without PK Created: 2013-12-03 Updated: 2013-12-03 Resolved: 2013-12-03 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | None |
| Affects Version/s: | 5.5.34 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Nicolas Payart | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | upstream | ||
| Environment: |
Using MariaDB Generic Linux packages on Debian Wheezy 64-bits |
||
| Description |
|
I set a replication master -> slave. Then, I switch binlog format to ROW => On slave, it takes a very long time to apply changes (on my original table with 200'000 rows, I skipped the query (with SQL_SLAVE_SKIP_COUNTER) after 20 minutes still in "Reading event from the relay log" state...). If I create a primary key, changes are applied instantly on slave. Here is a test case to reproduce the problem : MASTER
SLAVE
|
| Comments |
| Comment by Elena Stepanova [ 2013-12-03 ] |
|
It's not really surprising though, is it? You run one update on the master, it triggers 200,000 updates on the slave, each of which has to look up a row without any index. Is there any particular reason why you choose not to use a PK? MySQL bug report for the reference (there were many before and after, but I think this one is most representative): |
| Comment by Nicolas Payart [ 2013-12-03 ] |
|
Thank you Elena. Yes of course, without PK I now realize that slave must scan all rows to apply changes. I thought it had some internal id or whatever to identify each row but it is not... Well, another good reason to always create a PK! |
| Comment by Elena Stepanova [ 2013-12-03 ] |
|
Closing for now as "won't fix". Hopefully in future versions there will be improvements in the area. |