[pgpool-general: 3876] Re: issue with master-slave streaming replication

[Piotr Synak]

Hi

Thanks for the answer.

> Yes. Because PostgreSQL streaming replication does not care about
> replication delay. pgpool-II needs to care about entire cluster, not
> only the replication master. Even without pgpool-II, you need to think
> about the replication delay problem if your app wants to connect to
> standby right after DDL is executed.

Hmm, that would be true for synchronous replication but streaming replication in PG is asynchronous by default. If I assume that I want to connect to standby right after DDL is executed on primary I would choose synchronous option. Actually, in my setup as I don't use load balancer I connect to primary only and standby is solely for HA purpose. 

> Maybe we could mitigate the problem by adding a switch to wait for
> standby catches up master but this will require non trivial
> development.

That would be very helpful. I believe that even if we assume that CREATE DATABASE (or anything) should wait for standby to be synchronized then it should be handled internally, i.e., the operation should not finish until all gets synchronized.

Thanks,
Piotr

-----Original Message-----
From: Tatsuo Ishii [mailto:ishii at postgresql.org] 
Sent: Friday, July 17, 2015 2:51 AM
To: Piotr Synak
Cc: pgpool-general at pgpool.net
Subject: Re: [pgpool-general: 3874] issue with master-slave streaming replication

> Hi,
> 
> I have a simple pgpool configuration with two nodes, each hosting pgpool and backend. It is master-slave configuration with watchdog and postgres streaming replication. No load balancing.
> I am doing simple test in a script:
> 
> drop database test;
> create database test;
> \c test;
> 
> When running above script directly on PG backend it works fine.
> 
> When running it against pgpool via delegate ip I get an error when connecting to database "test":
> DROP DATABASE
> CREATE DATABASE
> psql:./test.sql:3: \connect: ERROR:  unable to read message kind
> DETAIL:  kind does not match between master(53) slot[1] (45)
> 
> I noticed that when I introduce some delay between "Create database" and "Connect" then it works fine. So it looks like pgpool is waiting for replication to finish or some kind of confirmation from standby node (or anything else?). This is for me contradictory with the idea of asynchronous replication (and such is streaming replication) where we don't wait for any confirmation but execute immediately. Fact that it runs well when executed directly by backend proves that the issue is not in the streaming replication but in pgpool. How to overcome this problem? Is it known issue?

Yes. Because PostgreSQL streaming replication does not care about
replication delay. pgpool-II needs to care about entire cluster, not
only the replication master. Even without pgpool-II, you need to think
about the replication delay problem if your app wants to connect to
standby right after DDL is executed.

> Adding "sleep" after each dml is not a solution for me.

Maybe we could mitigate the problem by adding a switch to wait for
standby catches up master but this will require non trivial
development.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp