| From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | AYahorau(at)ibagroup(dot)eu |
| Cc: | pgsql-general(at)postgresql(dot)org, rene(dot)romero(dot)b(at)gmail(dot)com |
| Subject: | Re: terminating walsender process due to replication timeout |
| Date: | 2019-05-24 06:34:04 |
| Message-ID: | 20190524.153404.138479543.horiguchi.kyotaro@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Hello.
At Fri, 17 May 2019 11:04:58 +0300, AYahorau(at)ibagroup(dot)eu wrote in <OFE11EC62A(dot)504EB2B3-ON432583FD(dot)002BE231-432583FD(dot)002C666E(at)iba(dot)by>
> Can frequent database operations cause getting a standby server behind? Is
> there a way to avoid this situation?
> I checked that walsender works well in my test if I set
> wal_sender_timeout at least to 5 second.
It depends on the transaction (WAL) traffic and the bandwidth of
your network. The performacne difference between master and
standby also affects.
The possibilities I can guess are:
- The bandwidth is narrow to the traffic.
- The standby performs poorer than the master.
- Your network is having a sort of trouble. Virtual network
(local network in a virtual environment) tends to suffer
network troubles caused by CPU saturation or something else.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julie Nishimura | 2019-05-24 06:57:52 | POSTGRES_FSM_RELATIONS CRITICAL: DB control fsm relations used: 79569 of 80000 (99%) |
| Previous Message | Achilleas Mantzios | 2019-05-24 06:23:50 | Re: terminating walsender process due to replication timeout |