<?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: Setting up MySQL Asynchronous Replication for High Availability</title>
	<atom:link href="http://www.clusterdb.com/mysql-cluster/setting-up-mysql-asynchronous-replication-for-high-availability/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.clusterdb.com/mysql-cluster/setting-up-mysql-asynchronous-replication-for-high-availability/</link>
	<description>MySQL Cluster database &#38; MySQL Replication</description>
	<lastBuildDate>Thu, 26 Aug 2010 08:05:11 -0700</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: How can a database be in-memory and durable at the same time? @ Andrew Morgan&#8217;s MySQL Cluster Database Blog</title>
		<link>http://www.clusterdb.com/mysql-cluster/setting-up-mysql-asynchronous-replication-for-high-availability/comment-page-1/#comment-8113</link>
		<dc:creator>How can a database be in-memory and durable at the same time? @ Andrew Morgan&#8217;s MySQL Cluster Database Blog</dc:creator>
		<pubDate>Tue, 13 Jul 2010 10:18:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.clusterdb.com/?p=401#comment-8113</guid>
		<description>[...] to store data in MySQL Cluster at all!). More details on Geo Replication scenarios can be found at http://www.clusterdb.com/mysql-cluster/setting-up-mysql-asynchronous-replication-for-high-availabil...   MySQL Cluster Durability, Durable, MySQL Cluster [...]</description>
		<content:encoded><![CDATA[<p>[...] to store data in MySQL Cluster at all!). More details on Geo Replication scenarios can be found at <a href="http://www.clusterdb.com/mysql-cluster/setting-up-mysql-asynchronous-replication-for-high-availabil.." rel="nofollow">http://www.clusterdb.com/mysql-cluster/setting-up-mysql-asynchronous-replication-for-high-availabil..</a>.   MySQL Cluster Durability, Durable, MySQL Cluster [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Software preview MySQL Scriptable Replication @ Andrew Morgan&#8217;s MySQL Cluster Database Blog</title>
		<link>http://www.clusterdb.com/mysql-cluster/setting-up-mysql-asynchronous-replication-for-high-availability/comment-page-1/#comment-2548</link>
		<dc:creator>Software preview MySQL Scriptable Replication @ Andrew Morgan&#8217;s MySQL Cluster Database Blog</dc:creator>
		<pubDate>Tue, 24 Nov 2009 16:14:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.clusterdb.com/?p=401#comment-2548</guid>
		<description>[...] can then be set-up as normal as described in Setting up MySQL Asynchronous Replication for High Availability with the exception that we use 2 slaves rather than [...]</description>
		<content:encoded><![CDATA[<p>[...] can then be set-up as normal as described in Setting up MySQL Asynchronous Replication for High Availability with the exception that we use 2 slaves rather than [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: admin</title>
		<link>http://www.clusterdb.com/mysql-cluster/setting-up-mysql-asynchronous-replication-for-high-availability/comment-page-1/#comment-1362</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Fri, 18 Sep 2009 18:40:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.clusterdb.com/?p=401#comment-1362</guid>
		<description>Yes - I do still plan on writing that post but unfortunately, vacation and business trips have kept me away from my target machines too much lately and it will be at least a week or so before I can write it.</description>
		<content:encoded><![CDATA[<p>Yes &#8211; I do still plan on writing that post but unfortunately, vacation and business trips have kept me away from my target machines too much lately and it will be at least a week or so before I can write it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: nottlv</title>
		<link>http://www.clusterdb.com/mysql-cluster/setting-up-mysql-asynchronous-replication-for-high-availability/comment-page-1/#comment-1179</link>
		<dc:creator>nottlv</dc:creator>
		<pubDate>Fri, 11 Sep 2009 14:22:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.clusterdb.com/?p=401#comment-1179</guid>
		<description>Andrew,

You mentioned a future post would cover setting up multimaster replication using an already active cluster...is that still in the works?  We&#039;re considering doing that and I would love to read your thoughts on it.</description>
		<content:encoded><![CDATA[<p>Andrew,</p>
<p>You mentioned a future post would cover setting up multimaster replication using an already active cluster&#8230;is that still in the works?  We&#8217;re considering doing that and I would love to read your thoughts on it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: admin</title>
		<link>http://www.clusterdb.com/mysql-cluster/setting-up-mysql-asynchronous-replication-for-high-availability/comment-page-1/#comment-778</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Sun, 23 Aug 2009 09:01:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.clusterdb.com/?p=401#comment-778</guid>
		<description>Krex,

 thanks for your response. If you set this same configuration on each server, would they not still have clashing auto-increment values? Wouldn&#039;t it be better to set the  increment to 2 on each server but the offset to 1 on one and 2 on the other? That way one server would generate odd values and the other even.

Regards, Andrew.</description>
		<content:encoded><![CDATA[<p>Krex,</p>
<p> thanks for your response. If you set this same configuration on each server, would they not still have clashing auto-increment values? Wouldn&#8217;t it be better to set the  increment to 2 on each server but the offset to 1 on one and 2 on the other? That way one server would generate odd values and the other even.</p>
<p>Regards, Andrew.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: krex</title>
		<link>http://www.clusterdb.com/mysql-cluster/setting-up-mysql-asynchronous-replication-for-high-availability/comment-page-1/#comment-561</link>
		<dc:creator>krex</dc:creator>
		<pubDate>Fri, 14 Aug 2009 06:38:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.clusterdb.com/?p=401#comment-561</guid>
		<description>Master Master Replication and Auto Increment - Mysql, Windows/Linux:

Consider we&#039;ve already set a master-master replication.
Now create following table on Server1:

CREATE TABLE `temp` (
  `id` int(10) NOT NULL auto_increment,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=12 DEFAULT CHARSET=latin1;

The table will will get replicated on Mysql Server2 in the master-master setup.

Now insert value on Mysql Server1 as follows:
insert into temp values(null);

On Mysql Server2 in replication you will see single row inserted.
Now insert one row from Mysql Server2 as follows:
insert into temp values(null);

You should see an error:
Error &#039;Duplicate entry &#039;1&#039; for key &#039;PRIMARY&#039;&#039; on query...

The obvious problem of maintaining auto increments in sync will persist on both mysql servers as AUTO_INCREMENT&#039;s value.

The solution is to use the variables &lt;a href=&quot;http://dev.mysql.com/doc/refman/5.0/en/replication-options-master.html#sysvar_auto_increment_increment&quot; rel=&quot;nofollow&quot;&gt;auto_increment_increment and auto_increment_offset&lt;/a&gt; as explained below.

- Stop both master-master replication servers.
- Add variables to my.[ini&#124;cnf] file.
	Eg. On both the Server&#039;s my.[ini&#124;cnf] add following lines:
	auto_increment_increment=1
	auto_increment_offset=2
- Restart mysql servers.
- Start slave.</description>
		<content:encoded><![CDATA[<p>Master Master Replication and Auto Increment &#8211; Mysql, Windows/Linux:</p>
<p>Consider we&#8217;ve already set a master-master replication.<br />
Now create following table on Server1:</p>
<p>CREATE TABLE `temp` (<br />
  `id` int(10) NOT NULL auto_increment,<br />
  PRIMARY KEY  (`id`)<br />
) ENGINE=MyISAM AUTO_INCREMENT=12 DEFAULT CHARSET=latin1;</p>
<p>The table will will get replicated on Mysql Server2 in the master-master setup.</p>
<p>Now insert value on Mysql Server1 as follows:<br />
insert into temp values(null);</p>
<p>On Mysql Server2 in replication you will see single row inserted.<br />
Now insert one row from Mysql Server2 as follows:<br />
insert into temp values(null);</p>
<p>You should see an error:<br />
Error &#8216;Duplicate entry &#8217;1&#8242; for key &#8216;PRIMARY&#8221; on query&#8230;</p>
<p>The obvious problem of maintaining auto increments in sync will persist on both mysql servers as AUTO_INCREMENT&#8217;s value.</p>
<p>The solution is to use the variables <a href="http://dev.mysql.com/doc/refman/5.0/en/replication-options-master.html#sysvar_auto_increment_increment" rel="nofollow">auto_increment_increment and auto_increment_offset</a> as explained below.</p>
<p>- Stop both master-master replication servers.<br />
- Add variables to my.[ini|cnf] file.<br />
	Eg. On both the Server&#8217;s my.[ini|cnf] add following lines:<br />
	auto_increment_increment=1<br />
	auto_increment_offset=2<br />
- Restart mysql servers.<br />
- Start slave.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Using NDB API Events to mask/hide colum data when replicating @ Andrew Morgan&#8217;s MySQL Cluster Database Blog</title>
		<link>http://www.clusterdb.com/mysql-cluster/setting-up-mysql-asynchronous-replication-for-high-availability/comment-page-1/#comment-538</link>
		<dc:creator>Using NDB API Events to mask/hide colum data when replicating @ Andrew Morgan&#8217;s MySQL Cluster Database Blog</dc:creator>
		<pubDate>Thu, 13 Aug 2009 13:10:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.clusterdb.com/?p=401#comment-538</guid>
		<description>[...] The first step is to set up replication (master-&gt;slave rather than multi-master) as described in Setting up MySQL Asynchronous Replication for High Availability). [...]</description>
		<content:encoded><![CDATA[<p>[...] The first step is to set up replication (master-&gt;slave rather than multi-master) as described in Setting up MySQL Asynchronous Replication for High Availability). [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: johan</title>
		<link>http://www.clusterdb.com/mysql-cluster/setting-up-mysql-asynchronous-replication-for-high-availability/comment-page-1/#comment-304</link>
		<dc:creator>johan</dc:creator>
		<pubDate>Tue, 04 Aug 2009 16:53:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.clusterdb.com/?p=401#comment-304</guid>
		<description>Be careful with multimaster.
Requires conflict detection and resolution, or partitioning to avoid conflicts.


BR
johan</description>
		<content:encoded><![CDATA[<p>Be careful with multimaster.<br />
Requires conflict detection and resolution, or partitioning to avoid conflicts.</p>
<p>BR<br />
johan</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Shlomi Noach</title>
		<link>http://www.clusterdb.com/mysql-cluster/setting-up-mysql-asynchronous-replication-for-high-availability/comment-page-1/#comment-299</link>
		<dc:creator>Shlomi Noach</dc:creator>
		<pubDate>Tue, 04 Aug 2009 09:58:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.clusterdb.com/?p=401#comment-299</guid>
		<description>Hi,

When doing cross-geographical replication, don&#039;t forget to set up replication over SSL, or your data is unencrypted across the network.

Regards</description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>When doing cross-geographical replication, don&#8217;t forget to set up replication over SSL, or your data is unencrypted across the network.</p>
<p>Regards</p>
]]></content:encoded>
	</item>
</channel>
</rss>
