>-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
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 00DF004C, offset 12148736
I believe this means the standby server receiv
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
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,
--
Leonardo M. Ramé
Medical IT - Griensu S.A.
Av. Colón 636 - Piso 8 Of. A
X5000EPT -- Córdoba
Tel.: +54(351)4246924 +54(351
Thank you.
Maybe it would help, but recently I had another issue with the tables
having large arrays. I likely will redesign that part of the application,
and I’ll see if it helps as a side effect.
On Thu, Jun 22, 2017 at 5:55 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> O
On 6/21/17 22:04, Maeldron T. wrote:
> * Logical replication is in 10.0 Beta 1. I might be oldschool but I
> would install 10.1 or maybe 10.0.2 into production
There are also other logical replication options such as pglogical and
londiste.
--
Peter Eisentraut http://www.2ndQuadrant
On Tue, Jun 20, 2017 at 3:06 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> 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.
>
I could do a lot. For example, if I
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
Hello,
tl;dr
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 huge amount of emails).
Is ther
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
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 ?
It's not occurs on primary or standalone servers, just on replication.
T
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
or just a reload will do it?
Thanks!
Gabriel
-- Forwarded message --
From: Achilleas Mantzios
Date: 2017-02-17 11:20 GMT-02:00
Subject: Re: [GENERAL] Streaming Replication Without Downtime
To: pgsql-general@postgresql.org
Gabriel you are thinking this in the correct way, but its
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
Hi all,
I've been searching for a way to initialize a new Hot Standby node with
Streaming Replication withou the need for stop or even restarting the
master.
Of course the master is already with the needed SR configs.
I know I have to use pg_start_backup/pg_stop_backup, but i'd like some
tip
Hello,
I'm trying to write a program that speaks the streaming replication
protocol (for logical decoding). I get to the part where I issue a query:
START_REPLICATION SLOT regression_slot LOGICAL 0/0;
And after that, I receive an empty copy_both_response then a copy_data that
has a "Primary kee
-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
Hi,
is there a perl module that allows to speak the streaming replication
protocol? Can DBD::Pg do that anyhow?
I think I could just pipe from pg_recvlogical. But would be cool to have it
directly in Perl.
Thanks,
Torsten
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
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)*
slave03 (Streaming Replication from slave02
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
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 slots.- Shut down master on A- Promote slave on B to
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
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 .
Let's suppose that the standby stays down for a long time, then it
restarts,
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.
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 be able to communicate each other. Not by
st
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
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. That works perfectly.
For recycling the previous mast
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
>
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
running 9.1.20.
Does the new slave have to be running 9.1? Or
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
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+)?
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
Hi All,
I use streaming replication on systems.
But I have an problem.
I need your support.
The system sometimes stacks Postgres process.
So, postgresql data isn't syncing.
I checkd process that it was stacked "waiting" status on slave server.
e.g.) postgres: startup process recovering 00
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
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_command = 'scp -o BatchMode=yes postgres@backuphost:/archived_wals/%f
%p'
re
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
Is it possible to use streaming replication across different platforms
(OSX/linux)?
As I read it, you must use a file system level base backup to setup the slave.
I ran into problems trying pg_basebackup and, as was pointed out, that is not
supported. So will a tarball or any other file syste
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
1 - 100 of 372 matches
Mail list logo
