On Tue, May 5, 2015 at 7:57 AM, Edson F. Lidorio
wrote:
>
>
> On 04-05-2015 00:46, Venkata Balaji N wrote:
>
>> You do not see the above WAL file in the archive directory ?
>> "/mnt/server/archivedir" is shared between master and slave databases ? The
>> file may have been removed from the archiv
On 05/05/2015 11:21 AM, Melvin Davidson wrote:
Have you allowed access to user "replication" in the master pg_hba.conf
and done a
SELECT pg_reload_conf()?
Can you ping the master from the standby?
Did you RTFM?
http://www.postgresql.org/docs/9.2/interactive/warm-standby.html
25.2.3 Preparing t
Have you allowed access to user "replication" in the master pg_hba.conf and
done a
SELECT pg_reload_conf()?
Can you ping the master from the standby?
Did you RTFM?
http://www.postgresql.org/docs/9.2/interactive/warm-standby.html
25.2.3 Preparing the Master for Standby Servers
25.2.4 Setting Up a
Em 2015-05-05 14:31, Adrian Klaver escreveu:
> On 05/05/2015 08:35 AM, Edson F. Lidorio wrote:
> On 05-05-2015 11:22, Melvin Davidson wrote: It's possible you have
> wal_keep_segments set too low. What happens is that the master will keep the
> wals ( in your case 20) after processing them,
On 05/05/2015 08:35 AM, Edson F. Lidorio wrote:
On 05-05-2015 11:22, Melvin Davidson wrote:
It's possible you have wal_keep_segments set too low. What happens is
that the master will keep the wals ( in your case 20) after processing
them, before sending them off to the great black hole in the ne
Em 2015-05-05 13:05, Melvin Davidson escreveu:
> Did you change the setting on the master? Did you remember to reload the
> config on the master after changing?
> Did you rebuild the Standby server after making the change and reloading? IE:
> psql -U postgres SELECT pg_reload_conf();
>
> Y
Did you change the setting on the master?
Did you remember to reload the config on the master after changing?
Did you rebuild the Standby server after making the change and reloading?
IE:
psql -U postgres
SELECT pg_reload_conf();
You must do ALL of the above to have any chance of making things wo
On 05-05-2015 11:22, Melvin Davidson wrote:
It's possible you have wal_keep_segments set too low. What happens is
that the master will keep the wals ( in your case 20) after processing
them, before sending them off to the great black hole in the network
(deleting) and making them unavailable to
On 05/05/2015 07:23 AM, Edson F. Lidorio wrote:
Please keep this on the list, for two reasons:
1) More eyes looking is better.
2) I will be off line shortly.
Em 2015-05-05 11:09, Adrian Klaver escreveu:
On 05/05/2015 07:05 AM, Edson F. Lidorio wrote:
CCing list.
Em 2015-05-05 10:45, Adria
It's possible you have wal_keep_segments set too low. What happens is that
the master will keep the wals ( in your case 20) after processing them,
before sending them off to the great black hole in the network (deleting)
and making them unavailable to the standby. Try increasing
wal_keep_segments =
On 05/05/2015 07:05 AM, Edson F. Lidorio wrote:
CCing list.
Em 2015-05-05 10:45, Adrian Klaver escreveu:
On 05/03/2015 05:57 PM, Edson F. Lidorio wrote:
Hello, I'm having trouble on Standby after the implementation of the
restore_command. I performed all the settings and it worked normally
a
On 05/03/2015 05:57 PM, Edson F. Lidorio wrote:
Hello,
I'm having trouble on Standby after the implementation of the
restore_command.
I performed all the settings and it worked normally and after restart
the slave server, started to generate errors in the log of the slave:
So is that implying
Hello,
I'm having trouble on Standby after the implementation of the
restore_command.
I performed all the settings and it worked normally and after restart
the slave server, started to generate errors in the log of the slave:
I'm using Debian 8 with PostgreSQL 9.4.1 on x86_64-unknown-linux-gn
13 matches
Mail list logo
