Re: Cluster Questions - Jon Stephens - com.mysql.lists.cluster

7 messages in com.mysql.lists.clusterRe: Cluster Questions

From	Sent On	Attachments
Andrew Hutchings	20 Jan 2007 01:36
Jon Stephens	20 Jan 2007 04:33
Andrew Hutchings	20 Jan 2007 08:00
Mikael Ronström	20 Jan 2007 09:26
Mindaugas	21 Jan 2007 23:10
Stewart Smith	13 Feb 2007 21:58
Jon Stephens	14 Feb 2007 06:45

Subject:	Re: Cluster Questions
From:	Jon Stephens (jo...@mysql.com)
Date:	02/14/2007 06:45:07 AM
List:	com.mysql.lists.cluster

Stewart Smith wrote:

On Mon, 2007-01-22 at 09:11 +0200, Mindaugas wrote:

It is not recommended or not supported? Because how without SQL node on the same server as data node use all 4 CPU cores? As far as I understood running 2 data nodes on the same server (from different node groups) is not supported?

It *should* all work fine running more than one data node on a physical machine. It's just that multiple simultaneous node failures (if the machine went down) isn't as well tested as single node failures so there may be as yet undiscovered bugs. So for real paranoid people, we say "don't do that".

Our QA people don't currently test using multiple-node-per-machine configurations, so we can't guarantee that they'll be free of problems, or that we'll quickly fix bugs uncovered in these sorts of setups. When we say "not supported" (instead of "not possible"), this is generally what we mean.

We know there's lots of demand for real "yes, you can definitely use this in production, and we'll definitely fix any bugs you report" support of multi-node setups, and it's something we're looking to add in the future, but I can't tell you when that will happen.

Thos things being said - I run two test clusters, each having two machines hosting 1 mgm, 2 ndbd's, and 1 or 2 mysqld's, and they're pretty stable. But then I don't have tables with millions of rows or run thousands of queries a minute on them, either. ;)

cheers

jon.

As for running mysqld and ndbd on the same host - the risk is that mysqld could hog resources from ndbd (or the other way around) leading to loss of service.