Re: OT: MySQL disable logging
Date: Thu, 31 May 2012 13:38:42 +0100
Facebook has talked in the past that they are very heavy users of MySQL replication - so presumably they don't bother to do point-in-time recovery, they just destroy the slave and recreate.
They've also said that they care a lot more about consistent response time than they generally do about individual performance. So, if a query is slow, it needs to always be slow. If a query is fast, it needs to always be fast.
That actually helps suggest Flash as a primary storage mechanism to help insure query consistency. They gave a talk back in 2010 about their MySQL implementation that gives some of their stats:
Query response times: 4ms reads, 5ms writes.
Rows read per second: 450M peak
Network bytes per second: 38GB peak
Queries per second: 13M peak
Rows changed per second: 3.5M peak
InnoDB disk ops per second: 5.2M peak
Obviously, that's across their farm, but they're clearly heavy MySQL users.
On Thu, May 31, 2012 at 1:28 PM, Paul Drake <bdbafh_at_gmail.com> wrote:
> block quote:
> He says: "By leveraging Fusion-io cards and the new SDK, customers can turn
> off this journalling system, since the Fusion-io cards also have a patented
> logging system that protects data in the event of power failure. By turning
> off journalling, management stated that customers can reduce the amount of
> data that is stored by 50 per cent, increase throughput by 33 per cent and
> decrease latency by 50 per cent versus the alternative HDD storage."
> Who wouldn't want to be on a destructive testing team for that one?
> How might point in time or incomplete recovery be performed?