Re: OT: MySQL disable logging

  • From: Matthew Zito <matt@xxxxxxxxxxxxxxxxx>
  • To: bdbafh@xxxxxxxxx
  • 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@xxxxxxxxx> 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."
> Fascinating.
> Who wouldn't want to be on a destructive testing team for that one?
> How might point in time or incomplete recovery be performed?
> Paul
> --

Other related posts: