On Fri, 2004-08-27 at 02:51, Tomas Ulin wrote:
> all,
>
> I feel an urge to break in here so as not to cause confusion.
>
> Today (will change some day) you can not change the number of nodes
> on-line, we've just added verifications for this in the code because
> doing this will cause the system to break eventually.
>
Thanks for clearing this up. It seemed too good to be true that MySQL
cluster would be that smart already. :)
> Hence to upgrade:
> 1) make backup
> 2) shutdown your old cluster
> 3) bring new cluster up
> 4) restore
>
This is kind of a bummer, but its acceptable. I imagine with smaller
databases this will still maintain 99.999% uptime. If this process takes
2 hours though, we're still in 99.99% uptime.. thats assuming you expand
your cluster once a year. Not bad. :)
One thing that would be a nice feature would be partial backups and
restores. If I could split this process into one backup/restore per
table.. I could parallelize it across the management servers and it
should run faster.. right?
> What you've managed to to by going from 4 to 8 on-line will (maybe) work
> if you don't create new tables... and anyways the data will not have
> redistributed itself in going from 4 to 8, all the data will still be
> located on the 4 first nodes (you should be able to see this if you do a
> load test...).
>
> An online upgrade path will look like follows:
>
> 4-node version 4.x -> 4-node version 5.y -> 8-node version 5.z
>
Ok so 5.x should have this. Thats acceptable.
Mostly curious question, why isn't it smart enough to do this yet? Must
be because the hash changes with the number of nodes... right?
Also, is the restriction on number of nodes to a power of n, where
n=replicas, going to be a requirement forever, or is it just a problem
with the current code? Would be nice to be able to expand by just two
nodes every once in a while. 4->8 is doable. 8->16 is a big investment,
no matter how small your nodes are.
