Re: OT: MySQL disable logging

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.

Matt
On Thu, May 31, 2012 at 1:28 PM, Paul Drake <bdbafh@xxxxxxxxx> wrote:
> http://www.theregister.co.uk/2012/05/31/facebook_fusion_io/
> 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
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
--
http://www.freelists.org/webpage/oracle-l


Other related posts: