Clarification on “Call Me Maybe: MariaDB Galera Cluster”
41–50 of 73 posts
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#42I 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…
A database maker would say it isn't the database that created the money out of thin air, but the faulty application code that didn't select the right isolation level. Of course, whether it's wise for a database to default to anything except Serializable isolation is another matter.
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#43I 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 dif…
corruption is a really scary word to hear about a database. inconsistency is also bad, but corruption is worse, IMO.
P.S. but, i must add - a DB that says it's isolated, but really isn't, and then says "but these are strange transactions", or the famous "you're doing it wrong!", that's really not cool.
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#44Besides being a super well-written and interesting series technically, the Call Me Maybe blogs have been very revealing as far as different organizations' response to criticism. Especially considering all of the target applications are open source, the project maintainers should be profusely thankful someone has taken the time for such thorough analysis, presumably much deeper than the maintainers themselves appear t…
I really like jerf's take on it [1]: How a project performs today tells you the zeroth derivative of its location. Looking at the commit log tells you about the first derivative. How people react to Call Me Maybe when its about their product gives you a lot of information about the second derivative. [1] https://news.ycombinator.com/item?id=10082099 Edit: username
DoubleTakeException: Unexpected pointer dereference in dbartlett's post on
line 0: got "Jeremy Bowers'", expected "jerf's"
Man that's a weird thing to see unexpectedly....Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#45Buncha people giving me for calling data written through an invariant violation "corrupted state", like somehow it's not garbage.
If TCP checksums don't work right we don't call the packet "inconsistent." We call it corrupt. If a disk shuffles your file's bits? Corrupt.
I use the word corrupt to emphasize that not only has the system up, but you have no way to know your data is now up.
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#46Am I missing something or does this not address the main issue the original article raised: The documentation is simply incorrect. It claims to support SNAPSHOT ISOLATION but does not. The company knows this and even this article says the behaviour "is totally expected". Seems like the first response should be to fix the docs and not claim capabilities beyond what's implemented. (Also it was pretty clear from the ori…
> It is recommended that you avoid using SERIALIZABLE in Galera Cluster.
Aphyr:
> SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE
Eh.
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#47Am I missing something or does this not address the main issue the original article raised: The documentation is simply incorrect. It claims to support SNAPSHOT ISOLATION but does not. The company knows this and even this article says the behaviour "is totally expected". Seems like the first response should be to fix the docs and not claim capabilities beyond what's implemented. (Also it was pretty clear from the ori…
Disclaimer: I work for Percona. The docs are on the galeracluster.com page, which is owned and maintained by another company, so there's no way we could fix those. A staff member from this company (And one of the Galera authors) replied on the original 'Call me maybe' post indicating they would fix the docs, though. I think the 'corruption vs inconsistency' debate could seem as nitpicking, but anybody who has been wo…
I'd suggest that the tone of the article be very clear that the problem described is accurate and isn't trying to be downplayed. Suggesting that Aphyr write another "FUD" article comes across as dismissive of the issue. And that'll make people read more into the corruption/inconsistent comment. (Unfair as it may be.)
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#48Earlier quoted context omitted.
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 dif…
oh, but it is an important difference, i believe. any experienced developer will keep an audit log of transactions somewhere. a corrupted database can be completely lost. an inconsistent one can be later corrected by using the audit trail. corruption is a really scary word to hear about a database. inconsistency is also bad, but corruption is worse, IMO. P.S. but, i must add - a DB that says it's isolated, but really…
If you have a full audit trail you can rebuild the database from scratch so there is no difference between an inconsistent and a corrupted database.
In fact, since the audit trail ought store responses from the database, replaying it may not lead to a corruption but it may lead to an inconsistent database again, or it may be rejected by the system.
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#49Besides being a super well-written and interesting series technically, the Call Me Maybe blogs have been very revealing as far as different organizations' response to criticism. Especially considering all of the target applications are open source, the project maintainers should be profusely thankful someone has taken the time for such thorough analysis, presumably much deeper than the maintainers themselves appear t…
I really like jerf's take on it [1]: How a project performs today tells you the zeroth derivative of its location. Looking at the commit log tells you about the first derivative. How people react to Call Me Maybe when its about their product gives you a lot of information about the second derivative. [1] https://news.ycombinator.com/item?id=10082099 Edit: username
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#50Earlier quoted context omitted.
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 dif…
oh, but it is an important difference, i believe. any experienced developer will keep an audit log of transactions somewhere. a corrupted database can be completely lost. an inconsistent one can be later corrected by using the audit trail. corruption is a really scary word to hear about a database. inconsistency is also bad, but corruption is worse, IMO. P.S. but, i must add - a DB that says it's isolated, but really…
Firstly, there's usually non-trivial amount of time until the inconsistency is discovered, that one modification may be easily followed by many additional modifications that are not simply commutative and "diffuse" the inconsistency to other records. For example if we're talking about bank accounts, you often get interests from that, which is not commutative with simple transfers (multiplication vs. addition). So you can't just compensate for that one error, you'd have to revert all the actions on all the involved accounts.
Secondly, databases are rarely isolated. If you're handling money, chances are you've already submitted the payments to an external payment processor, or perhaps sent data somewhere else (to a different system within the bank, for example). You can't (simply) fix this.
This is why people use constraints or higher transaction isolation levels, and also why the Galera response is amusing and also scary at the same time.