Jim Starkey wrote:

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

I agree that the cluster size should not be changed every day or so...
This is why I said that my prefered approach was "stteped values" with a
fixed gap, it has limmitations but is hard to hit it, it's more
theorical than pratical.

Ok, the problem os closiion values will be handled by a syncronization
of the physical sequences.

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

ok, but all nodes needs to be reached in someway at this point, if a
salesman has a DB in his Notebook and are offline at this moment how to
know what physical sequence value it has ? I agree that the same will
happen when they get back on-line and try to sync the DB, and some
metadata was changed, the replication code could look for a DB Metadata
version I just sync after the Metadata was bring in sync with the others.

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

:-)

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

ok.. I just want to understand how the interval would be changed, it
could be, but will need care, I think is a good trade-off between
simplicity and versatility.

I thing I forgot to mention, I am sure you know this.

The UUID/GUID is "guaranteed" unique even if it's generated by computers
that don't know of each other (don't belong to the cluster), so, for
multi-enterprise data exchange I think it still be a good unique
identifier. I think this is a point where UUID/GUID has advantage over
"unique cluster sequences".

see you !

--

Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.5 - Release Date: 29/03/2005