> Nigel Weeks wrote:
> > Each database that mod_repl hooks into MUST HAVE
> > int_siteid INTEGER NOT NULL,
> > dtm_rstamp TIMESTAMP DEFAULT 'now',
> > ...
> > in every table.
>
> Why timestamp?
> What happens if time on server is changed?
> How do you sinc the servers?

Sorry, I should have put more in the table example.
The timestamp isn't part of the primary key - it's a hint to fall back on if
there's a primary key clash...First in, first served...
Servers are time-synced using ntpdate - it's standard.

> My suggestion is to use generators, actually a single generator.

Generators, definitely, a single one, maybe not(still thinking, though).
Each table(currently) has it's own generator for primary key, i.e.,
int_accountid.
The pkey ends up being (int_siteid, int_accountid).

> > ------ Begin Pseudo ------
> > The 'Collector' queries each database, and retrieves any
> new changes.
>
> How do you plan on doing this?
> You can have a single one column table with one value: last
> replicated
> generator_id. Then just query each table if it has gen_id larger than
> that number.

Interesting idea! 64bit value, can handle a few records...but I think I'd
rather let the processing be a little more distributed - let the insert run
the trigger, and copy the row to the REPL. Table, and let collector simply
pull the row, instead of querying every table, then pulling the new/changed
rows from them.

I'll give more thought to your idea, though!

I'll select table name from RDB$ table where name starts with REPL., and
inside that loop, I pull any records out, and transfer to the 'Inbox'...

>
> Other things seem ok. Except one thing. It doesn't support
> conflicting
> updates. I define "conflicting updates" like this:
>
> At server A record X is changed to value y.
> At server B record X is changed to value z.
>
> When B receives updates from A, it could detect that it also
> has changed
> record X since the last replication, and if the values are different
> (A.new_x != B.new_x) it should issue the warning.

It should go close, as it can use the dtm_rstamp 'hint' to do first in,
first served.
It probably should also log this event(when rstamp get used), so information
doesn't silently disappear.

>
> Well, just my ideas.
>

And they are very valuable! Thankyou for your time!

Nige.