On 5/29/19 10:39 AM, Mariel Cherkassky wrote:
> Is there any messages that indicates that the secondary replayed a
> specific wal ? "restored 0..." means that the restore_command
> succeeded but there isnt any proof that it replayed the wal.
I believe that the message "restored log file..'
In my case, I'm talking about creating a standby -> standby clone and then
recover the wals . How can I run checkpoint in the secondary if it isnt up ?
בתאריך יום ד׳, 29 במאי 2019 ב-13:54 מאת Nikolay Samokhvalov <
samokhva...@gmail.com>:
> Hello Mariel,
>
> 1) Have you tried to run “CHECK
Hello Mariel,
1) Have you tried to run “CHECKPOINT;” on the standby to perform
restartpoint explicitly? It is possible.
2) If we talk about streaming replication, do you use replication slots? If
so, have you checked pg_replication_slots and pg_stat_replication? They can
help to troubleshoot stre
Is there any messages that indicates that the secondary replayed a specific
wal ? "restored 0..." means that the restore_command succeeded but
there isnt any proof that it replayed the wal.
My theory regarding the issue :
It seems, that my customer stopped the db 20 minutes after the clone ha
On 5/29/19 9:20 AM, Mariel Cherkassky wrote:
> First of all thanks Fabio.
> I think that I'm missing something :
> In the next questionI'm not talking about streaming replication,rather
> on recovery :
>
> 1.When the secondary get the wals from the primary it tries to replay
> them correct ?
First of all thanks Fabio.
I think that I'm missing something :
In the next questionI'm not talking about streaming replication,rather on
recovery :
1.When the secondary get the wals from the primary it tries to replay them
correct ?
2. By replaying it just go over the wal records and run them in
Hi Mariel,
please keep the list posted. When you reply, use 'reply all'. That will maybe
help others in the community and you might also get more help from others.
answers are in line here below
On 28/05/2019 10:54, Mariel Cherkassky wrote:
> I have pg 9.6, repmgr version 4.3 .
> I see in the
If you did not even see this messages on your standby logs:
restartpoint starting: xlog
then it means that the checkpoint was even never started.
In that case, I have no clue.
Try to describe step by step how to reproduce the problem together with
your setup and the version number of Postgres a
standby_mode = 'on'
primary_conninfo = 'host=X.X.X.X user=repmgr connect_timeout=10 '
recovery_target_timeline = 'latest'
primary_slot_name = repmgr_slot_1
restore_command = 'rsync -avzhe ssh postgres@x.x.x.x:/var/lib/pgsql/archive/%f
/var/lib/pgsql/archive/%f ; gunzip < /var/lib/pgsql/archive/%f
Hi Mariel,
let s keep the list in cc...
settings look ok.
what's in the recovery.conf file then?
regards,
fabio pardi
On 5/27/19 11:23 AM, Mariel Cherkassky wrote:
> Hey,
> the configuration is the same as in the primary :
> max_wal_size = 2GB
> min_wal_size = 1GB
> wal_buffers = 16MB
> chec
Hi Mariel,
if i m not wrong, on the secondary you will see the messages you
mentioned when a checkpoint happens.
What are checkpoint_timeout and max_wal_size on your standby?
Did you ever see this on your standby log?
"consistent recovery state reached at .."
Maybe you can post your whole con
Hey,
PG 9.6, I have a standalone configured. I tried to start up a secondary,
run standby clone (repmgr). The clone process took 3 hours and during that
time wals were generated(mostly because of the checkpoint_timeout). As a
result of that, when I start the secondary ,I see that the secondary keep
12 matches
Mail list logo
