Re: Transaction-controlled robustness for replication

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Transaction-controlled robustness for replication
Дата
Msg-id 200808121551.m7CFpgR08054@momjian.us
обсуждение исходный текст
Ответ на Transaction-controlled robustness for replication  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Transaction-controlled robustness for replication  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
Simon Riggs wrote:
> We can generalise this as three closed questions, answered either Yes
> (Synchronous) or No (Asynchronous)
> 
> * Does WAL get forced to disk on primary at commit time?
> * Does WAL get forced across link to standby at commit time?
> * Does WAL get forced to disk on standby at commit time?
> 
> In code, these are simple if tests: Do we wait, or not?
> 
> We could represent this with 3 parameters:
> synchronous_commit = on | off
> synchronous_standby_transfer = on | off
> synchronous_standby_wal_fsync = on | off
> 
...
> Or we could use just two parameters:
> synchronous_commit = on | off
> synchronous_replication = 'AA', 'SA' or 'SS'
>   with A = Asynchronous, S = Synchronous 
>   which corresponds with DRBD's algorithms like this
>     DRBD A = AA
>     DRBD B = SA
>     DRBD C = SS
> 
> Or we could use just a single parameter
> synchronous_commit = 'AAA', 'SAA', 'SSA', 'SSS' or on |off when no
> log-based replication is defined

First, I love this kind of control.

Second, I think our current control for the main/master are sufficient
that we don't need to add additional variables for this, so we can focus
just on whether we wait for the slave.

Third, we can control whether the slave WAL fsync's by setting things on
the slave, so I don't think we need a master setting for that.

Fourth, I don't think the boolean idea will work because there are
boolean combinations that are illogical, like having
synchronous_standby_transfer off and synchronous_standby_wal_fsync on.

I think you need to make it an enumerated type like log_min_messages; 
something like:
wal_transfer_wait

with values of:
nothing:    have network traffic send WAL as needednetflush:    wait for flush of WAL network packets to slaveprocess:
 wait for slave to process WAL traffic and        optionally fsync
 

The 'process' option either waits for fsync on the slave or not
depending on how the slave is configured, meaning you could use
synchronous_commit off to not wait for the fsync to disk.

I think we can add a table in the documention to show how to set things
up in postgresql.conf for async master and async slave, and other
combinations.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


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

Предыдущее
От: Markus Wanner
Дата:
Сообщение: Re: Plugin system like Firefox
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Transaction-controlled robustness for replication