>-Original Message-
>From: Andres Freund [mailto:and...@anarazel.de]
>Sent: Wednesday, August 09, 2017 6:34 PM
>To: Seong Son (US)
>Cc: pgsql-general@postgresql.org
>Subject: Re: [GENERAL] streaming replication - crash on standby
>
>Hi,
>
>Please quote prop
Hi,
Please quote properly on postgres mailing lists.
On 2017-08-09 22:31:23 +, Seong Son (US) wrote:
> I see. Thank you.
>
> But the Postgresql process had crashed at that time so the streaming
> replication was no longer working. Why would it crash and is that normal?
You've given us
.
-Original Message-
From: Andres Freund [mailto:and...@anarazel.de]
Sent: Wednesday, August 09, 2017 6:27 PM
To: Seong Son (US)
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] streaming replication - crash on standby
Hi,
On 2017-08-09 22:03:43 +, Seong Son (US) wrote:
>
Hi,
On 2017-08-09 22:03:43 +, Seong Son (US) wrote:
> The last line from pg_xlogdump of the last WAL file on the crashed standby
> server shows the following.
>
> pg_xlogdump: FATAL: error in WAL record at DF/4CB95FD0: unexpected pageaddr
> DB/62B96000 in log segment 00DF00
On Fri, Jul 21, 2017 at 8:15 AM, Andreas Kretschmer
wrote:
> Am 21.07.2017 um 08:01 schrieb Michael Paquier:
>> "No" is not completely exact and lacks in details. There are two cases
>> where having an archive is helpful:
>> 1) The standby has disconnected from its primary for a time long
>> enoug
Am 21.07.2017 um 08:01 schrieb Michael Paquier:
On Thu, Jul 20, 2017 at 10:07 PM, Leonardo M. Ramé wrote:
El 20/07/17 a las 16:57, Andreas Kretschmer escribió:
On 20 July 2017 21:46:09 GMT+02:00, "Leonardo M. Ramé"
wrote:
Hi, I wonder if archive_mode=on and archive_command parameters in
po
On Thu, Jul 20, 2017 at 10:07 PM, Leonardo M. Ramé wrote:
> El 20/07/17 a las 16:57, Andreas Kretschmer escribió:
>> On 20 July 2017 21:46:09 GMT+02:00, "Leonardo M. Ramé"
>> wrote:
>>>
>>> Hi, I wonder if archive_mode=on and archive_command parameters in
>>> postgresql.conf are really needed for
On 20/07/2017 23:07, Leonardo M. Ramé wrote:
El 20/07/17 a las 16:57, Andreas Kretschmer escribió:
On 20 July 2017 21:46:09 GMT+02:00, "Leonardo M. Ramé"
wrote:
Hi, I wonder if archive_mode=on and archive_command parameters in
postgresql.conf are really needed for streaming replication betw
El 20/07/17 a las 16:57, Andreas Kretschmer escribió:
On 20 July 2017 21:46:09 GMT+02:00, "Leonardo M. Ramé"
wrote:
Hi, I wonder if archive_mode=on and archive_command parameters in
postgresql.conf are really needed for streaming replication between two
servers (master-slave).
Regards,
N
On 20 July 2017 21:46:09 GMT+02:00, "Leonardo M. Ramé"
wrote:
>Hi, I wonder if archive_mode=on and archive_command parameters in
>postgresql.conf are really needed for streaming replication between two
>
>servers (master-slave).
>
>Regards,
No.
Andreas
--
2ndQuadrant - The PostgreSQL Suppor
Am 20. Juni 2017 03:06:05 MESZ schrieb Peter Eisentraut
:
>On 6/19/17 20:50, Maeldron T. wrote:
>>
>
>Not easily. You could play around with pg_xlogdump to see what's going
>on in the WAL. But even if you figure it out, there is not much you
>can
>do about it.
>
>Try perhaps logical replication
On 6/19/17 20:50, Maeldron T. wrote:
> Streaming replication generates too much traffic to set it up between
> different regions for financial reasons. The streaming replication would
> cost more than every other hosting expense altogether (including every
> the traffic, even though it’s web and hu
2017-04-18 22:46 GMT-03:00 Jeff Janes :
> On Tue, Apr 18, 2017 at 5:20 AM, Luciano Mittmann
> wrote:
>
>>
>>
>> Hi Jeff,
>>
>> **Does each file in pg_xlog/archive_status/ have a corresponding file
>> one directory up?
>>
>> no corresponding file on pg_xlog directory. That is the question.. for
>>
On Tue, Apr 18, 2017 at 5:20 AM, Luciano Mittmann
wrote:
>
>
> Hi Jeff,
>
> **Does each file in pg_xlog/archive_status/ have a corresponding file one
> directory up?
>
> no corresponding file on pg_xlog directory. That is the question.. for
> some reason or some parameter that I do not know, the
2017-04-17 20:04 GMT-03:00 Jeff Janes :
> 2017-04-17 17:08 GMT-03:00 Jeff Janes :
>
>> On Mon, Apr 17, 2017 at 12:22 PM, Luciano Mittmann
>> wrote:
>>
>>> Hi All,
>>>
>>> anyone knows why there are so many files in the directory
>>> pg_xlog/archive_status/ in replication server?
>>>
>>> # pg_xlog
2017-04-17 17:08 GMT-03:00 Jeff Janes :
> On Mon, Apr 17, 2017 at 12:22 PM, Luciano Mittmann
> wrote:
>
>> Hi All,
>>
>> anyone knows why there are so many files in the directory
>> pg_xlog/archive_status/ in replication server?
>>
>> # pg_xlog/archive_status/ | wc -l
>>
>> 75217
>>
>> Is possib
Version 9.6.2
Checkpoint on primary server:
[ 2017-04-17 17:23:25 BRT] @ LOG: checkpoint complete: wrote 19436 buffers
(2.4%); 0 transaction log file(s) added, 2 removed, 7 recycled;
write=149.506 s, sync=0.310 s, total=149.958 s; sync files=370,
longest=0.012 s, average=0.000 s; distance=133971
Hi Jeff,
checkpoint message on standby node:
[ 2017-04-17 17:21:56 BRT] @ LOG: restartpoint complete: wrote 21475
buffers (2.6%); 0 transaction log file(s) added, 0 removed, 0 recycled;
write=149.816 s, sync=0.064 s, total=149.890 s; sync files=314,
longest=0.002 s, average=0.000 s; distance=145
On Mon, Apr 17, 2017 at 12:22 PM, Luciano Mittmann
wrote:
> Hi All,
>
> anyone knows why there are so many files in the directory
> pg_xlog/archive_status/ in replication server?
>
> # pg_xlog/archive_status/ | wc -l
>
> 75217
>
> Is possible to clean this .done files or just don't need to worry
ata B N
Database consultant
-- Forwarded message --
From: *Achilleas Mantzios* mailto:ach...@matrix.gatewaynet.com>>
Date: 2017-02-17 11:20 GMT-02:00
Subject: Re: [GENERAL] Streaming Replication Without Downtime
To: pgsql-general@postgresql.org <mailto:pgsql-general@
e you using by the way ?
> If I do so, do I need do restart the master or just a reload will do it?
>
No need to restart, "reload" will do.
Venkata B N
Database consultant
> ------ Forwarded message --
> From: Achilleas Mantzios
> Date: 2017-02-17 11:2
Gabriel you are thinking this in the correct way, but its really :
pg_basebackup -D --write-recovery-conf --progress
--xlog-method=stream -h
then you just edit recovery.conf (if needed), tweak postgersql.conf (if needed)
and start the standby .
On 17/02/2017 15:09, Gunnar "Nick" Bluth wrote:
(sorry for the toppost, mobile device)
What you're looking for is pg_basebackup with - - xlog=stream, I guess.
Regards,
Nick
Am 17. Februar 2017 14:06:36 MEZ schrieb Gabriel Ortiz Lour
:
>Hi all,
>I've been searching for a way to initialize a new Hot Standby node with
>Streaming Replicati
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Torsten Förtsch asked:
> is there a perl module that allows to speak the streaming replication
> protocol?
Not that I know of.
> Can DBD::Pg do that anyhow?
Nope.
> I think I could just pipe from pg_recvlogical. But would be cool to have
On 06/12/2016 04:20, Patrick B wrote:
Hi guys,
I've got some database servers in USA (own data center) and also @ AWS Japan.
*USA:*
master01
slave01 (Streaming Replication from master01 + wal_files)
slave02 (Streaming Replication from master01 + wal_files)
*Japan: (Cascading replication)*
slav
On Nov 18, 2016, at 5:48 AM, Jehan-Guillaume de Rorthais wrote:
>
> On Thu, 17 Nov 2016 08:26:59 -0900
> Israel Brewster mailto:isr...@ravnalaska.net>> wrote:
>
>>> On Nov 16, 2016, at 4:24 PM, Adrian Klaver
>>> wrote:
>>>
>>> On 11/16/2016 04:51 PM, Israel Brewster wrote:
I've been pla
On Thu, 17 Nov 2016 08:26:59 -0900
Israel Brewster wrote:
> > On Nov 16, 2016, at 4:24 PM, Adrian Klaver
> > wrote:
> >
> > On 11/16/2016 04:51 PM, Israel Brewster wrote:
> >> I've been playing around with streaming replication, and discovered that
> >> the following series of steps *appears*
On Nov 16, 2016, at 11:39 PM, Jehan-Guillaume de Rorthais
wrote:
>
> On Wed, 16 Nov 2016 15:51:26 -0900
> Israel Brewster mailto:isr...@ravnalaska.net>> wrote:
>
>> I've been playing around with streaming replication, and discovered that the
>> following series of steps *appears* to work withou
> On Nov 16, 2016, at 4:24 PM, Adrian Klaver wrote:
>
> On 11/16/2016 04:51 PM, Israel Brewster wrote:
>> I've been playing around with streaming replication, and discovered that
>> the following series of steps *appears* to work without complaint:
>>
>> - Start with master on server A, slave
On Wed, 16 Nov 2016 15:51:26 -0900
Israel Brewster wrote:
> I've been playing around with streaming replication, and discovered that the
> following series of steps *appears* to work without complaint:
>
> - Start with master on server A, slave on server B, replicating via streaming
> replicatio
On 11/16/2016 04:51 PM, Israel Brewster wrote:
I've been playing around with streaming replication, and discovered that
the following series of steps *appears* to work without complaint:
- Start with master on server A, slave on server B, replicating via
streaming replication with replication sl
Sure you're right... my oversight, sorry. I wanted only to create a
situation in which the standby remains quite behind with updates, so we
can suppose that there is a list of standby servers (so the primary
keeps going on with the 2nd) or simply suppose the replication async.
Pupillo
Il 25/10
I may be confused but...
On Tue, Oct 25, 2016 at 5:08 PM, t.dalpo...@gmail.com
wrote:
> These servers are configured for Sync streaming replication .
> Let's suppose that the standby stays down for a long time, then it restarts,
Doesn't sync replication plus standby down mean primary will stop
a
On Tuesday 25 October 2016 17:08:26 t.dalpo...@gmail.com wrote:
> Hi,
> let's suppose I have:
> - a primary server with its own local archive location, configured for
> continuous archiving
> - a standby server without archive.
> These servers are configured for Sync streaming replication .
> L
sorry... wrong email. Will create a new topic.
Hi guys,
I'm setting up a new slave server, using Postgres 9.2. This new slave
server I'll call: New_slave.
I ran this command, from the new_slave server. It will connects to my other
slave and copy the DB.
ssh postgres@slave05 'pg_basebackup --pgdata=- --format=tar
> --label=new_slave --progres
On 07/10/2016 07:17 PM, Patrick B wrote:
If the master server can't send the wal_files through the slaves,
shouldn't the wal_files be in "background" waiting to be delivered?
Short version, yes, assuming you are talking about archiving the WAL
files somewhere and assuming there is sufficient
On 7/10/2016 8:51 PM, Patrick B wrote:
what if the network goes down?
that WAL server could be located in the same data center as the master
database server. if your local area network goes down, well, you're
probably in a world of hurt.
if the wide area network is mission critical, it wou
2016-07-11 15:48 GMT+12:00 John R Pierce :
> On 7/10/2016 4:28 PM, Patrick B wrote:
>
>>
>> archive_command = 'cp %p /var/lib/pgsql/archive/%f'
>>
>>
>> That would be ok right guys?
>>
>>
>
> normally, you want to ship your WAL archives to a NFS server or something
> similar, which the master and
On 7/10/2016 4:28 PM, Patrick B wrote:
archive_command = 'cp %p /var/lib/pgsql/archive/%f'
That would be ok right guys?
normally, you want to ship your WAL archives to a NFS server or
something similar, which the master and all the slaves can read.
--
john r pierce, recycling bits in sa
oh ok.. got it..
wal_keep_segments = To prevent the primary server from removing the
WAL segments required for the standby server before shipping them, set
the minimum number of segments retained in the pg_xlog directory
so it would be ok just by increasing that parameter, right? Once the
serve
If the master server can't send the wal_files through the slaves, shouldn't
the wal_files be in "background" waiting to be delivered?
Otherwise what's the purpose of them? If a network fails I'd loose those
files?
2016-07-11 12:18 GMT+12:00 Adrian Klaver :
> On 07/10/2016 04:28 PM, Patrick B wrote:
>
>> archive_command = 'cp %p /var/lib/pgsql/archive/%f'
>>
>
> This would be where?
>
master server
>
> And does the corresponding restore_command point to the same place?
yes.. the slaves have the restore_
On 07/10/2016 04:28 PM, Patrick B wrote:
archive_command = 'cp %p /var/lib/pgsql/archive/%f'
This would be where?
And does the corresponding restore_command point to the same place?
That would be ok right guys?
I will also setup wal_keep_segments to 512
The WAL segments kept would be d
archive_command = 'cp %p /var/lib/pgsql/archive/%f'
That would be ok right guys?
I will also setup wal_keep_segments to 512
thanks guys.. thanks for all the comments...
I'm not shipping the wal_files into master, I actually ship them into slave
and another backup server as well.
So I'll have to change my archive_command then :)
Thanks!
On 7/10/2016 2:42 PM, Andreas Kretschmer wrote:
1. When the connection comes back, will the master and slave work as
expected? The streaming replication should be ok?
if the master holds all needed WAL's there should be no problem.
You can ensure that with wal_keep_segments, or, in newer versio
Am 10.07.2016 um 23:19 schrieb Patrick B:
Hi all,
There will be a network maintenance at the company where my servers are...
I've got one master and one slave server, running PostgreSQL 9.2.
As the network will be down, the internet won't be working as well as
the intranet. Both servers won
On 07/10/2016 02:19 PM, Patrick B wrote:
Hi all,
There will be a network maintenance at the company where my servers are...
I've got one master and one slave server, running PostgreSQL 9.2.
As the network will be down, the internet won't be working as well as
the intranet. Both servers won't b
On 7/10/2016 2:19 PM, Patrick B wrote:
1. When the connection comes back, will the master and slave work as
expected? The streaming replication should be ok?
as long as you have sufficient WAL available it should recover fine.
you might have to restart the slave to get it to reconnect.
2.
On Sat, May 14, 2016 at 5:38 PM, Venkata Balaji N wrote:
>
> On Wed, May 11, 2016 at 9:04 PM, wrote:
>
>> I apologise for the missing data.
>>
>> we are running 9.1.15 on debian servers.
>>
>
> There is a possibility of making the old master standby if you have
> promoted standby after clean-shu
On Wed, May 11, 2016 at 9:04 PM, wrote:
> I apologise for the missing data.
>
> we are running 9.1.15 on debian servers.
>
There is a possibility of making the old master standby if you have
promoted standby after clean-shutting down the master. I I tested this in
9.2.x and later versions. This
On Wed, May 11, 2016 at 4:35 PM wrote:
> I apologise for the missing data.
>
> we are running 9.1.15 on debian servers.
>
>
I think there was a patch in v9.3 which makes sure that if the master has
been shutdown properly (smart or fast mode), it will ensure that pending
wals are replicated before
I apologise for the missing data.
we are running 9.1.15 on debian servers.
when we promote the old slave, it seems to go fine. Are you saying that it will
cause issues down the line if the previous master is not shut down before
promoting?
I was actually more concerned with the fact that we (s
On Wed, May 11, 2016 at 2:31 PM, wrote:
> Hi All,
>
> we are currently using streaming replication on multiple node pairs. We
> are seeing some issues, but I am mainly interrested in clarification.
>
> When a failover occurs, we touch the trigger file, promoting the previous
> slave to master. Th
On Tue, May 3, 2016 at 8:23 AM, Tony Nelson wrote:
> I have a nicely working 3 server, 1 master, 2 slave setup. All servers are
> running on Ubuntu 12.04. I was considering building a new slave server on
> 16.04.
>
> The master is currently running 9.1.13, the slave I'm going to replace is
>
Hi
2016-03-09 18:14 GMT+01:00 Ivan Voras :
> Hello,
>
> Is it possible (or will it be possible) to issue CREATE TEMP TABLE
> statements on the read-only slave nodes in master-slave streaming
> replication in recent version of PostgreSQL (9.4+)?
>
Currently it is not possible. There are two plans
Hi Michael ,
Thank you for your information!!
I understand.
I'll consider to upgrade to 9.4.5.
I'm grateful for all your support.
Yoji
--
View this message in context:
http://postgresql.nabble.com/Streaming-replication-stacked-tp5880104p5880550.html
Sent from the PostgreSQL - general
On Wed, Jan 6, 2016 at 9:27 AM, Yoji wrote:
> Hi Andreas and Michael,
>
> Thank you for your information!
>
> Let me know, which should I choose update to 9.4.5
Updating to 9.4.5 is highly recommended, and a separate issue.
> or hot_standby_feedback off?
Switching hot_standby_feedback to off de
Hi Andreas and Michael,
Thank you for your information!
Let me know, which should I choose update to 9.4.5 or hot_standby_feedback
off?
Best regards.
Yoji
--
View this message in context:
http://postgresql.nabble.com/Streaming-replication-stacked-tp5880104p5880487.html
Sent from the Postg
Michael Paquier wrote:
> As Andreas has already outlined, as hot_standby_feedback is enabled
> the master has to wait for the slave and the slave cannot replay from
> the master as transactions are running on the hot standby.
Oh, thanks for the confirmation ;-) (wasn't really sure)
Andreas
--
On Tue, Jan 5, 2016 at 5:13 PM, Yoji wrote:
> I'm using version of 9.4.3.
You should update to 9.4.5 as soon as possible.
> And I have seen same behavior on version of 9.3.4.
As Andreas has already outlined, as hot_standby_feedback is enabled
the master has to wait for the slave and the slave
Andreas Kretschmer wrote:
> ok, i think it's clear now: because of running transactions on the
> standby (and hot_standby_feedback on) the master has to wait for the
> slave and can't replay all from the master.
Mhh. Maybe i'm wrong, can't reproduce that.
Andreas
--
Really, I'm not out to des
Yoji wrote:
> Hi, Andreas
>
> Thank you for replying.
>
> You're right, I have only 1 slave.
>
> And I need running transactions on slave.
> Once I restarted postgres service on slave and then process began to move.
ok, i think it's clear now: because of running transactions on the
standby (
Hi Michael,
Thank you for replying.
I'm using version of 9.4.3.
And I have seen same behavior on version of 9.3.4.
Best regards.
Yoji
--
View this message in context:
http://postgresql.nabble.com/Streaming-replication-stacked-tp5880104p5880329.html
Sent from the PostgreSQL - general mai
Hi, Andreas
Thank you for replying.
You're right, I have only 1 slave.
And I need running transactions on slave.
Once I restarted postgres service on slave and then process began to move.
Best regards.
Yoji
--
View this message in context:
http://postgresql.nabble.com/Streaming-replicatio
On Mon, Jan 4, 2016 at 9:08 PM, wrote:
> And There is System Version.
> -
> - PostgreSQL Version : 9.4
> - OS : CentOS6.4
> - Replicaion Type: async
> -
You are using a version of 9.4 older than 9
Yoji wrote:
> Hi, Andreas
>
> Thank you for reply.
>
> Below is the recovery.conf.
>
> --
> standby_mode = on
> primary_conninfo = 'host=172.16.xxx.xxx user=xx'
> trigger_file = '/tmp/trigger_file0'
>
Hi Chiru ,
Thank you for your information.
I send wals to standby server using "wal sender" processes.
And I had checked logs but It was nothing.
Best regards.
Yoji
--
View this message in context:
http://postgresql.nabble.com/Streaming-replication-stacked-tp5880104p5880288.html
Sent
Hi, Andreas
Thank you for reply.
Below is the recovery.conf.
--
standby_mode = on
primary_conninfo = 'host=172.16.xxx.xxx user=xx'
trigger_file = '/tmp/trigger_file0'
--
Best regards.
Yoji
--
View t
Hi Yoji,
Please check is there any network issues ,between master and slave server
and also share the slave server pg log output.
-Are you shipping wals to standby server using any script other than
archive_command which is mentioned master config?.
On Mon, Jan 4, 2016 at 5:58 PM, Andreas Kret
y-tsuk...@xseed.co.jp wrote:
> -
>
> Do you have any solution?
please show us your recovery.conf.
Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvald
On Fri, May 8, 2015 at 2:29 PM James Sewell
wrote:
> Hello All,
>
> I am running 9.4 on Centos.
>
> I have three servers, one master and two slaves. The slaves have the
> following recovery.conf
>
> standby_mode = 'on'
> primary_conninfo = 'user=postgres host=mastervip port=5432'
> restore_comman
OK I think I have a solution, using the following script as the
restore_command
echo $1 | grep history > /dev/null
if [ $? -eq 0 ]; then
exit 1
fi
scp postgres@postgres3:/archived_wals/$1 $2
This seems to work, as it restricts slave servers from switching timeline
from the archive by
Hey,
This is an example of what I see when starting up a replica and attaching
it to a master.
In this case the master is in timeline 3, but the archive log goes up to
timeline 6.
2015-05-08 16:23:07 AEST @ ( 0 0)LOG: database system was interrupted;
last known up at 2015-05-08 16:21:14 AES
Hi
2015-03-06 7:23 GMT+01:00 Alan Nilsson :
> Is it possible to use streaming replication across different platforms
> (OSX/linux)?
>
No, it is not possible - you have to use logical replication like Slony
Regards
Pavel Stehule
>
> As I read it, you must use a file system level base backup t
On 01/04/2015 06:54 PM, Jayadevan M wrote:
On Sun, Jan 4, 2015 at 8:01 PM, Adrian Klaver mailto:adrian.kla...@aklaver.com>> wrote:
That was indeed the case. I had copied/pasted the code in Microsoft Word
and then copied/pasted from Word to recovery.conf. Word intelligently
(?) changed the 'q
On Sun, Jan 4, 2015 at 8:01 PM, Adrian Klaver
wrote:
> On 01/04/2015 06:09 AM, Jayadevan M wrote:
>
>> Hi,
>> I have streaming replication set up, with PostgreSQL 9.3. The entries in
>> recovery.conf on the slave are as follows -
>> standby_mode = 'on'
>> primary_conninfo = 'host=127.0.0.1 port=2
Jayadevan M wrote:
>
> Replication is working fine. The trigger file does get created by the failover
> script when I shut down the primary. But I just keep getting these entries in
> the log file in the slave and it does not get promoted.
> FATAL: could not connect to the primary server: could
On 01/04/2015 06:09 AM, Jayadevan M wrote:
Hi,
I have streaming replication set up, with PostgreSQL 9.3. The entries in
recovery.conf on the slave are as follows -
standby_mode = 'on'
primary_conninfo = 'host=127.0.0.1 port=2345 user=postgres
password=password'
restore_command = 'cp /pgdata/archi
On 12/9/2014 9:07 AM, Dara Unglaube wrote:
Is this neccessary? What is the benefit of having the archive on?
Could I map a network drive from the slave to the master and set the
archive_command to that mapped drive? Or what would be the best
approach for this?
having a wal archive lets the s
Thank so very for the info, John! This will help a lot to have it set up
locally.
I have it set up across the local network and double checked with
pg_stat_replication and it was using the local IP. But now I am not sure
about the "archive_command" command on the master. We had it set up to
archiv
On 12/8/2014 11:56 AM, Dara Unglaube wrote:
We have streaming replication set up on two servers that are on our
local network using their external/public IP addresses. We are
switching internet providers and need to change the external/public IP
addresses of both servers. I'm not sure how to go
*postgresql.conf:*
wal_level = hot_standby
hot_standby = on
archive_mode = on
archive_command = 'cp %p ../archive/%f'
## "archive" parallel to data directory
max_wal_senders = 10
## number of slaves
*recovery.conf(in slave)*
restore_command = 'cp ../archive/%f "%p"'
standby_mode = 'on'
primary_c
> Anupama Ramaswamy wrote:
>>> I would like to setup a 2 servers with streaming replication, one master
>>> and another hot standby.
>>> I want to use the standby for read-only queries. So I want the replication
>>> lag to be as small as
>>> possible.
>>> So I choose streaming replication over WA
Thanks for your response.
So are you saying that if I setup the following in my recovery.conf
restore_command =.
It will it be used only when the streaming replication falls behind more than (
wal_keep_segments ) or replication stream is not available (master goes down) ?
Thanks for your he
Thanks so much. That clarifies.
-Anupama
On Monday, April 14, 2014 12:09 PM, Michael Paquier
wrote:
On Sat, Apr 12, 2014 at 3:12 PM, Anupama Ramaswamy wrote:
> Lets suppose at this point there is 0 delivery lag but bytes of replay
> lag.
>
All your answers are here:
http://www.postgresql
Anupama Ramaswamy wrote:
> I would like to setup a 2 servers with streaming replication, one master and
> another hot standby.
> I want to use the standby for read-only queries. So I want the replication
> lag to be as small as
> possible.
> So I choose streaming replication over WAL shipping.
>
On Sat, Apr 12, 2014 at 3:12 PM, Anupama Ramaswamy wrote:
> Lets suppose at this point there is 0 delivery lag but bytes of replay
> lag.
>
All your answers are here:
http://www.postgresql.org/docs/devel/static/warm-standby.html
"Standby mode is exited and the server switches to normal operat
Thanks for your response.
>>There are two lag types to consider about in case of a normal
>>streaming replication - delivery lag and replay lag. The secondary
>>will completely catch up to what have been delivered, but what have
>>not been is going to be lost. See [1][2].
Ok, I understand. I want
On Sat, Apr 5, 2014 at 3:48 AM, Anupama Ramaswamy wrote:
> Scenario 1
>
> Suppose the secondary server is lagging behind the primary at the time of
> primary failure, will the secondary completely catch up to the primary
> state, before stopping replication. Or what in the process
Thanks for the information and the URLs!
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Streaming-Replication-Error-on-Standby-tp5791463p5791588.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general mailing list (pgsql
On 02/11/2014 10:12 AM, bobJobS wrote:
Postgres 9.3.2.
RHEL 5
After performing all of the Streaming Replication setup steps, I get the
following error message in my standby DB log file.
database system identifier differ between the primary and standby
I've double checked the recovery.conf f
On 02/11/2014 10:12 AM, bobJobS wrote:
Postgres 9.3.2.
RHEL 5
After performing all of the Streaming Replication setup steps, I get the
following error message in my standby DB log file.
database system identifier differ between the primary and standby
I've double checked the recovery.conf f
On Tue, Feb 11, 2014 at 11:25 AM, bobJobS wrote:
>
> To get the standby server to a point, I tool a globals dump and a data dump
> of the primary server and build the standby.
>
> Then I executed pg_startbackup, rsync data dir to standby data dir (to
> catch
> any changes made while I was buildin
To get the standby server to a point, I tool a globals dump and a data dump
of the primary server and build the standby.
Then I executed pg_startbackup, rsync data dir to standby data dir (to catch
any changes made while I was building the standby) and finally
pg_stopbackup... all on the primary
On Tue, Feb 11, 2014 at 10:12 AM, bobJobS wrote:
> Postgres 9.3.2.
> RHEL 5
>
> After performing all of the Streaming Replication setup steps,
>
What replication steps?
> database system identifier differ between the primary and standby
>
How did you take the initial backup of the master? D
On Mon, 25 Nov 2013, Tree wrote:
TLDR: We want to be able to use streaming replication, WAL archiving, and
have the ability to restore from a backup made before a failover using the
WAL archive.
(cutting rest of long description)
So, is it possible to use a "long-term WAL archive area" (as t
On Tue, Sep 10, 2013, Mahlon E. Smith wrote:
> On Mon, Sep 09, 2013, Jeff Davis wrote:
> >
> > You may have seen only partial information about that bug and the fix.
>
> Yep, I totally glazed over the REINDEX. Giving it a go -- thank you!
As a followup for anyone else landing on this thread, th
Anson Abraham wrote:
> No client connecting to the slave. It's just streamed replication for HA.
> This occurs when the slave
> starts immediately. SSL is used. And as I mentioned the libraries are
> identical on both slave and
> master. Interestingly, another slave that replicates from mast
1 - 100 of 289 matches
Mail list logo
