<?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: ZFS Replication for MySQL data</title>
	<atom:link href="http://coalface.mcslp.com/2008/11/09/zfs-replication-for-mysql-data/feed/" rel="self" type="application/rss+xml" />
	<link>http://coalface.mcslp.com/2008/11/09/zfs-replication-for-mysql-data/</link>
	<description>Thoughts from the bleeding edge of the MCslp keyboards</description>
	<lastBuildDate>Mon, 30 Aug 2010 19:30:28 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Mark Callaghan</title>
		<link>http://coalface.mcslp.com/2008/11/09/zfs-replication-for-mysql-data/comment-page-1/#comment-7689</link>
		<dc:creator>Mark Callaghan</dc:creator>
		<pubDate>Tue, 18 Nov 2008 21:01:25 +0000</pubDate>
		<guid isPermaLink="false">http://coalface.mcslp.com/?p=154#comment-7689</guid>
		<description>Maybe I am being pedantic, but what you have described is a full backup followed by a sequence of incremental backups. I would not call this replication. It is still interesting.</description>
		<content:encoded><![CDATA[<p>Maybe I am being pedantic, but what you have described is a full backup followed by a sequence of incremental backups. I would not call this replication. It is still interesting.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave Edwards</title>
		<link>http://coalface.mcslp.com/2008/11/09/zfs-replication-for-mysql-data/comment-page-1/#comment-7685</link>
		<dc:creator>Dave Edwards</dc:creator>
		<pubDate>Fri, 14 Nov 2008 19:26:53 +0000</pubDate>
		<guid isPermaLink="false">http://coalface.mcslp.com/?p=154#comment-7685</guid>
		<description>&lt;a href=&quot;http://www.pythian.com/blogs/1359/log-buffer-123-a-carnival-of-the-vanities-for-dbas&quot; rel=&quot;nofollow&quot;&gt;Martin ‘MC’ Brown of MCslp Coalface takes on the matter of ZFS Replication for MySQL data.&lt;/a&gt;</description>
		<content:encoded><![CDATA[<p><a href="http://www.pythian.com/blogs/1359/log-buffer-123-a-carnival-of-the-vanities-for-dbas" rel="nofollow">Martin ‘MC’ Brown of MCslp Coalface takes on the matter of ZFS Replication for MySQL data.</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Martin MC Brown</title>
		<link>http://coalface.mcslp.com/2008/11/09/zfs-replication-for-mysql-data/comment-page-1/#comment-7682</link>
		<dc:creator>Martin MC Brown</dc:creator>
		<pubDate>Tue, 11 Nov 2008 08:59:16 +0000</pubDate>
		<guid isPermaLink="false">http://coalface.mcslp.com/?p=154#comment-7682</guid>
		<description>Matthew: 

Yes, AVS is the way to go for a more complete DRBD-like solution, and I&#039;m working on an AVS blog post at the moment.

However, AVS is limited to OpenSolaris at the moment, and basic ZFS replication can be used on OS X and FreeBSD too.</description>
		<content:encoded><![CDATA[<p>Matthew: </p>
<p>Yes, AVS is the way to go for a more complete DRBD-like solution, and I&#8217;m working on an AVS blog post at the moment.</p>
<p>However, AVS is limited to OpenSolaris at the moment, and basic ZFS replication can be used on OS X and FreeBSD too.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matthew Montgomery</title>
		<link>http://coalface.mcslp.com/2008/11/09/zfs-replication-for-mysql-data/comment-page-1/#comment-7680</link>
		<dc:creator>Matthew Montgomery</dc:creator>
		<pubDate>Tue, 11 Nov 2008 01:26:35 +0000</pubDate>
		<guid isPermaLink="false">http://coalface.mcslp.com/?p=154#comment-7680</guid>
		<description>The proper way to handle block device level replication in Solaris/ZFS is to use AVS 

See: http://opensolaris.org/os/project/avs/

The idea behind AVS is very much the same as DRBD.</description>
		<content:encoded><![CDATA[<p>The proper way to handle block device level replication in Solaris/ZFS is to use AVS </p>
<p>See: <a href="http://opensolaris.org/os/project/avs/" rel="nofollow">http://opensolaris.org/os/project/avs/</a></p>
<p>The idea behind AVS is very much the same as DRBD.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nils Meyer</title>
		<link>http://coalface.mcslp.com/2008/11/09/zfs-replication-for-mysql-data/comment-page-1/#comment-7677</link>
		<dc:creator>Nils Meyer</dc:creator>
		<pubDate>Mon, 10 Nov 2008 15:03:31 +0000</pubDate>
		<guid isPermaLink="false">http://coalface.mcslp.com/?p=154#comment-7677</guid>
		<description>Keep in mind that DRBD works live, it&#039;s not a stale snapshot that&#039;s periodically replicated. Kind of like RAID over TCP. Your CAPTCHA is impossible to read.</description>
		<content:encoded><![CDATA[<p>Keep in mind that DRBD works live, it&#8217;s not a stale snapshot that&#8217;s periodically replicated. Kind of like RAID over TCP. Your CAPTCHA is impossible to read.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Martin MC Brown</title>
		<link>http://coalface.mcslp.com/2008/11/09/zfs-replication-for-mysql-data/comment-page-1/#comment-7676</link>
		<dc:creator>Martin MC Brown</dc:creator>
		<pubDate>Mon, 10 Nov 2008 07:24:57 +0000</pubDate>
		<guid isPermaLink="false">http://coalface.mcslp.com/?p=154#comment-7676</guid>
		<description>It is true that the more snapshots that you keep around, there will be both some storage and performance overhead to keep them up to date. 

But the point is that you shouldn&#039;t ever be keeping snapshots long term. 

In a typical backup setup, you&#039;d keep limited snapshots around (say one a day), but most likely copy anything more than day old, and certainly a week old, off somewhere else.

In a replication environment, as I&#039;ve described here, you need only keep the snapshots for as long as it takes to replicated them to the slave machine, plus enough snapshots for you to be able to create a suitable incremental for zfs send.

I replicate between two machines with a snapshot every 15 minutes, and keep one snapshot from the start of the day (literally at midnight) and keep only the last 4 (one hour) of snapshots beyond that. The rest are automatically destroyed. 

Because of the way the snapshots work, that means I can replicate from the start of the day and any incremental up until the last 15 minute checkpoint, and still have all the changes. 

Keeping those 5 snapshots up to date doesn&#039;t make a particular impact on performance, as far as I can tell.</description>
		<content:encoded><![CDATA[<p>It is true that the more snapshots that you keep around, there will be both some storage and performance overhead to keep them up to date. </p>
<p>But the point is that you shouldn&#8217;t ever be keeping snapshots long term. </p>
<p>In a typical backup setup, you&#8217;d keep limited snapshots around (say one a day), but most likely copy anything more than day old, and certainly a week old, off somewhere else.</p>
<p>In a replication environment, as I&#8217;ve described here, you need only keep the snapshots for as long as it takes to replicated them to the slave machine, plus enough snapshots for you to be able to create a suitable incremental for zfs send.</p>
<p>I replicate between two machines with a snapshot every 15 minutes, and keep one snapshot from the start of the day (literally at midnight) and keep only the last 4 (one hour) of snapshots beyond that. The rest are automatically destroyed. </p>
<p>Because of the way the snapshots work, that means I can replicate from the start of the day and any incremental up until the last 15 minute checkpoint, and still have all the changes. </p>
<p>Keeping those 5 snapshots up to date doesn&#8217;t make a particular impact on performance, as far as I can tell.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Arjen Lentz</title>
		<link>http://coalface.mcslp.com/2008/11/09/zfs-replication-for-mysql-data/comment-page-1/#comment-7675</link>
		<dc:creator>Arjen Lentz</dc:creator>
		<pubDate>Sun, 09 Nov 2008 22:14:19 +0000</pubDate>
		<guid isPermaLink="false">http://coalface.mcslp.com/?p=154#comment-7675</guid>
		<description>Useful.
From the above description, I do conclude that the more snapshots you have on your system, the more overhead there will be in the filesystem when block are changed, as the ZFS will need to spend time updating the info in the various snapshots.
So this would be something to keep in mind, otherwise it will start affecting performance, right?</description>
		<content:encoded><![CDATA[<p>Useful.<br />
From the above description, I do conclude that the more snapshots you have on your system, the more overhead there will be in the filesystem when block are changed, as the ZFS will need to spend time updating the info in the various snapshots.<br />
So this would be something to keep in mind, otherwise it will start affecting performance, right?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
