<?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: A Critical Warning If You Are Using InnoDB Hot Backup</title>
	<atom:link href="http://www.pythian.com/news/1485/a-critical-warning-if-you-are-using-innodb-hot-backup/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.pythian.com/news/1485/a-critical-warning-if-you-are-using-innodb-hot-backup/</link>
	<description>News and views from Pythian DBAs</description>
	<lastBuildDate>Thu, 18 Mar 2010 00:27:25 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Ken Jacobs</title>
		<link>http://www.pythian.com/news/1485/a-critical-warning-if-you-are-using-innodb-hot-backup/#comment-341512</link>
		<dc:creator>Ken Jacobs</dc:creator>
		<pubDate>Mon, 16 Feb 2009 23:03:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1485/a-critical-warning-if-you-are-using-innodb-hot-backup#comment-341512</guid>
		<description>I&#039;ve closed the bug, and we have posted the corrected Perl script on our website: http://www.innodb.com/downloads/.

Thanks again for reporting this ...</description>
		<content:encoded><![CDATA[<p>I&#8217;ve closed the bug, and we have posted the corrected Perl script on our website: <a href="http://www.innodb.com/downloads/" rel="nofollow">http://www.innodb.com/downloads/</a>.</p>
<p>Thanks again for reporting this &#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ken Jacobs</title>
		<link>http://www.pythian.com/news/1485/a-critical-warning-if-you-are-using-innodb-hot-backup/#comment-340710</link>
		<dc:creator>Ken Jacobs</dc:creator>
		<pubDate>Sat, 14 Feb 2009 23:19:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1485/a-critical-warning-if-you-are-using-innodb-hot-backup#comment-340710</guid>
		<description>Sheeri,

Thanks for fully describing the issue here and explaining that the backups were performed correctly and where people can find the binary log file and position information. 

As you say, the problem you experienced is due to the de-support of the keyword TYPE in the innobackup script.  Instead of 

CREATE TABLE ibbackup_binlog_marker(a INT) TYPE=INNODB;

it should use

CREATE TABLE ibbackup_binlog_marker(a INT) ENGINE=INNODB;

The technical issues are addressed in the bug report you posted (Bug #42812). We thank you for filing the bug report and posting this note, as well as your comment that the &quot;product works well&quot;.

However, I&#039;d like to briefly address a couple of related things.

1. MySQL does not distribute or support InnoDB Hot Backup.  You won&#039;t find a &quot;category&quot; for it in the bug database.

2. Please use the InnoDB Forums at http://forums.innodb.com/ to interact with the InnoDB team, especially about products like InnoDB Hot Backup and the InnoDB Plugin, which MySQL is not (yet?) distributing or supporting.  [Besides, since we know you ;-) you could also contact us directly by email.]

3. I think it worth mentioning that the real &quot;bug&quot; here was caused by a rather unnecessary change in the syntax MySQL supports.  You said, &quot;Thereâ€™s no reason for ibbackup to continue to use TYPE&quot;.  It could equally well be said, &quot;There was no reason to deprecate this syntax.&quot;  In fact, Mark Callaghan said it very well in a post to the MySQL internals mail list back in November 2007: http://lists.mysql.com/internals/35180.   This sort of gratuitous change causes hassle and expense for everyone.  Upward compatibility is a really good idea.

4. Lastly, I don&#039;t understand your comment that InnoDB Hot Backup &quot;is much more expensive than it warrants&quot;.  InnoDB Hot Backup is the only product available today that can backup MySQL/InnoDB databases (including MyISAM tables) with little to no disruption of on-going operations.  It is feature-rich, reliable and fast.  It is selling well as a commercially-licensed product (and obviously the buyers don&#039;t agree that it is &quot;much more expensive&quot; than it warrants.  ;-)

Thanks for listening!</description>
		<content:encoded><![CDATA[<p>Sheeri,</p>
<p>Thanks for fully describing the issue here and explaining that the backups were performed correctly and where people can find the binary log file and position information. </p>
<p>As you say, the problem you experienced is due to the de-support of the keyword TYPE in the innobackup script.  Instead of </p>
<p>CREATE TABLE ibbackup_binlog_marker(a INT) TYPE=INNODB;</p>
<p>it should use</p>
<p>CREATE TABLE ibbackup_binlog_marker(a INT) ENGINE=INNODB;</p>
<p>The technical issues are addressed in the bug report you posted (Bug #42812). We thank you for filing the bug report and posting this note, as well as your comment that the &#8220;product works well&#8221;.</p>
<p>However, I&#8217;d like to briefly address a couple of related things.</p>
<p>1. MySQL does not distribute or support InnoDB Hot Backup.  You won&#8217;t find a &#8220;category&#8221; for it in the bug database.</p>
<p>2. Please use the InnoDB Forums at <a href="http://forums.innodb.com/" rel="nofollow">http://forums.innodb.com/</a> to interact with the InnoDB team, especially about products like InnoDB Hot Backup and the InnoDB Plugin, which MySQL is not (yet?) distributing or supporting.  [Besides, since we know you ;-) you could also contact us directly by email.]</p>
<p>3. I think it worth mentioning that the real &#8220;bug&#8221; here was caused by a rather unnecessary change in the syntax MySQL supports.  You said, &#8220;Thereâ€™s no reason for ibbackup to continue to use TYPE&#8221;.  It could equally well be said, &#8220;There was no reason to deprecate this syntax.&#8221;  In fact, Mark Callaghan said it very well in a post to the MySQL internals mail list back in November 2007: <a href="http://lists.mysql.com/internals/35180" rel="nofollow">http://lists.mysql.com/internals/35180</a>.   This sort of gratuitous change causes hassle and expense for everyone.  Upward compatibility is a really good idea.</p>
<p>4. Lastly, I don&#8217;t understand your comment that InnoDB Hot Backup &#8220;is much more expensive than it warrants&#8221;.  InnoDB Hot Backup is the only product available today that can backup MySQL/InnoDB databases (including MyISAM tables) with little to no disruption of on-going operations.  It is feature-rich, reliable and fast.  It is selling well as a commercially-licensed product (and obviously the buyers don&#8217;t agree that it is &#8220;much more expensive&#8221; than it warrants.  ;-)</p>
<p>Thanks for listening!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Keith Murphy</title>
		<link>http://www.pythian.com/news/1485/a-critical-warning-if-you-are-using-innodb-hot-backup/#comment-339852</link>
		<dc:creator>Keith Murphy</dc:creator>
		<pubDate>Fri, 13 Feb 2009 03:11:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1485/a-critical-warning-if-you-are-using-innodb-hot-backup#comment-339852</guid>
		<description>Thanks Sheeri. That is a great catch!</description>
		<content:encoded><![CDATA[<p>Thanks Sheeri. That is a great catch!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
