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

Jonas Oreland wrote:
> 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.

But I did it.

1) I shut down the whole cluster.

2) I replaced 4.1.5 with 4.1.6

3) I made a clean directory for the data node.

4) I started the management server

# ndb_mgmd

5) I started the data server

# ndbd --initial

6) ... And I got an error. :-(

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

I made sure that the only binaries in view were the ones from 4.1.6.
Now I am back to 4.1.5, because I have a bunch of tests still in my schedule.

> 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?

No SELECTs with the latest version. I couldn't go past the configuration phase.

> ds.
> 

Cheers

Giuseppe


-- 
Giuseppe Maxia
CTO
http://www.StarData.it
MySQL Certified Professional
        __              __     __
   ___ / /____ ________/ /__ _/ /____ _
  (_-</ __/ _ `/ __/ _  / _ `/ __/ _ `/
/___/\__/\_,_/_/  \_,_/\_,_/\__/\_,_/
        Database is our business

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