Hacker News Reader

Comment by lmm | Hacker News Reader

Randomly rewriting a file that mysqld has open seems a lot more dangerous than restarting mysqld. What if that was e.g. where mysqld was batching up query results before streaming them to the client? Now you've not merely had a query fail, you've silently sent back incorrect results.

If you can't restart mysqld you have an architectural problem. Your database will go down sometimes and your system should be built to tolerate that.

View on HN

i was just going to write the exact same thing. one should at least have a simple master to master setup for redundancy imho - then these kind of problems are much easier to solve, just restart mysql.

I did not even know this was a thing (without using some less well-known mysql extension like Galera), but just googled and found a brief document from Digital Ocean on exactly how to do this with stock MySQL. And here it is, right in the fine manual, supported since 5.1.18.

I don't know how to ask this more precisely, but how are races and concurrent writes on both masters handled? Is it still "ACID safe" writing across the cluster, or would you use something like this as a hot-spare for promotion in case of failover only?

I bet it's intended for failover. Otherwise there wouldn't be much point in something like Galera.

Yeah. I thought about it, and there is so much work on things like etcd and zookeeper, I would have already heard about it if multi-master MySQL was really a thing worth writing home about. But still, cool to find out they're advertising it.

Good thing the author wasn't randomly rewriting a file, then, and that the file was deleted and inferably unlikely to be used in a critical operation!

Restarting MySQL is a violent operation. For large databases, it can take several minutes. If I can avoid it, I do so, and this was a really clever workaround for an issue that indeed avoided a restart. That's a good thing.

> Good thing the author wasn't randomly rewriting a file, then, and that the file was deleted and inferably unlikely to be used in a critical operation!

That's not at all true. It's very common unix practice to open a file, delete it, and then use it for critical operations.

I find it quite ironic that you and author of the article completely misunderstand what is happening.

Creating then deleting a temporary file is very common technique to make sure that that for will be removed as soon as the application closes it, it also is used to make sure that nothing will tamper with it. I find amusing that author found a way to still tamper with it.

Now depending on what the file was used for either the corrupted files caused database to return corrupted data to the user, write corrupted data to the database, our in the best scenario return error to the application issuing the query.

open's O_TMPFILE (since Linux 3.11) does exactly that without creating a named file and immediately removing it from the filesystem. I don't argue that the other technique isn't common though.

The older technique is probably more common since it is available in older version of Linux and also compatible with other Unix based systems.

That said it still doesn't prevent the author for modifying the file by referencing file descriptor.

Reply on news.ycombinator.com