differences between rsync and pseudo-RSS

[Brian K. White]

Fairlight wrote:
> Ah, just thought of another (but related) difference.
>
> Even if you didn't hit a corrupt file in the middle of being updated,
> you could hit a state where say, an index was updated, but a key file
> had not been, if the file order was right.  That could be bad as well.
>
> Another reason to do it as an internal transaction, IMHO.  Everything
> is guaranteed to be updated as fP expects it.
>
> mark->

Yes rsync of fp data should only be done while fp users on both systems are
locked out, cron reports suspended, etc...

I rsync live data to backup boxes while running live, but that is a
conscious decision weighing the advantages & disadvantages.

The worst case scenario is is both not very bad and extremely unlikely.
rsync happens in the middle of a year-end process.
live box dies later

So it just means you restore yesterdays data from one of the 2 nightly
backups (cmpressed tar of fp data, tape of everything)
re-enter a days work, and re-run the process.

far more likely is:
rsync happens while a few different orders are being entered
live box dies later.

In that case if they had to switch to running on the backup box they just do
a rebuild-all-indexes initially and delete/re-enter the couple buggy orders
when they discover them.

But this is for backup and having some kind of safety in the event the main
server dies where it's more important that the data be as complete and as
current as possible and it's ok if a few transactions are incomplete or
inconsistent. I agree rsync is no good at all for keeping multiple live
servers in sync unless you could take both servers off-line for the duration
and exit any currently running fp process. For that you need to encapsulate
the updates into some form of transaction and have fp perform the updates
exactly as if a user were to do the same work. Which is exactly what you are
on to.

I've toyed with the idea a couple years ago ever since I made my first cgi
that exports data on demand. I could see it would be not much harder to
allow it to import & update and not much harder to allow it to have generic
access to all the files, and not much more to have it use the "guts" of
various input process tables and reports to duplicate actual user work and
not much more to have the update routines (both normal interactive and cgi)
include a gosub to send update info to other boxes. By "not much more" I
guess I mean it desn't seem like an exoctic puzzle to solve, just a wamba
big boatload of more or less straightforward tedious work.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani