Re: NDB tables with character primary key replicate only partially (2) - Jonas Oreland - com.mysql.lists.bugs

9 messages in com.mysql.lists.bugsRe: NDB tables with character primary...

From	Sent On	Attachments
Giuseppe Maxia	13 Oct 2004 05:07
Jonas Oreland	13 Oct 2004 12:14
Giuseppe Maxia	13 Oct 2004 12:45
Giuseppe Maxia	13 Oct 2004 22:02
Jonas Oreland	14 Oct 2004 00:29
Giuseppe Maxia	14 Oct 2004 01:59
Jonas Oreland	14 Oct 2004 02:11
Giuseppe Maxia	14 Oct 2004 03:15
Giuseppe Maxia	17 Oct 2004 03:35

Subject:	Re: NDB tables with character primary key replicate only partially (2)
From:	Jonas Oreland (jona...@mysql.com)
Date:	10/14/2004 02:11:38 AM
List:	com.mysql.lists.bugs

Giuseppe Maxia wrote:

Jonas Oreland wrote:

Giuseppe Maxia wrote:

Jonas Oreland wrote:

Hi,

I've tried to reproduce you problem, but I can't.

How long time does pass between mysql1-commit and mysql2-select?

Giuseppe Maxia wrote:

Some more info to set the record straight: Node1 and Node2 are NOT two clients of the same MySQL server, but two clients of two different MySQL servers using the same NDB data node.

Using the config.ini as listed in the documentation, I started two instances of the (MySQLL) server listening to two different ports.

Then, after a slight addition to the configuration file, I repeated the experiment with two MySQL servers in two separate machines and the bug works as I said in my first message.

hmm...I guessed that it was two mysql servers. But, I still can't repeat the bug (also using auto commit=0) :-(

I'm using the latest bk-source (soon to be released as 4.1.6).

Could you try this using a nightly snapshot?

I just did that. I compiled 4.1.6 and I got another surprise. It seems that it does not like the configuration that worked fine with 4.1.5

-- NDB Cluster -- Management Client -- Connecting to Management Server: localhost:2200 NDB> show Cluster Configuration

--------------------- Could not get configuration * 1006: Illegal reply from server

And in the error log:

Date/Time: Thursday 14 October 2004 - 10:35:51 Type of error: error Message: Invalid Configuration fetched from Management Server Fault ID: 2350 Problem data: Could not fetch configuration/invalid configuration Object of reference: ProgramName: NDB Kernel ProcessID: 3954 TraceFile: ./ndb_2_trace.log.1

Curious, though. I have been experimenting with the cluster since June, and the format of the configuration file has already changed three times.

:-)

But, please correct me if I'm wrong. This does not mean that the actual format changed, but that you need to restart the mgm server.

We have currently made the decision not to allow _any_ different version binaries connecting to each other.

This decision was made to reduce load on testing organization and takes into account that 4.1* is the _first_ release of mysql cluster.

For 5.0 there will probably be a upgrade path. Example: you can upgrade from 4.1.3->4.1.8->5.0 but not from 4.1.2->5.0.

(note that this is guesses, and that version numbers are _only_ examples)

/Jonas

ps. How did the select go? ds.