Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fo7Ss-0005Uh-Lk for pgsql-admin@arkaria.postgresql.org; Fri, 10 Aug 2018 13:28:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fo7Sq-00023t-DF for pgsql-admin@arkaria.postgresql.org; Fri, 10 Aug 2018 13:28:24 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fo7Sq-00023m-23 for pgsql-admin@lists.postgresql.org; Fri, 10 Aug 2018 13:28:24 +0000 Received: from hermes.gatewaynet.com ([193.92.121.98]) by makus.postgresql.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fo7Sl-0008GO-Ov for pgsql-admin@lists.postgresql.org; Fri, 10 Aug 2018 13:28:22 +0000 Received: from smadev.internal.net (pc131.internal.net [10.9.200.131]) by hermes.gatewaynet.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id w7ADSBCD025484 for ; Fri, 10 Aug 2018 16:28:16 +0300 Received: from smadev.internal.net (smadev [10.9.200.131]) by smadev.internal.net (8.15.2/8.15.2) with ESMTP id w7ADSAnP033380 for ; Fri, 10 Aug 2018 16:28:10 +0300 (EEST) (envelope-from achill@matrix.gatewaynet.com) Subject: Re: Logical replication monitoring To: pgsql-admin@lists.postgresql.org References: From: Achilleas Mantzios Message-ID: <9d702bb3-9988-dd09-e0fb-f75858665f8b@matrix.gatewaynet.com> Date: Fri, 10 Aug 2018 16:28:10 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CB2889CC11A4F26EB148BC61" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.98.7 at hermes X-Virus-Status: Clean X-Spam-Status: No, score=-27.0 required=5.0 tests=ALL_TRUSTED,DYN_HAM_COORD, DYN_HAM_IT,DYN_HAM_NAUTICAL,DYN_HAM_SIGNAT1,HTML_MESSAGE autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hermes.gatewaynet.com List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------CB2889CC11A4F26EB148BC61 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 10/08/2018 13:05, AYahorau@ibagroup.eu wrote: > Hello PostgreSQL Community! > > I configured logical replication for PostgreSQL 10.4 on 2 machines, set wal_level to logical, created a publication on master node and created a subscription on standby node according to the > PostgreSQL documentation. > Could you please suggest an approach for replication state monitoring. > > According to my experience the monitoring of *pg_stat_subscription *and *pg_publication, pg_replication_slots *unfortunately is not enough for this aim. Moreover standby database does not prohibit > write operations by default and it can lead to some inconsistency between these databases. > > For example a chain of queries as > *SELECT pg_is_is_recovery()*, > *SELECT * FROM pg_stat_replication* and > *SELECT * FROM pg_stat_wal_receiver* > provide insight into replication state for hot_standby replication. > > So is there a reliable way of replication state monitoring for logical replication? tail_n_mail and look for relevant errors (logical, logical replication worker ... exited with ..., ERROR) > > > Best regards, > Andrei Yahorau -- Achilleas Mantzios IT DEV Lead IT DEPT Dynacom Tankers Mgmt --------------CB2889CC11A4F26EB148BC61 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 10/08/2018 13:05, AYahorau@ibagroup.eu wrote:
Hello PostgreSQL Community!

I configured logical replication for PostgreSQL 10.4 on 2 machines, set wal_level to logical, created a publication on master node and created a subscription on standby node according to the PostgreSQL documentation.
Could you please suggest an approach for replication state monitoring.

According to my experience the monitoring of pg_stat_subscription and pg_publication, pg_replication_slots unfortunately is not enough for this aim. Moreover standby database does not prohibit write operations by default and it can lead to some inconsistency between these databases.

For example a chain of queries as
SELECT pg_is_is_recovery(),
SELECT * FROM pg_stat_replication and
SELECT * FROM pg_stat_wal_receiver
provide insight into replication state for hot_standby replication.

So is there a reliable way of replication state monitoring for logical replication?
tail_n_mail and look for relevant errors (logical, logical replication worker ... exited with ..., ERROR)


Best regards,
Andrei Yahorau 


-- 
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt
--------------CB2889CC11A4F26EB148BC61--