Re: NDB tables with character primary key replicate only partially (2)

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?
>>>>
>>>> /Jonas
>>>>
>>>> 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?
>>
>> /Jonas
>>
>>
> 
> 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.

-- 
Jonas Oreland, Software Engineer
MySQL AB, www.mysql.com

-- 
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe:    http://lists.mysql.com/[email protected]