Re: Timeline Conflict

Поиск
Список
Период
Сортировка
От Pedro Sam
Тема Re: Timeline Conflict
Дата
Msg-id 077B647C27DECA4F915A81CA368C84C303179EB02A@XCH119CNC.rim.net
обсуждение исходный текст
Ответ на Re: Timeline Conflict  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Timeline Conflict
Re: Timeline Conflict
Список pgsql-general
I've been trying to use repmgr for just that purpose.  Looks like it simply creates/modifies a recovery.conf pointing
primary_conninfoto the new master, and then restart.  It does not seem to have the ability to resolve any timeline
conflictsat all. 

Am I using repmgr incorrectly?

-----Original Message-----
From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Simon Riggs
Sent: Tuesday, August 02, 2011 12:07 PM
To: Merlin Moncure
Cc: senthilnathan; pgsql-general
Subject: Re: [GENERAL] Timeline Conflict

On Tue, Aug 2, 2011 at 2:55 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Tue, Aug 2, 2011 at 12:59 AM, senthilnathan
> <senthilnathan.t@gmail.com> wrote:
>> We have system(Cluster) with Master replicating to 2 stand by servers.
>>
>> i.e
>>
>> M   |-------> S1
>>
>>      |-------> S2
>>
>> If master failed, we do a trigger file at S1 to take over as master. Now
>> we
>> need to re-point the standby S2 as slave for the new master (i.e S1)
>>
>> While trying to start standby S2,there is a conflict in timelines, since
>> on
>> recovery it generates a new line.
>>
>> Is there any way to solve this issue?
>
> AFAIK, the only solution is to follow the initial standby setup
> process to bring the standby up to sync with the new master.  One
> small comfort is that since the standby is mostly in the state it
> needs to be, an rsync based process might happen fairly quickly.  This
> of course means that if you lose the new master before the standby is
> up to speed you are facing data loss.  I'm really curious if anyone
> has figured out a potential solution to this problem.

http://projects.2ndquadrant.com/repmgr

solves the problem

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including
materialprotected by the solicitor-client or other applicable privileges), or constitute non-public information. Any
useof this information by anyone other than the intended recipient is prohibited. If you have received this
transmissionin error, please immediately reply to the sender and delete this information from your system. Use,
dissemination,distribution, or reproduction of this transmission by unintended recipients is not authorized and may be
unlawful.

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

Предыдущее
От: devrim@gunduz.org
Дата:
Сообщение: Re: 9.0 Streaming Replication Problem to two slaves
Следующее
От: Rory Campbell-Lange
Дата:
Сообщение: Problem with selecting arrays in set-returning plpgsql function