Re: pg 9.0, streaming replication, fail over and fail back strategies

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: pg 9.0, streaming replication, fail over and fail back strategies
Дата
Msg-id AANLkTimQU2nugb9d7obTF7sZ-04VUwOnSBviHSD3=pGx@mail.gmail.com
обсуждение исходный текст
Ответ на pg 9.0, streaming replication, fail over and fail back strategies  ("Kyle R. Burton" <kyle.burton@gmail.com>)
Список pgsql-general
On Tue, Aug 10, 2010 at 7:10 AM, Kyle R. Burton <kyle.burton@gmail.com> wrote:
> Is there any way to get PostgreSQL to bind to a new ip address and
> interface without actually shutting it down?  If it could, would I
> need to break all the current (read only) client connections to get
> them to reconnect and have the ability to write?  (am I confused about
> this?)

What about setting listen_addresses to '*'? If so, you would be able to
connect to new master as soon as VIP has been moved to it.

> Now that the master+slave configuration is up and running again, I'm
> looking for advice on how to monitor for faults: I can fail over
> manually, which is fine for now.  What aspects of the postgres system
> should be monitored to watch for faults and what are the kinds of
> faults that should lead to a fail over?  The machine crashing (OS/HW)
> is an obvious one, which will be recognized by corosync and I can
> script the initiation of failover (including using ipmi to power down
> the master).

Probably the crash of the postgres and corosync process, the trouble
of VIP, and network outage between the master and the client should be
monitored, I think. Since any of them prevents the master from running
queries from the client, we should cause a failover.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

В списке pgsql-general по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: pg 9.0, streaming replication, fail over and fail back strategies
Следующее
От: Mabry Tyson
Дата:
Сообщение: Win Server 2003: postgres can't logon