Given that you are using a less then capable storage solution(S3) why do you think pushing the WAL from the standby to S3 would perform any better then what is happening with the primary WAL?
I mean that archive_mode is set to on in primary and set to always in standby.
This way, even if the primary crashes, the standby can still archive WAL files that the primary did not archive.
The solution is to use a more capable storage platform.
However, I believe that even if we use a more capable storage platform, it is still impossible to archive WAL files in real time. As long as real-time archiving cannot be achieved, there will always be some WAL files that are not archived if the primary node crashes.
On 8/12/25 01:24, px shi wrote: > > 1) What is the current archiving setup on the primary and why is > lagging? > > The archive command uses pgBackRest to archive to S3. Because it is > uploaded to S3, the archiving speed is slow, which has caused lagging. > > 2) Have you looked at archiving off the standby node while it is in > standby per: > > Yes, archiving on the standby node is disabled. Is it recommended to > share the WAL archive between the primary and standby nodes to avoid > interruptions in archiving?
Given that you are using a less then capable storage solution(S3) why do you think pushing the WAL from the standby to S3 would perform any better then what is happening with the primary WAL?
The solution is to use a more capable storage platform.
