Re: [External] Re: WAL Replication query

Поиск
Список
Период
Сортировка
От Ron
Тема Re: [External] Re: WAL Replication query
Дата
Msg-id 42306ea2-74c2-a95e-551d-e1d16946c083@gmail.com
обсуждение исходный текст
Ответ на Re: [External] Re: WAL Replication query  (Laurenz Albe <laurenz.albe@cybertec.at>)
Ответы Re: [External] Re: WAL Replication query  (Laurenz Albe <laurenz.albe@cybertec.at>)
Список pgsql-admin
On 11/1/22 08:34, Laurenz Albe wrote:
On Tue, 2022-11-01 at 02:43 -0500, Ron wrote:
On 11/1/22 01:53, Laurenz Albe wrote:
On Tue, 2022-11-01 at 06:44 +0000, Sacheen Birhade wrote:
If replication is in asynchronous then there will be data loss, right Laurenz?
Why?  The data will perhaps show up on the standby a little later, but why is
that data loss?  Remember that the question was about replication, and there
was no mention of failover.
 No, the question was about a crash during replication: OP (not Sacheen, unless that person
is using two email addresses) explicitly asked "When the primary crashes  due an unforeseen
reason (what happens)?"
 
 If the two database systems are really busy, and especially if the network connection
isn't fast enough, async replication means there might be some transactions committed
on Primary which were queued for transmission, but hadn't yet made it to the Secondary, right?
Right.  And how does that constitute data loss?  If you start the primary again, the transaction
will be replicated just fine.  Now if you call it *data delay*, I would agree.

Primary has crashed, according to OP; it's not coming back any time soon.  And thus you promote Secondary to be New Primary, and go about  your work.  When the Old Primary comes back up (hours or days later), you do a pg_basebackup to make it the New Secondary.

--
Angular momentum makes the world go 'round.

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

Предыдущее
От: Laurenz Albe
Дата:
Сообщение: Re: finding best possible new master in case of failover?
Следующее
От: Scott Ribe
Дата:
Сообщение: Re: [External] WAL Replication query