Re: Urgent :: Postgresql streaming replication issue - sync mode

Поиск
Список
Период
Сортировка
От Shital A
Тема Re: Urgent :: Postgresql streaming replication issue - sync mode
Дата
Msg-id CAMp7vw_0pDWBd+GP1pt-078vkdDZAOuO9juwtP-PRSwCyMJEtw@mail.gmail.com
обсуждение исходный текст
Ответ на Urgent :: Postgresql streaming replication issue - sync mode  (Shital A <brightuser2019@gmail.com>)
Список pgsql-general
Дерево обсуждения


On Thu, 3 Oct 2019, 03:10 Jason Wang, <jasonwang.public@gmail.com> wrote:
I think when you use kill -9 it wouldn't give any chance for postgres to do what it normally does. So in your case, the db was killed with no chance to apply to remote then it would be up to the recovery to decide how to handle the extra data at the master. I'm not sure what would happen but killall in general is a dangerous command.

On Thu, 3 Oct 2019, 7:00 am Shital A, <brightuser2019@gmail.com> wrote:


On Thu, 3 Oct 2019, 00:08 Ravi Krishna, <srkrishna@vivaldi.net> wrote:
>
> As the failed primary is having more data, How is it possible that primary is committing transaction before they were applied on standby with synchronous_commit=remote_apply?

If I am not mistaken remote_apply is only from ver 11.

Hi Ravi,

Thanks for your reply.

This property/feature is available in 9.6.


Thanks!

Thanks Jason.

Using killall -9 we are trying to simulate the situation where primary is stopped unexpectedly/crashed.

So in this case there is data loss because when the broken primary later comes in sync with new primary it copies data from new primary and the data records that were extra in old primary are lost. Can this data loss be prevented in anyway in postgres 9.6 ? Please suggest. 


Thanks! 

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

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: performance of pg_upgrade "Copying user relation files"
Следующее
От: Pankaj Jangid
Дата:
Сообщение: Re: PG11 Parallel Thanks!!