Thread: PostgreSQL 9.3 synchronous replication

PostgreSQL 9.3 synchronous replication

From
Sergey Arlashin
Date:
Hi!

Recently I've found out that synchronous replication just guarantees that the commit has reached the transaction log on
theslave. Therefore that doesn't mean the slave has replayed the transaction log and a query against the slave will
showthe transaction's results. 

So I'm wondering if there is a way to ensure that once a transaction is committed the data is available on the slave
andI can get it by executing a query against the slave? 

--
Best regards,
Sergey Arlashin

Re: PostgreSQL 9.3 synchronous replication

From
Vladimir Borodin
Date:

21 янв. 2015 г., в 11:25, Sergey Arlashin <sergeyarl.maillist@gmail.com> написал(а):

Hi!

Recently I've found out that synchronous replication just guarantees that the commit has reached the transaction log on the slave. Therefore that doesn't mean the slave has replayed the transaction log and a query against the slave will show the transaction's results.

So I'm wondering if there is a way to ensure that once a transaction is committed the data is available on the slave and I can get it by executing a query against the slave?

You should set synchronous_commit = on (seems, that right now you have remote_write). See http://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT for more details.


--
Best regards,
Sergey Arlashin

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


--
May the force be with you...




Re: PostgreSQL 9.3 synchronous replication

From
Matheus de Oliveira
Date:

On Wed, Jan 21, 2015 at 6:25 AM, Sergey Arlashin <sergeyarl.maillist@gmail.com> wrote:
Recently I've found out that synchronous replication just guarantees that the commit has reached the transaction log on the slave. Therefore that doesn't mean the slave has replayed the transaction log and a query against the slave will show the transaction's results.


The exact guarantee depends on synchronous_commit configuration, but none provides guarantee that the xlog records have been applied and ready to query, you are right about it.

 
So I'm wondering if there is a way to ensure that once a transaction is committed the data is available on the slave and I can get it by executing a query against the slave?

Well, you can use compare the values of pg_current_xlog_location on the master immediately after commit and pg_last_xlog_replay_location on the slave (or even use pg_stat_replication.replay_location).

Regards,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres

Re: PostgreSQL 9.3 synchronous replication

From
Sergey Arlashin
Date:

On Jan 21, 2015, at 3:19 PM, Vladimir Borodin <root@simply.name> wrote:


21 янв. 2015 г., в 11:25, Sergey Arlashin <sergeyarl.maillist@gmail.com> написал(а):

Hi!

Recently I've found out that synchronous replication just guarantees that the commit has reached the transaction log on the slave. Therefore that doesn't mean the slave has replayed the transaction log and a query against the slave will show the transaction's results.

So I'm wondering if there is a way to ensure that once a transaction is committed the data is available on the slave and I can get it by executing a query against the slave?

You should set synchronous_commit = on (seems, that right now you have remote_write). See http://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT for more details.

Actualy I have 'synchronous_commit = on' in my postgresql.conf:

postgres=# show synchronous_commit ;
 synchronous_commit
--------------------
 on
(1 row)

--
Best regards,
Sergey Arlashin

Re: PostgreSQL 9.3 synchronous replication

From
Sergey Arlashin
Date:

On Jan 21, 2015, at 3:34 PM, Matheus de Oliveira <matioli.matheus@gmail.com> wrote:


On Wed, Jan 21, 2015 at 6:25 AM, Sergey Arlashin <sergeyarl.maillist@gmail.com> wrote:
Recently I've found out that synchronous replication just guarantees that the commit has reached the transaction log on the slave. Therefore that doesn't mean the slave has replayed the transaction log and a query against the slave will show the transaction's results.


The exact guarantee depends on synchronous_commit configuration, but none provides guarantee that the xlog records have been applied and ready to query, you are right about it.

 
So I'm wondering if there is a way to ensure that once a transaction is committed the data is available on the slave and I can get it by executing a query against the slave?

Well, you can use compare the values of pg_current_xlog_location on the master immediately after commit and pg_last_xlog_replay_location on the slave (or even use pg_stat_replication.replay_location).


Yes, I understand this. But I was wondering whether it is possible to somehow force this procedure. Or wait until xlog is applied on slave and  only then consider the transaction committed. 
Or at least improve the ability of slave to apply xlogs? 

--
Best regards,
Sergey Arlashin


Regards,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres


Re: PostgreSQL 9.3 synchronous replication

From
Matheus de Oliveira
Date:

On Wed, Jan 21, 2015 at 1:21 PM, Sergey Arlashin <sergeyarl.maillist@gmail.com> wrote:
Yes, I understand this. But I was wondering whether it is possible to somehow force this procedure. Or wait until xlog is applied on slave and  only then consider the transaction committed. 

You'd have to do it somehow in your application. AFAICT, PostgreSQL does not provide any way to that in current versions (might be done in future releases).

Regards,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres

Re: PostgreSQL 9.3 synchronous replication

From
Bruce Momjian
Date:
On Wed, Jan 21, 2015 at 04:21:26PM -0200, Matheus de Oliveira wrote:
>
> On Wed, Jan 21, 2015 at 1:21 PM, Sergey Arlashin <sergeyarl.maillist@gmail.com>
> wrote:
>
>     Yes, I understand this. But I was wondering whether it is possible to
>     somehow force this procedure. Or wait until xlog is applied on slave and
>      only then consider the transaction committed. 
>
>
> You'd have to do it somehow in your application. AFAICT, PostgreSQL does not
> provide any way to that in current versions (might be done in future releases).

The problem with forcing the WAL to be replayed is that it might cause
many existing transactions to be canceled due to their snapshots
becoming invalid.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +