Re: Re: [pgadmin-support] Issue with a hanging apply process on the replica db after vacuum works on primary
От | Jim Nasby |
---|---|
Тема | Re: Re: [pgadmin-support] Issue with a hanging apply process on the replica db after vacuum works on primary |
Дата | |
Msg-id | 54F81306.9060404@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Re: [pgadmin-support] Issue with a hanging apply process on the replica db after vacuum works on primary (Sergey Shchukin <shchukin.s.a@gmail.com>) |
Ответы |
Re: Re: [pgadmin-support] Issue with a hanging apply process
on the replica db after vacuum works on primary
|
Список | pgsql-general |
On 2/27/15 5:11 AM, Sergey Shchukin wrote: > > show max_standby_streaming_delay; > max_standby_streaming_delay > ----------------------------- > 30s We both need to be more clear about which server we're talking about (master or replica). What are max_standby_streaming_delay and max_standby_archive_delay set to *on the replica*? My hope is that one or both of those is set to somewhere around 8 minutes on the replica. That would explain everything. If that's not the case then I suspect what's happening is there's something running on the replica that isn't checking for interrupts frequently enough. That would also explain it. When replication hangs, is the replication process using a lot of CPU? Or is it just sitting there? What's the process status for the replay process show? Can you get a trace of the replay process on the replica when this is happening to see where it's spending all it's time? How are you generating these log lines? Tue Feb 24 15:05:07 MSK 2015 Stream: MASTER-masterdb:79607161592048 SLAVE:79607161550576 Replay:79607160986064 :: REPLAY 592 KBytes (00:00:00.398376 seconds) Do you see the confl_* fields in pg_stat_database_conflicts on the *replica* increasing? -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-general по дате отправления: