Re: PostgreSQL 9.3 synchronous replication

Поиск
Список
Период
Сортировка
От Sergey Arlashin
Тема Re: PostgreSQL 9.3 synchronous replication
Дата
Msg-id 4D515075-C030-4E13-80E8-42C3F6A7FC80@gmail.com
обсуждение исходный текст
Ответ на Re: PostgreSQL 9.3 synchronous replication  (Matheus de Oliveira <matioli.matheus@gmail.com>)
Ответы Re: PostgreSQL 9.3 synchronous replication  (Matheus de Oliveira <matioli.matheus@gmail.com>)
Список pgsql-admin

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


В списке pgsql-admin по дате отправления:

Предыдущее
От: Sergey Arlashin
Дата:
Сообщение: Re: PostgreSQL 9.3 synchronous replication
Следующее
От: Craig James
Дата:
Сообщение: pg_basebackup bug: base backup is double the size of the database