<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Speed up your MySQL replication slaves</title>
	<atom:link href="http://www.xaprb.com/blog/2008/01/13/speed-up-your-mysql-replication-slaves/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.xaprb.com/blog/2008/01/13/speed-up-your-mysql-replication-slaves/</link>
	<description>Stay curious!</description>
	<pubDate>Tue, 07 Oct 2008 03:02:05 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: Xaprb</title>
		<link>http://www.xaprb.com/blog/2008/01/13/speed-up-your-mysql-replication-slaves/#comment-14162</link>
		<dc:creator>Xaprb</dc:creator>
		<pubDate>Mon, 14 Jan 2008 14:10:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.xaprb.com/blog/2008/01/13/speed-up-your-mysql-replication-slaves/#comment-14162</guid>
		<description>Kevin, I wrote more about the workload in the next post.  You're right about in-memory -- it works only if data is lots bigger than memory.</description>
		<content:encoded><![CDATA[<p>Kevin, I wrote more about the workload in the next post.  You&#8217;re right about in-memory &#8212; it works only if data is lots bigger than memory.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin Burton</title>
		<link>http://www.xaprb.com/blog/2008/01/13/speed-up-your-mysql-replication-slaves/#comment-14160</link>
		<dc:creator>Kevin Burton</dc:creator>
		<pubDate>Mon, 14 Jan 2008 10:24:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.xaprb.com/blog/2008/01/13/speed-up-your-mysql-replication-slaves/#comment-14160</guid>
		<description>Another note.  This will NOT fix performance on DBs that are all in memory.  This is how we see most of our performance benefits.</description>
		<content:encoded><![CDATA[<p>Another note.  This will NOT fix performance on DBs that are all in memory.  This is how we see most of our performance benefits.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin Burton</title>
		<link>http://www.xaprb.com/blog/2008/01/13/speed-up-your-mysql-replication-slaves/#comment-14159</link>
		<dc:creator>Kevin Burton</dc:creator>
		<pubDate>Mon, 14 Jan 2008 10:22:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.xaprb.com/blog/2008/01/13/speed-up-your-mysql-replication-slaves/#comment-14159</guid>
		<description>I saw that presentation.  Not much meat there.

Anyway. what's the right load ?  Mostly write bound?</description>
		<content:encoded><![CDATA[<p>I saw that presentation.  Not much meat there.</p>
<p>Anyway. what&#8217;s the right load ?  Mostly write bound?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Xaprb</title>
		<link>http://www.xaprb.com/blog/2008/01/13/speed-up-your-mysql-replication-slaves/#comment-14157</link>
		<dc:creator>Xaprb</dc:creator>
		<pubDate>Mon, 14 Jan 2008 00:22:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.xaprb.com/blog/2008/01/13/speed-up-your-mysql-replication-slaves/#comment-14157</guid>
		<description>Dale, it's actually a bit of a misnomer.  It's not pre-fetching the relay log -- MySQL already does that extremely fast, as you know.  It's pre-executing the write queries as SELECT queries to address precisely the issue you mentioned: single-threaded execution on the slave.

In a bit more detail: pre-executing these queries can, if the conditions are right, cause MySQL to fetch at least some of the necessary data from the disk, so it's already in memory when the slave SQL thread wants to update it.

I should really explain this in more detail.  I'll write another post on the topic and give proper references this time :-)

Chris, you are absolutely correct.</description>
		<content:encoded><![CDATA[<p>Dale, it&#8217;s actually a bit of a misnomer.  It&#8217;s not pre-fetching the relay log &#8212; MySQL already does that extremely fast, as you know.  It&#8217;s pre-executing the write queries as SELECT queries to address precisely the issue you mentioned: single-threaded execution on the slave.</p>
<p>In a bit more detail: pre-executing these queries can, if the conditions are right, cause MySQL to fetch at least some of the necessary data from the disk, so it&#8217;s already in memory when the slave SQL thread wants to update it.</p>
<p>I should really explain this in more detail.  I&#8217;ll write another post on the topic and give proper references this time :-)</p>
<p>Chris, you are absolutely correct.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Xaprb</title>
		<link>http://www.xaprb.com/blog/2008/01/13/speed-up-your-mysql-replication-slaves/#comment-14156</link>
		<dc:creator>Xaprb</dc:creator>
		<pubDate>Mon, 14 Jan 2008 00:19:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.xaprb.com/blog/2008/01/13/speed-up-your-mysql-replication-slaves/#comment-14156</guid>
		<description>Sean, thanks.</description>
		<content:encoded><![CDATA[<p>Sean, thanks.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
