<?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: InnoDB logfiles</title>
	<atom:link href="http://www.pythian.com/news/1242/innodb-logfiles/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.pythian.com/news/1242/innodb-logfiles/</link>
	<description>News and views from Pythian DBAs</description>
	<lastBuildDate>Fri, 10 Feb 2012 13:01:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: InnoDB disabled if ib_logfile files corrupted &#124; Binary Sludge</title>
		<link>http://www.pythian.com/news/1242/innodb-logfiles/#comment-731835</link>
		<dc:creator>InnoDB disabled if ib_logfile files corrupted &#124; Binary Sludge</dc:creator>
		<pubDate>Thu, 09 Feb 2012 19:07:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1242/innodb-logfiles#comment-731835</guid>
		<description>[...] had become corrupted and were not recognised, the engine couldn&#8217;t start. These files are the crash recovery logs: The unsung heroes of InnoDB are the logfiles. They are what makes InnoDB automatic crash recovery [...]</description>
		<content:encoded><![CDATA[<p>[...] had become corrupted and were not recognised, the engine couldn&#8217;t start. These files are the crash recovery logs: The unsung heroes of InnoDB are the logfiles. They are what makes InnoDB automatic crash recovery [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: MySQL: Failed Registration of InnoDB as a Storage Engine &#124; Atomic Spin</title>
		<link>http://www.pythian.com/news/1242/innodb-logfiles/#comment-544209</link>
		<dc:creator>MySQL: Failed Registration of InnoDB as a Storage Engine &#124; Atomic Spin</dc:creator>
		<pubDate>Mon, 09 May 2011 21:45:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1242/innodb-logfiles#comment-544209</guid>
		<description>[...] configuration change which can prevent MySQL from starting involves the InnoDB log file size. The InnoDB log file is the &#8216;redo&#8217; or recovery log for the InnoDB storage engine. It contains transactions [...]</description>
		<content:encoded><![CDATA[<p>[...] configuration change which can prevent MySQL from starting involves the InnoDB log file size. The InnoDB log file is the &#8216;redo&#8217; or recovery log for the InnoDB storage engine. It contains transactions [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: [SOLVED] Convert MySQL for Windows files to Linux? - Page 2</title>
		<link>http://www.pythian.com/news/1242/innodb-logfiles/#comment-443701</link>
		<dc:creator>[SOLVED] Convert MySQL for Windows files to Linux? - Page 2</dc:creator>
		<pubDate>Thu, 15 Jul 2010 05:25:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1242/innodb-logfiles#comment-443701</guid>
		<description>[...]  [...]</description>
		<content:encoded><![CDATA[<p>[...]  [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sheeri Cabral</title>
		<link>http://www.pythian.com/news/1242/innodb-logfiles/#comment-375178</link>
		<dc:creator>Sheeri Cabral</dc:creator>
		<pubDate>Wed, 16 Sep 2009 16:26:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1242/innodb-logfiles#comment-375178</guid>
		<description>Amit,

The InnoDB log files do not contain a lot of historical information.

What you want is the binary logs -- if turned on, they will log every change.

An even better solution would be to restore the data from a backup -- I recommend having a consistent physical backup for disaster recovery (file copy of some kind, whether it&#039;s using XtraBackup, InnoDB Hot Backup, having a slave where MySQL is stopped and the files are copied, LVM, etc) AND having a logical backup, doesn&#039;t need to be consistent, for problems like this.

(ie, using mysqldump --skip-extended-insert)

To read the binary logs, use at the mysqlbinlog tool.  http://dev.mysql.com/doc/refman/5.1/en/mysqlbinlog.html</description>
		<content:encoded><![CDATA[<p>Amit,</p>
<p>The InnoDB log files do not contain a lot of historical information.</p>
<p>What you want is the binary logs &#8212; if turned on, they will log every change.</p>
<p>An even better solution would be to restore the data from a backup &#8212; I recommend having a consistent physical backup for disaster recovery (file copy of some kind, whether it&#8217;s using XtraBackup, InnoDB Hot Backup, having a slave where MySQL is stopped and the files are copied, LVM, etc) AND having a logical backup, doesn&#8217;t need to be consistent, for problems like this.</p>
<p>(ie, using mysqldump &#8211;skip-extended-insert)</p>
<p>To read the binary logs, use at the mysqlbinlog tool.  <a href="http://dev.mysql.com/doc/refman/5.1/en/mysqlbinlog.html" rel="nofollow">http://dev.mysql.com/doc/refman/5.1/en/mysqlbinlog.html</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Amit</title>
		<link>http://www.pythian.com/news/1242/innodb-logfiles/#comment-375127</link>
		<dc:creator>Amit</dc:creator>
		<pubDate>Wed, 16 Sep 2009 09:14:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1242/innodb-logfiles#comment-375127</guid>
		<description>i&#039;m faced with a situation which is not a crash but is as bad. Some wrong action on part of our customer triggered some delete statements that resulted in some undesired data loss (the records from that table and all referenced tables got deleted). All the tables in question are InnoDB tables. Is there a way I can get to see those records (possibly to refill them manually on my own)? Wouldn&#039;t the innodb log files have a record of what was inserted in the tables originally? I&#039;m not sure if these log files just contain the data that&#039;s still to be flushed to disk, or do they even keep some historical data. If it&#039;s the later case, I think I should give reading these files a try. So, next question is how to read them? I&#039;ll appreciate any help/pointers on this.</description>
		<content:encoded><![CDATA[<p>i&#8217;m faced with a situation which is not a crash but is as bad. Some wrong action on part of our customer triggered some delete statements that resulted in some undesired data loss (the records from that table and all referenced tables got deleted). All the tables in question are InnoDB tables. Is there a way I can get to see those records (possibly to refill them manually on my own)? Wouldn&#8217;t the innodb log files have a record of what was inserted in the tables originally? I&#8217;m not sure if these log files just contain the data that&#8217;s still to be flushed to disk, or do they even keep some historical data. If it&#8217;s the later case, I think I should give reading these files a try. So, next question is how to read them? I&#8217;ll appreciate any help/pointers on this.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ronald Bradford</title>
		<link>http://www.pythian.com/news/1242/innodb-logfiles/#comment-374168</link>
		<dc:creator>Ronald Bradford</dc:creator>
		<pubDate>Wed, 09 Sep 2009 21:37:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1242/innodb-logfiles#comment-374168</guid>
		<description>@Sandeep.

Using these terms, I&#039;d call the innodb log files the redo logs, and the binary log archive redo logs.</description>
		<content:encoded><![CDATA[<p>@Sandeep.</p>
<p>Using these terms, I&#8217;d call the innodb log files the redo logs, and the binary log archive redo logs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sandeep</title>
		<link>http://www.pythian.com/news/1242/innodb-logfiles/#comment-372561</link>
		<dc:creator>sandeep</dc:creator>
		<pubDate>Mon, 31 Aug 2009 09:09:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1242/innodb-logfiles#comment-372561</guid>
		<description>how we can call these files as redo log files?

i think the best word to describe these files is undo log files ,redo log files are one which we are calling as bin log files because &quot;redo&quot; log files reapplies the changes</description>
		<content:encoded><![CDATA[<p>how we can call these files as redo log files?</p>
<p>i think the best word to describe these files is undo log files ,redo log files are one which we are calling as bin log files because &#8220;redo&#8221; log files reapplies the changes</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sheeri Cabral</title>
		<link>http://www.pythian.com/news/1242/innodb-logfiles/#comment-288450</link>
		<dc:creator>Sheeri Cabral</dc:creator>
		<pubDate>Thu, 09 Oct 2008 19:35:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1242/innodb-logfiles#comment-288450</guid>
		<description>Newbie:

According to:
&lt;a HREF=&quot;http://forge.mysql.com/wiki/MySQL_Internals_Files_In_InnoDB_Sources&quot; rel=&quot;nofollow&quot;&gt;http://forge.mysql.com/wiki/MySQL_Internals_Files_In_InnoDB_Sources&lt;/A&gt;, the undo logs are inside the tablespace.  

And sadly there isn&#039;t an easy way to see what&#039;s in the logfile, though it is possible (I don&#039;t know how, but Heikki can do it!)</description>
		<content:encoded><![CDATA[<p>Newbie:</p>
<p>According to:<br />
<a HREF="http://forge.mysql.com/wiki/MySQL_Internals_Files_In_InnoDB_Sources" rel="nofollow">http://forge.mysql.com/wiki/MySQL_Internals_Files_In_InnoDB_Sources</a>, the undo logs are inside the tablespace.  </p>
<p>And sadly there isn&#8217;t an easy way to see what&#8217;s in the logfile, though it is possible (I don&#8217;t know how, but Heikki can do it!)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gerry Narvaja</title>
		<link>http://www.pythian.com/news/1242/innodb-logfiles/#comment-285444</link>
		<dc:creator>Gerry Narvaja</dc:creator>
		<pubDate>Fri, 03 Oct 2008 03:40:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1242/innodb-logfiles#comment-285444</guid>
		<description>&quot;Note that some filesystems are not honest about flushing to disk, so even though you may have the default value of 1, your system may be acting as if it has a value of 2. Setting this parameter to 2 means that there will be less I/O, at the cost of not being able to recover data from a crash.&quot;

The most &#039;dis-honest&#039; filesystems are the ones across a network. The issue is that every software, firmware and hardware layer has physical limitation when it comes to speed, so everyone caches. The DB, the OS, the hard drive, the network card and every one layer tells the rest it&#039;s ready, when actually the data is still in memory.

Storage manufacturers have been aware of this for a long time, so now you may find that some storage appliances have &#039;battery backed up memory&#039;, which means that even if the power goes down, the cache will still be there to be applied for a some period of time. This way, when the hardware gets powered again, it can complete the write. Kind of how the pagers retain the messages for a while to give you time to change the battery.

Keep this in mind when you choose whether 0, 1 or 2 is the right value for your your &quot;innodb_flush_log_at_trx_commit&quot;. Without forgetting that you&#039;ll have to compromise security vs performance. My $.02.</description>
		<content:encoded><![CDATA[<p>&#8220;Note that some filesystems are not honest about flushing to disk, so even though you may have the default value of 1, your system may be acting as if it has a value of 2. Setting this parameter to 2 means that there will be less I/O, at the cost of not being able to recover data from a crash.&#8221;</p>
<p>The most &#8216;dis-honest&#8217; filesystems are the ones across a network. The issue is that every software, firmware and hardware layer has physical limitation when it comes to speed, so everyone caches. The DB, the OS, the hard drive, the network card and every one layer tells the rest it&#8217;s ready, when actually the data is still in memory.</p>
<p>Storage manufacturers have been aware of this for a long time, so now you may find that some storage appliances have &#8216;battery backed up memory&#8217;, which means that even if the power goes down, the cache will still be there to be applied for a some period of time. This way, when the hardware gets powered again, it can complete the write. Kind of how the pagers retain the messages for a while to give you time to change the battery.</p>
<p>Keep this in mind when you choose whether 0, 1 or 2 is the right value for your your &#8220;innodb_flush_log_at_trx_commit&#8221;. Without forgetting that you&#8217;ll have to compromise security vs performance. My $.02.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: newbie</title>
		<link>http://www.pythian.com/news/1242/innodb-logfiles/#comment-285179</link>
		<dc:creator>newbie</dc:creator>
		<pubDate>Thu, 02 Oct 2008 16:16:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1242/innodb-logfiles#comment-285179</guid>
		<description>Hi Sheeri,
         How about the undo log what are they ? Where are they written? Can we see exactly what is the content in the ib_logfile ? Thanks.</description>
		<content:encoded><![CDATA[<p>Hi Sheeri,<br />
         How about the undo log what are they ? Where are they written? Can we see exactly what is the content in the ib_logfile ? Thanks.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

