Message-ID: <54F81306.9060404@BlueTreble.com>
Date: Thu, 5 Mar 2015 02:25:42 -0600
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Sergey Shchukin <shchukin.s.a@gmail.com>, Radovan Jablonovsky
 <radovan.jablonovsky@replicon.com>, <pgsql-general@postgresql.org>
Subject: Re: Re: [pgadmin-support] Issue with a hanging apply process
 on the replica db after vacuum works on primary
References: <54EC7FAE.8050003@gmail.com>
 <CAJYcdTtmk4bB9eXfEK_YSrqmXMmssJ3NVwTPXNw2UVrtCScoew@mail.gmail.com>
 <54EEBC5B.5000402@gmail.com> <54F03052.6050900@BlueTreble.com>
 <54F050D2.7030406@gmail.com>
In-Reply-To: <54F050D2.7030406@gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2015 08:25:52.6904 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR11MB0344
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-general>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-general.postgresql.org>
List-Owner: <mailto:pgsql-general-owner@postgresql.org>
List-Post: <mailto:pgsql-general@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-general>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-general>
X-Mailing-List: pgsql-general
Precedence: bulk
Sender: pgsql-general-owner@postgresql.org

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


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general