On 02/28/2017 02:20 PM, Sasa Vilic wrote:
On 2017-02-28 16:41, Adrian Klaver wrote:
Seems to mean the simpler thing to do would be to set standby to
archive_mode = on, in which case the standby would not contribute WAL's
until it was promoted which would seem to be what you want.
Yes, that
On 2017-02-28 16:57, Jon Nelson wrote:
What does pg_xlogdump say about the differences in the files?
What a nice tool. I didn't realize that it exists for 9.6.
Unfortunately, we gave up on shared WAL archive, so I don't if I will
still have all both WALs. I have one conflicting WAL from one
On 2017-02-28 16:41, Adrian Klaver wrote:
Seems to mean the simpler thing to do would be to set standby to
archive_mode = on, in which case the standby would not contribute WAL's
until it was promoted which would seem to be what you want.
Yes, that was my first thought. Except that
On Tue, Feb 28, 2017 at 9:41 AM, Adrian Klaver
wrote:
> On 02/27/2017 11:14 PM, Sasa Vilic wrote:
> ...
>
> "My problem is that sometimes WAL uploaded from master and from slave are
> not 100% identical. In most cases they are but occasionally they are not. I
> have
On 02/27/2017 11:14 PM, Sasa Vilic wrote:
On 2017-02-28 06:14, Adrian Klaver wrote:
On 02/27/2017 05:52 PM, Sasa Vilic wrote:
Because standby is running in syncronous replication, whereby wal
archiver is asynchronous. Therefore there is a small window where slave
has received the data but
On 2017-02-28 06:14, Adrian Klaver wrote:
On 02/27/2017 05:52 PM, Sasa Vilic wrote:
Because standby is running in syncronous replication, whereby wal
archiver is asynchronous. Therefore there is a small window where slave
has received the data but master has not pushed it yet to wal archive.
On 02/27/2017 05:52 PM, Sasa Vilic wrote:
Because standby is running in syncronous replication, whereby wal
archiver is asynchronous. Therefore there is a small window where slave
has received the data but master has not pushed it yet to wal archive.
Exactly. The standby already has the latest
On Mon, Feb 27, 2017 at 7:32 PM, Sasa Vilic wrote:
>
> My general idea is to have synchronous hot standby and asynchronous shared
> wal archive. If that were possible I could actually switch back and forth
> between master and slave without interrupting wal stream and with
Am 28.02.2017 02:50 schrieb "David G. Johnston" :
It is customary to inline or bottom-posts on these lists. Please follow
the example of those responding to your emails.
On Mon, Feb 27, 2017 at 6:45 PM, Sasa Vilic wrote:
> And also this:
>
>
On Mon, Feb 27, 2017 at 6:10 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> But IIUC the system seems designed around master->slave replication and
> doesn't support slave daisy-chains.
>
>
I thought that sounded wrong when I wrote it...
Because standby is running in syncronous replication, whereby wal archiver
is asynchronous. Therefore there is a small window where slave has received
the data but master has not pushed it yet to wal archive.
Regards,
Sasa
Am 28.02.2017 02:48 schrieb "Adrian Klaver" :
It is customary to inline or bottom-posts on these lists. Please follow
the example of those responding to your emails.
On Mon, Feb 27, 2017 at 6:45 PM, Sasa Vilic wrote:
> And also this:
>
> """
> If archive_mode is set to on, the archiver is not enabled during recovery
>
On 02/27/2017 05:29 PM, Sasa Vilic wrote:
Master is streaming directly to standby. Both master and standby are
pushing WALs to archive.
My point is that in case that master crashed completely (and we failover
to standby) and wal archiver on master didn't push everything to wal
archive, we would
And also this:
"""
If archive_mode is set to on, the archiver is not enabled during recovery
or standby mode. If the standby server is promoted, it will start archiving
after the promotion, but will not archive any WAL it did not generate
itself. To get a complete series of WAL files in the
On Mon, Feb 27, 2017 at 6:33 PM, Sasa Vilic wrote:
> Hi David,
>
> thanks for the answer. I read this in documentation but here there is a
> corner case that I am not sure how to handle:
> """
> This requires more care in the archive_command, as it must be careful to
> not
Hi David,
thanks for the answer. I read this in documentation but here there is a
corner case that I am not sure how to handle:
"""
This requires more care in the archive_command, as it must be careful to
not overwrite an existing file with different contents, *but return success
if the exactly
Master is streaming directly to standby. Both master and standby are
pushing WALs to archive.
My point is that in case that master crashed completely (and we failover to
standby) and wal archiver on master didn't push everything to wal archive,
we would still have a wal pushed from slave.
On Mon, Feb 27, 2017 at 5:40 PM, Sasa Vilic wrote:
> Aren't WALs from master and standby supposed to be identical?
>
This would seem unwise to assume on its face and at least one piece of
documentation directly mentions that it is false:
On 02/27/2017 04:40 PM, Sasa Vilic wrote:
Hallo,
I am trying to setup shared WAL archive between master and standby.
Standby is synchronously streaming from master and both servers run with
archive_mode = always. The ideas is that when promoting standby to
master we would not missed WALs.
I
Hallo,
I am trying to setup shared WAL archive between master and standby. Standby
is synchronously streaming from master and both servers run with
archive_mode = always. The ideas is that when promoting standby to master
we would not missed WALs.
My problem is that sometimes WAL uploaded from
20 matches
Mail list logo