MySql fixes autoincrement bug after 14 years of users complaining about dataloss(bugs.mysql.com)
bugs.mysql.com
MySql fixes autoincrement bug after 14 years of users complaining about dataloss
https://bugs.mysql.com/bug.php?id=199
8 comments
I'd wager that this only got fixed now because some large Oracle customer got bit hard by this bug.
Best comment from the bug report: So we decides to switch on PostreSQL for production...
And 14 1/2 years after the first bug report the bug is fixed and: Thank you for the bug report.
And 14 1/2 years after the first bug report the bug is fixed and: Thank you for the bug report.
This is quite scary, I wonder how many systems I’ve been on that have had minor unnoticed data corruptions because of this. This is truely a weird thing to not fix
Probably because it's not that scary. In practice, it would generally be a non-issue.
1) mysql server restarts are rare. you'd need a delete followed by a restart to trigger this. 2) you may be using soft deletes, which wouldn't trigger this problem anyway. 3) even if an ID gets reused, it may not actually matter (application dependent.)
1) mysql server restarts are rare. you'd need a delete followed by a restart to trigger this. 2) you may be using soft deletes, which wouldn't trigger this problem anyway. 3) even if an ID gets reused, it may not actually matter (application dependent.)
According to the comments it actually is a huge issue and multiple people got their data corrupted.
I've looked at the comments and disagree. For a 15 year old bug, there is actually not that much discussion.
Still, MySQL as any other database has one job, which is keeping data safe. Any issue causing data loss or worse silent data corruption should be considered a critical bug.
There is no data loss caused directly by this bug.
Indirect data loss is still a data loss.
MongoDB gets a lot of bad rep because of it, MySQL supposed to be on a higher standard.
MongoDB gets a lot of bad rep because of it, MySQL supposed to be on a higher standard.
I'm guessing you didn't use MySQL in the late 90's or early 2000's? It was basically the Mongo of its day, before InnoDB and strict SQL mode..
I actually used it, but at the time I didn't know better. I stopped using it when the default engine was still MyISAM, I heard that InnoDB improved it and made it a real database.
Now as you mentioned MongoDB it looks like indeed is a sister DB of MySQL.
1. Written by person (people) who did not know anything about databases and learned about them while working on them.
2. Nearly exclusive choice for hip language at the time (PHP for MySQL, NodeJS for MongoDB)
3. Performed much faster than competitive database only to turn out that it was at the cost of durability
4. New engine that supposed to improve durability (WiredTiger vs InnoDB), but even then, it still is plagued by issues caused by initial bad design.
Now as you mentioned MongoDB it looks like indeed is a sister DB of MySQL.
1. Written by person (people) who did not know anything about databases and learned about them while working on them.
2. Nearly exclusive choice for hip language at the time (PHP for MySQL, NodeJS for MongoDB)
3. Performed much faster than competitive database only to turn out that it was at the cost of durability
4. New engine that supposed to improve durability (WiredTiger vs InnoDB), but even then, it still is plagued by issues caused by initial bad design.
> MongoDB gets a lot of bad rep because of it
What are the claims for mongodb?
What are the claims for mongodb?
I wonder when it was fixed in Percona's MySQL version, as the reporter of this bug founded Percona in the meantime.
The title is a bit clickbaity. The bug doesn’t cause data loss by itself.
curious how they did a shutdown of the db. are they saying in all scenarios this causes an the issue ?
They must be busy over there.
Now for #20786 https://www.youtube.com/watch?v=oAiVsbXVP6k