Michael,
On Wed, 17 Feb 1999, Michael Davis wrote:
> I was thinking about creating a trigger on every table that would write an
> insert, update, or delete statement into a log file. Each replicated
> database would pro-actively read these and post them.
Right. This is one of the prerequesites to avoid a timestamp orientated
replication mechanism, which is known to be vulnerable to the lost
update phenomenon. (e.g. "newnews" on newsservers)
But even if you do that, you have to keep the relations between the
tables intact creating a really unique recordid for each record
in each database.
As Dustin pointed out, he solved it by merging a unique database
id with a sequence into a unique primary key.
This solution is only a partially one because of the insert
into a relation from database 2 into a relation initially
created by database 1.
If the newly inserted record gets the database id of database 2
it will later not be recognized belonging to the relation by a
"... where db_id=this_relations_host and recid=this_relations_sequence"
on every host.
If the newly inserted record gets the database id of database 1
it will be surely regocnized, but the sequence number of the
record may collide with a pre existing record in database 1
when replicated.
Multiple updates to a record of the same relation on different
non connected databases are another problem not solved by
this mechanism.
Every solution which i can imagine relies on a master, which
receives temporary data on inserts, creates unique record ids
and re exports the data to the slaves.
A slave will create in his local database a record id which is
known to be "not part of all databases". e.g. all numbers below
100000 are temporary.
Then it exports this data to the master and deletes the temporary
data, when the master acknowledged his import.
The master creates unique record ids among all temporary data
and reexports the data to all his slaves.
But what to do, if there are several local masters?
t++