Re: Postgres Synchronous replication

Поиск
Список
Период
Сортировка
От Gilberto Castillo
Тема Re: Postgres Synchronous replication
Дата
Msg-id 44694.192.168.207.54.1432243144.squirrel@webmail.etecsa.cu
обсуждение исходный текст
Ответ на Re: Postgres Synchronous replication  (Keith <keith@keithf4.com>)
Ответы Re: Postgres Synchronous replication  (Keith <keith@keithf4.com>)
Список pgsql-admin

> On Thu, May 21, 2015 at 4:10 PM, Ravi Krishna <sravikrishna3@gmail.com>
> wrote:
>
>>
>> AFAIK the commit on master happens only after it receives ack from the
>>> slave. This is how synchronous replication ensures that the slave is'in
>>> sync'.
>>>
>>
>>
>> If that is the case , then why does PG find it impossible to sync back
>> with the primary after a crash.
>> Other products offering similar technology do not have this issue.
>>
>> In my opinion this is quite a serious limitation with PG replication.
>> Every time the primary crashes and the business continues with the
>> promotion of standby as the new primary, the crashed server has to be
>> reinitialized for the set up of the replication.
>>
>>
>>
>>>
>>> On Thu, May 21, 2015 at 3:56 PM, Ravi Krishna <sravikrishna3@gmail.com>
>>> wrote:
>>>
>>>> I want to understand how PG sync replication works. This is what I
>>>> know
>>>> (assuming two node sync replication)
>>>>
>>>> 1 - Application issues commit.
>>>> 2 - PG commits the transaction locally on the primary server.
>>>> 3 - At this stage the application has not got the commit indication
>>>> back.
>>>> 4 - PG transmits the transaction from the local to the remote server.
>>>> 5 - Remote server sends back acknowledgement
>>>> 6 - The app gets commit ack back.
>>>>
>>>> So this means, between step 2 and step 6, the app is not aware that
>>>> the
>>>> transaction has already been committed.
>>>> This is the reason why, in the event of server crashing between step 2
>>>> and step 6, and the remote takes over as the
>>>> new primary, the crashed server can not restart as standby and the
>>>> only
>>>> option is to recreate the db from the remote
>>>> server (which is now acting as the primary).
>>>>
>>>> Am I correct in the understanding?
>>>>
>>>> One more question: In Step 5, does the remote harden the transaction
>>>> on
>>>> the disk, or merely receives the transaction in the log buffer and it
>>>> sends
>>>> back ACK to the local server.
>>>>
>>>> Thanks
>>>>
>>>
>>>
>>
>
> This issue has been address with pg_rewind in the upcoming 9.5 major
> version release
>
> http://hlinnaka.iki.fi/2015/03/23/pg_rewind-in-postgresql-9-5/

pg_rewind is used 9.3 onwards

Saludos,
Gilberto Castillo
ETECSA, La Habana, Cuba
---
This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE running at host imx3.etecsa.cu
Visit our web-site: <http://www.kaspersky.com>, <http://www.viruslist.com>

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

Предыдущее
От: Keith
Дата:
Сообщение: Re: Postgres Synchronous replication
Следующее
От: Scott Ribe
Дата:
Сообщение: Re: Postgres Synchronous replication