On 3/16/20 2:57 AM, Nicola Contu wrote:
I was able to make pg_basebackup working using --max-rate=128M
Still don't understand why. I guess it is related to the encryption and
slowness of the disk..
Do you have any idea?
I think your explanation fits. Encryption/decryption have overhead.
I
I was able to make pg_basebackup working using --max-rate=128M
Still don't understand why. I guess it is related to the encryption and
slowness of the disk..
Do you have any idea?
Il giorno ven 13 mar 2020 alle ore 16:15 Adrian Klaver <
adrian.kla...@aklaver.com> ha scritto:
> On 3/13/20 4:11 AM
On 3/13/20 4:11 AM, Nicola Contu wrote:
So in the logs I now see this :
2020-03-13 11:03:42 GMT [10.150.20.22(45294)] [27804]: [1-1]
db=[unknown],user=replicator LOG: terminating walsender process due to
replication timeout
Yeah that's been showing up the log snippets you have been posting.
So in the logs I now see this :
2020-03-13 11:03:42 GMT [10.150.20.22(45294)] [27804]: [1-1]
db=[unknown],user=replicator LOG: terminating walsender process due to
replication timeout
So I tried increasing the wal_sender_timeout to 300s but it did not help
Il giorno gio 12 mar 2020 alle ore 15:
The encryption is at os level. So the drives are encrypted with a password
where the db saves data
Il gio 12 mar 2020, 15:51 Adrian Klaver ha
scritto:
> On 3/12/20 4:31 AM, Nicola Contu wrote:
> > The replicator is ok and the replicated as well.
> > %Cpu(s): 0.2 us, 1.0 sy, 0.0 ni, 94.8 id,
On 3/12/20 4:31 AM, Nicola Contu wrote:
The replicator is ok and the replicated as well.
%Cpu(s): 0.2 us, 1.0 sy, 0.0 ni, 94.8 id, 4.0 wa, 0.0 hi, 0.0 si,
0.0 st
CPU is really low on both.
I am running pg_basebackup again everytime.
Any other suggestions?
I have to believe their is
The replicator is ok and the replicated as well.
%Cpu(s): 0.2 us, 1.0 sy, 0.0 ni, 94.8 id, 4.0 wa, 0.0 hi, 0.0 si,
0.0 st
CPU is really low on both.
I am running pg_basebackup again everytime.
Any other suggestions?
Il giorno mer 11 mar 2020 alle ore 23:13 Adrian Klaver <
adrian.kla...@
On 3/11/20 2:12 PM, Nicola Contu wrote:
CPU load on the server to be built? No.
CPU load, I/O load on the servers in the replication chain.
Basically you just recently, it seems, imposed extra overhead to the
process by encrypting/decrypting. From what I gather from earlier post
then your re
CPU load on the server to be built? No.
System logs don't show anything relevant unfortunately
Il mer 11 mar 2020, 21:34 Adrian Klaver ha
scritto:
> On 3/11/20 11:59 AM, Nicola Contu wrote:
> > I am actually cascading.
> > The master is in nyh, the first slave is in Dallas and the one having
> >
On 3/11/20 11:59 AM, Nicola Contu wrote:
I am actually cascading.
The master is in nyh, the first slave is in Dallas and the one having
problems is in Dallas as well on the same switch of the one replicating
from the master.
It always worked not sure what is wrong now. We just encrypted disks
I am actually cascading.
The master is in nyh, the first slave is in Dallas and the one having
problems is in Dallas as well on the same switch of the one replicating
from the master.
It always worked not sure what is wrong now. We just encrypted disks on all
servers
Il mer 11 mar 2020, 18:57 Ad
On 3/11/20 2:54 AM, Nicola Contu wrote:
These are the lines before
2020-03-11 09:05:08 GMT [127.0.0.1(40214)] [43853]: [1-1]
db=cmdv3,user=zabbix_check ERROR: recovery is in progress
2020-03-11 09:05:08 GMT [127.0.0.1(40214)] [43853]: [2-1]
db=cmdv3,user=zabbix_check HINT: WAL control functi
These are the lines before
2020-03-11 09:05:08 GMT [127.0.0.1(40214)] [43853]: [1-1]
db=cmdv3,user=zabbix_check ERROR: recovery is in progress
2020-03-11 09:05:08 GMT [127.0.0.1(40214)] [43853]: [2-1]
db=cmdv3,user=zabbix_check HINT: WAL control functions cannot be executed
during recovery.
2020
On 3/10/20 8:17 AM, Nicola Contu wrote:
Please post to list also.
Ccing list.
What came immediately before the temporary file error?
2020-03-10 15:10:17 GMT [[local]] [28171]: [1-1]
db=postgres,user=postgres LOG: temporary file: path
"base/pgsql_tmp/pgsql_tmp28171.0", size 382474936
2020-0
On 3/10/20 2:26 AM, Nicola Contu wrote:
Hello,
I have two servers connected to the same switch running postgres 11.5
I am trying to replicate one of those servers after a planned work on
the master, so the replica has been lost. It has always worked but now I
get this :
pg_basebackup: could
Hello,
I have two servers connected to the same switch running postgres 11.5
I am trying to replicate one of those servers after a planned work on the
master, so the replica has been lost. It has always worked but now I get
this :
pg_basebackup: could not receive data from WAL stream: server clos
16 matches
Mail list logo
