Jon Brisbin wrote:
> At each store, there are a number of POS registers that are networked. If
> they enter a ticket at one register, they should be able to go to any other
> register to tender the transaction, etc...
>
> We already have mechanisms in place to remotely download and install
> software on existing PCs, so no additional outlay of cash would be required
> to set up these existing machines with more software. To install new PCs in
> 800 stores at the same time would be a nightmare of logistics that we can't
> currently contemplate. We also can't contemplate what nasty things will be
> done to us if we go to the executives and say we're going to fix their
> problems by forcing the stores to rely on only one machine. The restaurant
> business is not kind to PC hardware.
OK, fair enough.
> One option is to have the POS software always write to a local database,
> with that change getting replicated to all other active nodes. Another
> option is to have a "master" database, with a failover as backup. Downside
> here is that if both machines fail, then they are dead in the water. We
> can't make money if the registers aren't operational. However, this is
> similar to what happens now (which is why we want to change it.)
>
> Having mucked with postgres replication a little in the last couple of days,
> I'm starting to wonder just how long it will take us to develop a good
> replication mechanism. If one is already in place, I'd just like to use
> that. Or at least learn from someone else trying to set up something
> similar.
Well, sounds like Slony would pretty much do what you want (one master,
multiple backups) apart from the failover.
I'm assuming your POS database is fairly simple and your transactions
are at a slow rate which means the traffic generated by replication
would be minimal. What constitutes a "dead" database is the tricky part.
Do you have a "master" terminal at the moment or are they all strictly
peers?
--
Richard Huxton
Archonet Ltd