Re: Turning recovery.conf into GUCs

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Turning recovery.conf into GUCs
Дата
Msg-id 20150107011702.GC6173@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: Turning recovery.conf into GUCs  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Turning recovery.conf into GUCs  (Kevin Grittner <kgrittn@ymail.com>)
Список pgsql-hackers
On 2015-01-06 17:08:20 -0800, Josh Berkus wrote:
> On 01/06/2015 04:42 PM, Andres Freund wrote:
> > On 2015-01-06 16:33:36 -0800, Josh Berkus wrote:
> >> F. Inability to remaster without restarting the replica.
> > 
> > That has pretty much nothing to do with the topic at hand.
> 
> It has *everything* to do with the topic at hand.  The *only* reason we
> can't remaster without restarting is that recovery.conf is only read at
> startup time, and can't be reloaded.

> http://www.databasesoup.com/2014/05/remastering-without-restarting.html

Not really. It's a good way to introduce suble and hard to understand
corruption and other strange corner cases. Your replication connection
was lost/reconnected in the wrong moment? Oops, received/replayed too
much.

To achieve what you describe there, you don't even need a proxy, simple
dns based failover suffices.

A real solution to this requires more. You need to 1) disable writing
any wal 2) force catchup of all possible standbys, including apply. Most
importantly of the new master. This requires knowing which standbys
exist. 3) promote new master. 4) only now allow reconnects.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Turning recovery.conf into GUCs
Следующее
От: Amit Langote
Дата:
Сообщение: Re: Possible typo in create_policy.sgml