Обсуждение: PostgreSQL 9.3 synchronous replication
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
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
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
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
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
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
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
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
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. +