[firebase-br] [firebird-support] Re: SURVIVING SERVER DOWNTIME

Anderson - EasyBit anderson em easybit.com.br
Ter Fev 13 16:24:22 -03 2007


Boa tarde Galera, blz?

Estou replicando aqui uma mensagem da lista 
internacional por tratar-se de um assunto que 
rolou várias vezes aqui na FB-Br. Gostei da 
abordagem do Adam sobre o assunto, espero que ela 
contribua para o debate sobre replicação.

Abraço,

Anderson


At 19:20 12/2/2007, Adam wrote:

>--- In 
><mailto:firebird-support%40yahoogroups.com>firebird-support em yahoogroups.com, 
>James N Hitz <jamhitz em ...> wrote:
> >
> > Hello
> >
> > I read somewhere that a good client/server application (say in a
> > supermarket) should be able to survive both a server downtime as
>well as
> > a client downtime - implying; that is if I got it correctly; that the
> > client application (in a retail store for example) should allow the
>user
> > to continue selling even if the server should happen to go down.
> >
> > Somebody please shed some light here. How would I survive a server
> > downtime if my data (like prices, stock levels etc) are stored in a
> > Firebird database at the server?
> >
>
>Well you can not deal with 'client downtime'. If the register isn't
>working, it isn't working. What you can handle is comms problems and
>server problems.
>
>I don't think client-server is an appropriate methodology for a cash
>register. It is inherently unreliable, reliable enough for most
>problems, but good luck trying to sell your product with the
>disclaimer that if the server network card fails they need to close
>the shop for half an hour while someone runs down and installs a new one.
>
>Firebird is just a database engine (a very good one at that), but not
>some magical piece of software able to defy the laws of physics. If
>the client has no way of contacting the server, the client can't ask
>the server to do anything.
>
>We have software with a similar requirement. The server may be
>thousands of km away (across an internet connection, sometimes in
>another state, and in at least one case another country). This is
>probably 1000 times less reliable than a LAN.
>
>If you need reliability, you can't require another machine to respond
>to yours to function. You can not just assume that you can just issue
>a select statement and get a response. It may take too long to come or
>it may not even come at all.
>
>Turn the big problem into two smaller problems. You need a local
>database at each client, and you need to replicate the information to
>and from the main server. When the client workstation needs some
>information, it just looks at its local database. It reads prices,
>stock, whatever is required from its local database. It writes its
>transactions to its local database. Periodically, it sends any
>transactions to the server and downloads new information for stock
>levels and prices etc.
>
>There are third party tools to handle replication, or it is reasonably
>trivial to handle yourself using triggers to keep track of changes.
>
>You can potentially avoid installing a Firebird service on each client
>by using the embedded server. You will need to read the appropriate
>readme files to make sure it is suitable to your needs.
>
>Adam



Mais detalhes sobre a lista de discussão lista