(Migrated) questions about zato

(This message has been automatically imported from the retired mailing list)

Hello i have some questions about zato.

Does zato synchronise data beetween different postgresql server ?

What happen if one of the postgresql server goes offline ?

Regards and thanks

Bussiere

  • Были бы кости, а мясо нарастет

On 17/11/14 14:42, bussiere bussiere wrote:

Hi there,

Does zato synchronise data beetween different postgresql server ?

Zato won’t do it itself. It connects to an address and it doesn’t know
if that address if of a Postgres instance or a load-balancer, pgpool or
anything else.

What happen if one of the postgresql server goes offline ?

Broadly speaking, nothing really bad will happen - but here are the details.

Zato always reads in each and every piece of configuration it finds in
the ODB. That’s the reason servers start in 10-20 seconds rather than
1-2 seconds - because they need to issue dozens or hundreds of SQL
queries to get everything from the database.

This lets them be very quick in runtime on the one hand and on the other
hand it means that the database is not that much needed once servers
started.

So, as long as the servers only process incoming requests from client
applications and you don’t update a cluster’s configuration, the only
thing that will fail are background checks Zato internally performs in
order to check if the ODB is still alive - so the only bad thing will be
error messages in server.log pointing out that your DB has gone away.

On 17/11/14 14:42, bussiere bussiere wrote:

Hi there,

Does zato synchronise data beetween different postgresql server ?

Zato won’t do it itself. It connects to an address and it doesn’t know
if that address if of a Postgres instance or a load-balancer, pgpool or
anything else.

What happen if one of the postgresql server goes offline ?

Broadly speaking, nothing really bad will happen - but here are the details.

Zato always reads in each and every piece of configuration it finds in
the ODB. That’s the reason servers start in 10-20 seconds rather than
1-2 seconds - because they need to issue dozens or hundreds of SQL
queries to get everything from the database.

This lets them be very quick in runtime on the one hand and on the other
hand it means that the database is not that much needed once servers
started.

So, as long as the servers only process incoming requests from client
applications and you don’t update a cluster’s configuration, the only
thing that will fail are background checks Zato internally performs in
order to check if the ODB is still alive - so the only bad thing will be
error messages in server.log pointing out that your DB has gone away.

Ok thanks for the answer

  • =D0=91=D1=8B=D0=BB=D0=B8 =D0=B1=D1=8B =D0=BA=D0=BE=D1=81=D1=82=D0=B8, =D0=
    =B0 =D0=BC=D1=8F=D1=81=D0=BE =D0=BD=D0=B0=D1=80=D0=B0=D1=81=D1=82=D0=B5=D1=
    =82

On Mon, Nov 17, 2014 at 2:53 PM, Dariusz Suchojad dsuch@zato.io wrote:

On 17/11/14 14:42, bussiere bussiere wrote:

Hi there,

Does zato synchronise data beetween different postgresql server ?

Zato won’t do it itself. It connects to an address and it doesn’t know
if that address if of a Postgres instance or a load-balancer, pgpool or
anything else.

What happen if one of the postgresql server goes offline ?

Broadly speaking, nothing really bad will happen - but here are the detai=
ls.

Zato always reads in each and every piece of configuration it finds in
the ODB. That’s the reason servers start in 10-20 seconds rather than
1-2 seconds - because they need to issue dozens or hundreds of SQL
queries to get everything from the database.

This lets them be very quick in runtime on the one hand and on the other
hand it means that the database is not that much needed once servers
started.

So, as long as the servers only process incoming requests from client
applications and you don’t update a cluster’s configuration, the only
thing that will fail are background checks Zato internally performs in
order to check if the ODB is still alive - so the only bad thing will be
error messages in server.log pointing out that your DB has gone away.

On 17/11/14 15:00, bussiere bussiere wrote:

Ok thanks for the answer

Sure, just please remember that were are discussing implementation
details here.

Just to be 100% sure everything will go smoothly for you - an
environment needs an SQL DB - that it can disappear for a moment and the
fact will be tolerated is just a nice coincidence but shouldn’t be
something to build an architecture around.