[MDEV-13902] Orphan rows despite ON DELETE CASCADE constraint Created: 2017-09-24 Updated: 2019-04-20 Resolved: 2019-04-20 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Affects Version/s: | 10.2.8 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Critical |
| Reporter: | Mark Samman | Assignee: | Unassigned |
| Resolution: | Incomplete | Votes: | 0 |
| Labels: | need_feedback | ||
| Environment: |
Server version: 10.2.8-MariaDB-10.2.8+maria~stretch-log mariadb.org binary distribution |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
This is the same issue I reported in
To answer questions which were asked in the previous issue:
I have attached my.cnf. |
| Comments |
| Comment by Mark Samman [ 2017-09-24 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
Actually it looks like I did have binlogs enabled this time. Although I'm not familiar with the tooling around binlogs, I'll try to figure out how to create a minimal case to reproduce. | |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mark Samman [ 2017-09-24 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
I've tried replaying the binlogs on top of a backup a day before this happened, up until a position a bit after the matchmaking_match entry was deleted. I was unable to reproduce the issue that way, so it seems like the binlog isn't helpful here. Perhaps it would be if I had logs from when the MariaDB server started (~30 days ago), but my binlogs only go a few days back. Note that I did this on a different machine, with a different operating system (OS X), but still with MariaDB 10.2.8 (Server version: 10.2.8-MariaDB Homebrew). | |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2017-09-30 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
Could it happen that these rows remained in the table from the time when the instance was still working on the old unfixed version? | |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mark Samman [ 2017-09-30 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
That doesn't sound like it since I saw the INSERT query for the rows in the binlog around September 21 when the server was already running 10.2.8. I've upgraded to 10.2.9 since reporting this and will report back if it still happens on 10.2.9. | |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2017-10-01 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
Please also check the error log for any suspicious errors and messages, and run CHECK TABLE on the involved tables. This case, if it's really happening, is even stranger than | |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mark Samman [ 2017-10-01 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
The users table does not have any foreign keys. The error log is empty. Running CHECK TABLE shows status OK. The MariaDB server has been restarted since the issue happened though to upgrade to 10.2.9. I'll do another CHECK TABLE and check error logs next time it happens if 10.2.9 is still affected. | |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2017-11-05 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
Samman, did you encounter the problem again and if you did, were you able to collect information as you were going to? | |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mark Samman [ 2017-11-05 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
I have not encountered the problem since reporting this issue. It's possible that my application logic has changed so that it no longer triggers the issue (it's an actively developed project), or that some change in 10.2.9 fixed it. You can close it if you'd like to and I'll open a new one if I spot it again. | |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2017-11-05 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
Samman, I'll close it for now, but JIRA issues are re-open-able, so if you encounter it again, you don't need to create a new one – comment and we will re-open this one. | |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mark Samman [ 2018-02-11 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
I just had this happen again with server version 10.2.12. The most recent DDL was within the past 12 hours, and it was:
It's possible that it's triggered by a bug in my application that uses the Go MySQL driver since there was a memory inconsistency bug last time this happened, and today there was another bug with the buffers used when reading rows from SELECT queries.
| |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Asmir Mustafic [ 2018-10-10 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
I'm facing the same issue with 10.2.11 As a temporary solution I have created a cronjob that daily sets to null the columns having orphan values. But now that we have introduced a slave server, we have the same issue also on the slave... and for now we have also periodically to skip replication errors... | |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Asmir Mustafic [ 2018-10-10 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
Here are my create tables:
From time to time (daily), main_picture_id contains IDs that do not exists in the users_pictures table. | |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Asmir Mustafic [ 2018-10-10 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
CHECK TABLE on both tables did not report any error | |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Marko Mäkelä [ 2019-02-21 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
Samman, goetas, sorry, I only became aware of this report now. Can you please confirm if you are still having the problem with more recent MariaDB? I believe that MariaDB 10.2.13 should have fixed this. |