I got it should be LSN + MAXALIGN(xlogrecord length) 👍
Thanks a lot.
> On 2 Jun 2020, at 19:11, Jehan-Guillaume de Rorthais wrote:
>
> Nope, just sum the xlogrecord length.
On Mon, 1 Jun 2020 12:44:26 +0500
godjan • wrote:
> Hi, sorry for 2 weeks latency in answer :)
>
> >> It fixed out trouble, but there is one another. Now we should wait when all
> >> ha alive hosts finish replaying WAL to failover. It might take a while(for
> >> example WAL contains wal_record a
Hi, sorry for 2 weeks latency in answer :)
>> It fixed out trouble, but there is one another. Now we should wait when all
>> ha alive hosts finish replaying WAL to failover. It might take a while(for
>> example WAL contains wal_record about splitting b-tree).
>
> Indeed, this is the concern I wro
(please, the list policy is bottom-posting to keep history clean, thanks).
On Thu, 14 May 2020 07:18:33 +0500
godjan • wrote:
> -> Why do you kill -9 your standby?
> Hi, it’s Jepsen test for our HA solution. It checks that we don’t lose data
> in such situation.
OK. This test is highly usefu
-> Why do you kill -9 your standby?
Hi, it’s Jepsen test for our HA solution. It checks that we don’t lose data in
such situation.
So, now we update logic as Michael said. All ha alive standbys now waiting for
replaying all WAL that they have and after we use pg_last_replay_lsn() to
choose whi
On Mon, 11 May 2020 15:54:02 +0900
Michael Paquier wrote:
[...]
> There are several HA solutions floating around in the community, and I
> got to wonder as well if some of them don't just scan the local
> pg_wal/ of each standby in this case, even if that's more simple to
> let the nodes start and
(too bad the history has been removed to keep context)
On Fri, 8 May 2020 15:02:26 +0500
godjan • wrote:
> I got it, thank you.
> Can you recommend what to use to determine which quorum standby should be
> promoted in such case? We planned to use pg_last_wal_receive_lsn() to
> determine which
On Sun, May 10, 2020 at 06:58:50PM +0500, godjan • wrote:
> synchronous_standby_names=ANY 1(host1, host2)
> synchronous_commit=on
Thanks for the details. I was not sure based on your previous
messages.
> So to understand which standby wrote last data to disk I should know
> receive_lsn or write
synchronous_standby_names=ANY 1(host1, host2)
synchronous_commit=on
So to understand which standby wrote last data to disk I should know
receive_lsn or write_lsn.
Sent from my iPhone
> On 9 May 2020, at 13:48, Michael Paquier wrote:
>
> On Fri, May 08, 2020 at 03:02:26PM +0500, godjan • wrot
On Fri, May 08, 2020 at 03:02:26PM +0500, godjan • wrote:
> Can you recommend what to use to determine which quorum standby
> should be promoted in such case?
> We planned to use pg_last_wal_receive_lsn() to determine which has
> fresh data but if it returns the beginning of the segment on both
>
I got it, thank you.
Can you recommend what to use to determine which quorum standby should be
promoted in such case?
We planned to use pg_last_wal_receive_lsn() to determine which has fresh data
but if it returns the beginning of the segment on both replicas we can’t
determine which standby con
Hello
Yes, this is expected. Walreceiver always start streaming from beginning of the
wal segment.
./src/backend/replication/walreceiverfuncs.c in RequestXLogStreaming:
* We always start at the beginning of the segment. That prevents a
broken
* segment (i.e., with no records i
PG12
Steps to reproduce on 3 nodes cluster with quorum commit.
1. Cut off network on master with everything.
2. Pkill -9 PostgreSQL on each node.
3. Start PostgreSQL on each node.
What was strange?
I check every second pg_last_wal_replay_lsn() and pg_last_wal_receive_lsn().
All time it was the s
13 matches
Mail list logo
