Re: Replication and PITR

Поиск
Список
Период
Сортировка
От Bo Lorentsen
Тема Re: Replication and PITR
Дата
Msg-id 4517C216.2020700@netgroup.dk
обсуждение исходный текст
Ответ на Re: Replication and PITR  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Replication and PITR  (Jeff Davis <pgsql@j-davis.com>)
Re: Replication and PITR  (Robert Treat <xzilla@users.sourceforge.net>)
Список 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 по дате отправления:

Предыдущее
От: Alban Hertroys
Дата:
Сообщение: Re: in failed sql transaction
Следующее
От: Matthias.Pitzl@izb.de
Дата:
Сообщение: Re: copy db1 to db2