<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Progress in percents: 0 1 2 3 …</title>
	<atom:link href="http://mituzas.lt/2008/10/26/innodb-crash-recovery/feed/" rel="self" type="application/rss+xml" />
	<link>http://mituzas.lt/2008/10/26/innodb-crash-recovery/</link>
	<description>where ideas come and die</description>
	<lastBuildDate>Fri, 26 Feb 2010 17:15:26 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0-alpha</generator>
	<item>
		<title>By: OurDelta - Builds for MySQL &#187; This week in OurDelta - Vol 2</title>
		<link>http://mituzas.lt/2008/10/26/innodb-crash-recovery/comment-page-1/#comment-188527</link>
		<dc:creator>OurDelta - Builds for MySQL &#187; This week in OurDelta - Vol 2</dc:creator>
		<pubDate>Thu, 06 Nov 2008 00:34:47 +0000</pubDate>
		<guid isPermaLink="false">http://dammit.lt/?p=227#comment-188527</guid>
		<description>[...] the InnoDB recovery code. Surely this can be made faster without a major rewrite. Sure there can be rollbacks also and [...]</description>
		<content:encoded><![CDATA[<p>[...] the InnoDB recovery code. Surely this can be made faster without a major rewrite. Sure there can be rollbacks also and [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Zaitsev</title>
		<link>http://mituzas.lt/2008/10/26/innodb-crash-recovery/comment-page-1/#comment-188429</link>
		<dc:creator>Peter Zaitsev</dc:creator>
		<pubDate>Mon, 27 Oct 2008 07:01:53 +0000</pubDate>
		<guid isPermaLink="false">http://dammit.lt/?p=227#comment-188429</guid>
		<description>Domas,

I wrote about it over a year ago 
http://www.mysqlperformanceblog.com/2007/07/17/innodb-recovery-is-large-buffer-pool-always-better/

And there is MySQL bug filed on it http://bugs.mysql.com/bug.php?id=29847 which is of course classified as Feature request.

The workaround one can often use in this case is to REDUCE innodb_buffer_pool_size  and remove innodb_flush_method=O_DIRECT so OS cache can be used for caching.   This can speed up recovery 10x in some cases.</description>
		<content:encoded><![CDATA[<p>Domas,</p>
<p>I wrote about it over a year ago<br />
<a href="http://www.mysqlperformanceblog.com/2007/07/17/innodb-recovery-is-large-buffer-pool-always-better/" rel="nofollow">http://www.mysqlperformanceblog.com/2007/07/17/innodb-recovery-is-large-buffer-pool-always-better/</a></p>
<p>And there is MySQL bug filed on it <a href="http://bugs.mysql.com/bug.php?id=29847" rel="nofollow">http://bugs.mysql.com/bug.php?id=29847</a> which is of course classified as Feature request.</p>
<p>The workaround one can often use in this case is to REDUCE innodb_buffer_pool_size  and remove innodb_flush_method=O_DIRECT so OS cache can be used for caching.   This can speed up recovery 10x in some cases.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin Burton</title>
		<link>http://mituzas.lt/2008/10/26/innodb-crash-recovery/comment-page-1/#comment-188428</link>
		<dc:creator>Kevin Burton</dc:creator>
		<pubDate>Mon, 27 Oct 2008 06:20:23 +0000</pubDate>
		<guid isPermaLink="false">http://dammit.lt/?p=227#comment-188428</guid>
		<description>Wow... that is REALLY REALLY stupid and NEEDS to be fixed.

It&#039;s also not scalable across cores (obviously) which is why my InnoDB recoveries always use one core.

Dumb dumb dumb.</description>
		<content:encoded><![CDATA[<p>Wow&#8230; that is REALLY REALLY stupid and NEEDS to be fixed.</p>
<p>It&#8217;s also not scalable across cores (obviously) which is why my InnoDB recoveries always use one core.</p>
<p>Dumb dumb dumb.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
