Live data from Hacker News

Clarification on “Call Me Maybe: MariaDB Galera Cluster”

percona.com

11–20 of 73 posts

Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”

#11
post #3

I do not quite like the usage of the word “corrupted” here. For me, the more correct word be to use is “inconsistent”. Aren't we talking about situations in which a database tracking account balances creates money out of thin air, or vaporizes it unexpectedly? I feel like Aphyr is always at pains to talk about the real-world implications of these findings --- not just how bad they are in sensitive applications, but a…

I think the Percona writer is focusing on "corruption" in terms of how I think most database folks imagine "corruption" - where a series of commands will erase a block of data, or make a block of data unrecoverable.

I agree that "inconsistent" is probably more mechanically accurate, but since in this case the side effect of the inconsistency is that you can't trust the contents of a block of data, it seems like a difference without a distinction.

Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”

#12
post #2

> If you use this in a real life, the more obvious way to write these transactions is: Is it? Do ORMs really do that, or is it one of those "SQL was designed to be used this way, but nobody using SQL read the design documents" cases?

> Do ORMs really do that

I haven't seen any, but they do use optimistic locking.

Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”

#13
post #3

I do not quite like the usage of the word “corrupted” here. For me, the more correct word be to use is “inconsistent”. Aren't we talking about situations in which a database tracking account balances creates money out of thin air, or vaporizes it unexpectedly? I feel like Aphyr is always at pains to talk about the real-world implications of these findings --- not just how bad they are in sensitive applications, but a…

I would agree from a database perspective, it's an inconsistency. From the application user's perspective though, the information can get corrupted in the sense that the original intent of the transactions is no longer clear, and can't be recovered. I think it's not always obvious from which perspective Aphyr is writing (database or user), so the meaning could be somewhat ambiguous.

While an unexpected inconsistency like this is certainly bad enough, I tend to agree with Vadim to reserve the word "corruption" for the situation in which the database actually stores garbage data such that it can't actually read back information properly.

Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”

#14
> Following that conclusion is using Galera cluster may result in “corrupted” data. I do not quite like the usage of the word “corrupted” here. For me, the more correct word be to use is “inconsistent”.

But Aphyr never once uses the term "corrupted data", or the word "corrupted". If you're going to quote an article, it's important to be precise.

This response feels panicked, or at least rushed. And it really misses the point. You can't, or shouldn't, try to explain away these types of findings as irrelevant, or just an issue of semantics. Instead, I'd hope by now that technical folks on the receiving end of a Call Me Maybe analysis would have learned that there's precisely one correct way to respond: acknowledge the faults, clarify relevant documentation, and file (and link to) issues in public issue-trackers that will address the problems.

HashiCorp, CoreOS, and arguably Elastic played it correctly. Aerospike, Mesos, and now Percona, didn't. Shame.

Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”

#15
post #13
post #3

I do not quite like the usage of the word “corrupted” here. For me, the more correct word be to use is “inconsistent”. Aren't we talking about situations in which a database tracking account balances creates money out of thin air, or vaporizes it unexpectedly? I feel like Aphyr is always at pains to talk about the real-world implications of these findings --- not just how bad they are in sensitive applications, but a…

I would agree from a database perspective, it's an inconsistency. From the application user's perspective though, the information can get corrupted in the sense that the original intent of the transactions is no longer clear, and can't be recovered. I think it's not always obvious from which perspective Aphyr is writing (database or user), so the meaning could be somewhat ambiguous. While an unexpected inconsistency…

Would it not be preferable for things to break in a piece of banking software rather than be incorrect but no one notices there is a problem. I hope they are trying to fix these issues rather than be sensitive.

Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”

#16
post #2

> If you use this in a real life, the more obvious way to write these transactions is: Is it? Do ORMs really do that, or is it one of those "SQL was designed to be used this way, but nobody using SQL read the design documents" cases?

I think in general when writing applications, you should assume that any data you keep in memory between SQL queries could become stale and change before the next query/update.

Anytime you have to update multiple individual records and rely on calculating state from both of them at once, alarm bells should start going off. Yes, you can start dropping into special transactions but there's also a potential opportunity for a better design.

Unfortunately, all that feels like a huge accidental complexity.

Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”

#17
post #16
post #2

> If you use this in a real life, the more obvious way to write these transactions is: Is it? Do ORMs really do that, or is it one of those "SQL was designed to be used this way, but nobody using SQL read the design documents" cases?

I think in general when writing applications, you should assume that any data you keep in memory between SQL queries could become stale and change before the next query/update. Anytime you have to update multiple individual records and rely on calculating state from both of them at once, alarm bells should start going off. Yes, you can start dropping into special transactions but there's also a potential opportunity…

To some extent, isn't that the whole point of specifying the transaction isolation level you need? So you can make these assumptions?

Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”

#18

> Following that conclusion is using Galera cluster may result in “corrupted” data. I do not quite like the usage of the word “corrupted” here. For me, the more correct word be to use is “inconsistent”. But Aphyr never once uses the term "corrupted data", or the word "corrupted". If you're going to quote an article, it's important to be precise. This response feels panicked, or at least rushed. And it really misses t…

Yes; it's got a bunch of typos and a subtext of barely concealed rage. (e.g. This is a good opportunity for Asphyr to start another FUD “Call Me Maybe: InnoDB”).

Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”

#19

> Following that conclusion is using Galera cluster may result in “corrupted” data. I do not quite like the usage of the word “corrupted” here. For me, the more correct word be to use is “inconsistent”. But Aphyr never once uses the term "corrupted data", or the word "corrupted". If you're going to quote an article, it's important to be precise. This response feels panicked, or at least rushed. And it really misses t…

> But Aphyr never once uses the term "corrupted data", or the word "corrupted". If you're going to quote an article, it's important to be precise.

As opposed to "pedantic"? Here's a quote from the article:

> The probability of data corruption scales with client concurrency, with the duration of transactions, and with the increased probability of intersecting working sets.

Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”

#20
post #16
post #2

> If you use this in a real life, the more obvious way to write these transactions is: Is it? Do ORMs really do that, or is it one of those "SQL was designed to be used this way, but nobody using SQL read the design documents" cases?

I think in general when writing applications, you should assume that any data you keep in memory between SQL queries could become stale and change before the next query/update. Anytime you have to update multiple individual records and rely on calculating state from both of them at once, alarm bells should start going off. Yes, you can start dropping into special transactions but there's also a potential opportunity…

> Yes, you can start dropping into special transactions

Transactions aren't "special" in SQL. You expect that reads and writes within a transaction are kept consistent, unless you have deliberately chosen a weaker serialization level.

Post reply on HN