<?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: Fix of InnoDB/XtraDB scalability of rollback segment</title>
	<atom:link href="http://www.mysqlperformanceblog.com/2009/01/18/partial-fix-of-innodb-scalability-rollback-segments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mysqlperformanceblog.com/2009/01/18/partial-fix-of-innodb-scalability-rollback-segments/</link>
	<description>Everything about MySQL Performance</description>
	<lastBuildDate>Sat, 21 Nov 2009 05:23:57 -0800</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Shirish</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/18/partial-fix-of-innodb-scalability-rollback-segments/comment-page-1/#comment-455129</link>
		<dc:creator>Shirish</dc:creator>
		<pubDate>Sun, 25 Jan 2009 18:25:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=590#comment-455129</guid>
		<description>Vadim,

Peter has a point regarding unpatched innodb compatibility.
My group has recommended may times in increasing the rollback segments, but my concern is that in a mixed server environment (where some servers have patched innodb and some don&#039;t) the user will not be able to move a data files from a crashed (patched) innodb server to an unpatched innodb server and recover. An the unpatched code will not recover from the new segments defined.
Also, giving my.cnf parameter to control segments gives some flexibility but also increases risks if the user didn&#039;t backup my.cnf file then they will not be able to recover (unless you store this somewhere in system space as well).

These may be rare cases but a disclosure that goes along with this feature to educate user on this will be helpful.</description>
		<content:encoded><![CDATA[<p>Vadim,</p>
<p>Peter has a point regarding unpatched innodb compatibility.<br />
My group has recommended may times in increasing the rollback segments, but my concern is that in a mixed server environment (where some servers have patched innodb and some don&#8217;t) the user will not be able to move a data files from a crashed (patched) innodb server to an unpatched innodb server and recover. An the unpatched code will not recover from the new segments defined.<br />
Also, giving my.cnf parameter to control segments gives some flexibility but also increases risks if the user didn&#8217;t backup my.cnf file then they will not be able to recover (unless you store this somewhere in system space as well).</p>
<p>These may be rare cases but a disclosure that goes along with this feature to educate user on this will be helpful.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Baron Schwartz</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/18/partial-fix-of-innodb-scalability-rollback-segments/comment-page-1/#comment-451685</link>
		<dc:creator>Baron Schwartz</dc:creator>
		<pubDate>Thu, 22 Jan 2009 13:37:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=590#comment-451685</guid>
		<description>Paul, the InnoDB owners generally decline to say why they do or don&#039;t do anything, and give no information about what they&#039;re working on until after they release it.  And though their developers are very very smart, and they write good code, they are also insulated from real world needs.  Sometimes there&#039;s a serious need for something in the real world and they don&#039;t see the need for it, so it doesn&#039;t happen even after years of asking.</description>
		<content:encoded><![CDATA[<p>Paul, the InnoDB owners generally decline to say why they do or don&#8217;t do anything, and give no information about what they&#8217;re working on until after they release it.  And though their developers are very very smart, and they write good code, they are also insulated from real world needs.  Sometimes there&#8217;s a serious need for something in the real world and they don&#8217;t see the need for it, so it doesn&#8217;t happen even after years of asking.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: paul</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/18/partial-fix-of-innodb-scalability-rollback-segments/comment-page-1/#comment-451428</link>
		<dc:creator>paul</dc:creator>
		<pubDate>Thu, 22 Jan 2009 07:37:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=590#comment-451428</guid>
		<description>I realize the innodb functionality already exists, and it &quot;appears&quot; to work when enabled, but given the critical nature of this data structure is there any information available publicly for why the innodb owners haven&#039;t already done this?  I failed to find any when just looking.  If there is any chance of it reducing the ability for recovery or proper transaction rollback I would be very unlikely to use a build including it.  Apologies if I sound like I&#039;m putting it down, on the flip side, the results are quite impressive.</description>
		<content:encoded><![CDATA[<p>I realize the innodb functionality already exists, and it &#8220;appears&#8221; to work when enabled, but given the critical nature of this data structure is there any information available publicly for why the innodb owners haven&#8217;t already done this?  I failed to find any when just looking.  If there is any chance of it reducing the ability for recovery or proper transaction rollback I would be very unlikely to use a build including it.  Apologies if I sound like I&#8217;m putting it down, on the flip side, the results are quite impressive.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vadim</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/18/partial-fix-of-innodb-scalability-rollback-segments/comment-page-1/#comment-449579</link>
		<dc:creator>Vadim</dc:creator>
		<pubDate>Tue, 20 Jan 2009 17:19:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=590#comment-449579</guid>
		<description>Dim,

It is not included yet, we are testing this. Along with this we are testing fix for group-commit.
Should be included in XtraDB-release3 in few weeks.</description>
		<content:encoded><![CDATA[<p>Dim,</p>
<p>It is not included yet, we are testing this. Along with this we are testing fix for group-commit.<br />
Should be included in XtraDB-release3 in few weeks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dim</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/18/partial-fix-of-innodb-scalability-rollback-segments/comment-page-1/#comment-449389</link>
		<dc:creator>dim</dc:creator>
		<pubDate>Tue, 20 Jan 2009 13:27:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=590#comment-449389</guid>
		<description>Did already you integrate this patch into XtraDB source? 
and if no - when?..

Rgds,
-Dim</description>
		<content:encoded><![CDATA[<p>Did already you integrate this patch into XtraDB source?<br />
and if no &#8211; when?..</p>
<p>Rgds,<br />
-Dim</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: C.J.</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/18/partial-fix-of-innodb-scalability-rollback-segments/comment-page-1/#comment-448453</link>
		<dc:creator>C.J.</dc:creator>
		<pubDate>Mon, 19 Jan 2009 04:12:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=590#comment-448453</guid>
		<description>Wow.  I like the red line more.  :)</description>
		<content:encoded><![CDATA[<p>Wow.  I like the red line more.  <img src='http://www.mysqlperformanceblog.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Yasufumi</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/18/partial-fix-of-innodb-scalability-rollback-segments/comment-page-1/#comment-448427</link>
		<dc:creator>Yasufumi</dc:creator>
		<pubDate>Mon, 19 Jan 2009 01:40:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=590#comment-448427</guid>
		<description>peter,

InnoDB already has multiple rollback segments code (but not used).
It seems to be stable at least while we use the number of segments statically.
So I implemented this parameter as create_new_db only parameter currently.
(the value must be 0 ~ 255)

We may be able to use the datafile created by this option for unpatched InnoDB also, because it uses InnoDB&#039;s unused code.</description>
		<content:encoded><![CDATA[<p>peter,</p>
<p>InnoDB already has multiple rollback segments code (but not used).<br />
It seems to be stable at least while we use the number of segments statically.<br />
So I implemented this parameter as create_new_db only parameter currently.<br />
(the value must be 0 ~ 255)</p>
<p>We may be able to use the datafile created by this option for unpatched InnoDB also, because it uses InnoDB&#8217;s unused code.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: peter</title>
		<link>http://www.mysqlperformanceblog.com/2009/01/18/partial-fix-of-innodb-scalability-rollback-segments/comment-page-1/#comment-448417</link>
		<dc:creator>peter</dc:creator>
		<pubDate>Mon, 19 Jan 2009 01:10:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=590#comment-448417</guid>
		<description>Vadim,

How stable is this multiple rollback segments code ? 

Also how flexible is this variable ?  Can it be set to any value as a startup option or you need to set it before Innodb tablespace is created ?

I also assume you use this option you can&#039;t run unpatched Innodb on same data files any more, right ?</description>
		<content:encoded><![CDATA[<p>Vadim,</p>
<p>How stable is this multiple rollback segments code ? </p>
<p>Also how flexible is this variable ?  Can it be set to any value as a startup option or you need to set it before Innodb tablespace is created ?</p>
<p>I also assume you use this option you can&#8217;t run unpatched Innodb on same data files any more, right ?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
