Alexandre Benson Smith wrote:

>If this works this way, I think we will get duplicated values, I think I've missed something here :-(
>
>Did you manage to enforce a starting physical sequence value when a new DB is created based uppon the interval value or the max sequence values of all others DB's ?
>
>

Change the interval needs to be handled with similar care to a metadata
update. In specific, the physical sequence values should be
synchronized. Since the "update sequence" command will only move the
physical sequence forward, not back, this is straightforward. Once the
physical sequences are synchronized the interval can be changed with
impunity. In practice, changing the interval (cluster size) is an
unusual and generally rare event. If you have a steadily increasing
replication cluster size, it is straightforward to maintain sufficient
synchronization of physical sequences to allow dynamic increases of the
sequence interval on the fly.

>
>
>> 2. The interval can be increased, never decreased.
>>
>>
>>
>>
>ok, but see above.
>The interval should be increased on every DB at same time right ? How it
>is done ?
>
>

Two ways come to mind; there are probably more. One is for the
replication code to track physical sequence values from other nodes and
ensure that local physical sequence values are synchronized before
changing the interval. Another to is quiese the cluster, perform an ad
hoc physical sequence synchronization, then change the interval. The
choice probably follows the method chosen to perform metadata updates.
If you can handle metadata updates during active cluster operations,
then managing the sequence interval should be easy.

>>
>>
>This is a point I didn't understand how do you get an unique ID based on
>MAC or IP Address for unconnected DB's that is guaranteed unique, it's
>made with human intervention ?
>
>

No. In the replication scheme implemented by my customer, a replicant
starts as a simple physical copy of the database from a different node.
It figures out it's system id when it wakes up. Each system then
contacts its replication partners, announces the high end of its
replication log, and gets blasted with everything that's happened since
them. It uses a database table to make MAC or IP address to system id
to avoid human intervention, which is important, since the circumstances
that lead to rebuilding a replication node after the previous one has
reduced itself to a smoking wreck almost alway has everyone upset and
therefor error prone. Time has proven that dead node failover has to be
mindless since when it's required, the mind is less.

>>
>>
>Thanks for the explanation, I am curious to see what I have missed, this
>looks like a very simple and elegant way to generate unique ID's without
>the fixed interval limits of what I called "stepped values".
>
>
>
>

Done stupidly, there can be problems. If managed properly, the
operation is safe.


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376