4 ms·
Actually, mostly in an informal matter, we have in fact received many test implementations from maintainers of frameworks directly. If you go through the pull
by bhauer 13y ago
Actually, mostly in an informal matter, we have in fact received many test implementations from maintainers of frameworks directly. If you go through the pull requests, you may recognize some folks. I don't want to name drop though.
I had in passing asked a few if they would be willing to apply an "official" indicator next to their rows. But the response had been uniformly "not interested." Maybe later I'll ask again. :)
Thanks for the notes on the MySQL configuration. There are a lot of gray areas in setting up the configuration, but we do seek recommendations such as these. Aside from concessions we've made to the matter of running a benchmark, the overriding goal for configuration is that "production-class" configuration is preferred.
I'm not an expert at InnoDB tuning, so you might tell me that "innodb_log_flush_at_trx_commit = 1" is not typical for production environments, in which case I'd want to make a change. But if it is typical for production, I'd like to keep it as-is.
If the point is that other databases do not have something comparable, that speaks to the point of the linked blog entry. These things are not directly comparable, feature-by-feature. We would like Postgres and MongoDB to be deployed in a typical "production-class" configuration, but that may or may not be feature-identical with MySQL.
- rsynnott 13y agoIn many production environments where a few lost writes in the event of OS crash aren't entirely the end of the world, innodb_log_flush_at_trx_commit is set to 2. In some it will even be set to 0 (in that instance, data is lost in the event of MySQL crash). If you care deeply about every write definitely hitting disk in a recoverable manner, you set it to 1, but at that point you may have to do other stuff (is the OS lying to you? Is your RAID controller lying to you? Is your disk lying to you?) > If the point is that other databases do not have something comparable, that speaks to the point of the linked blog entry. Other databases do have something comparable. It looks like MongoDB actually doesn't, but that's highly unusual. Postgres does (I believe it's on by default), Riak does, Voldemort does (one could make an argument that it's safer to leave it off in the latter two cases than elsewhere).
- bhauer 13y agoIf I am parsing you right, it sounds like "innodb_log_flush_at_trx_commit = 2" is what you would recommend for a majority of production environments.
- rsynnott 13y agoReally depends on the scenario, but for most web stuff, I'd tend to recommend a setting of 2, if the data durability caveats were acceptable.
- morgo 13y agoDurability will typically be very expensive to implement unless you have a fast SSD or RAID controller with NVRAM, so it will skew the test considerably if you make MySQL offer it, but say MongoDB does not have to. But I do recommend it for the majority of people. Shameless plug: http://www.tocker.ca/2013/06/19/deciding-whether-or-not-to-make-mysql-durable.html http://www.tocker.ca/2013/06/19/deciding-whether-or-not-to-m... Also: http://dom.as/2013/08/09/on-durability/ http://dom.as/2013/08/09/on-durability/ (Domas works on MySQL@Facebook).
- bhauer 13y agoThanks! Just for the record, on our i7 tests, starting with Round 6, we have been using a Samsung 840 Pro SSD for the database server.
- rsynnott 13y agoIncidentally, on the EBS durability thing, it's addressed here: https://forums.aws.amazon.com/thread.jspa?threadID=27590 https://forums.aws.amazon.com/thread.jspa?threadID=27590 - An fsync isn't a guarantee, or wasn't in 2013, but they estimate the risk of loss after fsync to be very low. Can't find anything on whether their newer SSD-providing instances guarantee durability, though.
- morgo 13y agoThat's really cool. Thanks!