Re: Replication and PITR - Mailing list pgsql-general

From Bo Lorentsen
Subject Re: Replication and PITR
Date
Msg-id 4517C216.2020700@netgroup.dk
Whole thread Raw
In response to Re: Replication and PITR  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Replication and PITR
Re: Replication and PITR
List pgsql-general
Jeff Davis wrote:
> Standby mode means that the database is kept almost up to date with the
> master, but is not "up". When the master goes down, you can bring the
> standby machine up. Until then, you unfortunately can't even do read
> queries on that machine.
>
Do you know if this will change in the future ?
> If you want more of a master/slave setup for performance, you should
> take a second look at Slony. A PITR standby doesn't help you with
> performance at all.
>
Ok, I can see that ... so PITR is for a standby backup DB, with at the
best ... manual fail over ?
> Why don't you like the fact that Slony is trigger-based? Does that cause
> you a problem?
>
Hmm, well i guess i dislike the idea of having a high level mechanism to
collect data, not a rational argument, sorry. The PITR just seemed so
right as it has a more prober low level approach, but it sound to me
like Slony is the only real choice at the moment, and it will do the job
with a relatively low overhead.
> And missing DDL is mainly a problem when you want to provide postgresql
> to many people, and you have no idea how they will use it. If that's the
> case, standby PITR might be a better solution for you. Slony has nice
> "execute script" functionality that is useful for making DDL changes on
> all machines.
>
Ok, I think that the only thing I really need to do is to try to work
more with Slony and learn to understand it. And the DDL problem is more
when others need to maintain the system, and I then have to explain how
to do this and that, and I think I am a bit spoiled by the easy working
of the mysql replication :-)
> Asynchronous does have very good performance.
>
So, Slony also do some queuing to gain low overhead ?
> I prefer working with async when possible because it's easier to do
> well. I was just making sure you knew that it is possible to lose
> transactions.
>
Thanks, one never know :-)
> By the way, no matter what you do, you probably do want to use the PITR
> to at least do backups for you. It won't help to use replication if
> someone accidentally does an unqualified "DELETE FROM mytable".
>
Yeps, a master and and slave with Slony replication and backup from the
slave database, that seems to be the plan at the moment.

/BL

pgsql-general by date:

Previous
From: Alban Hertroys
Date:
Subject: Re: in failed sql transaction
Next
From: Matthias.Pitzl@izb.de
Date:
Subject: Re: copy db1 to db2