Review: Patch for Synchronous Replication

From: Thom Brown <thom(at)linux(dot)com>
To: pgsql-rrreviewers(at)postgresql(dot)org
Subject: Review: Patch for Synchronous Replication
Date: 2010-09-29 22:29:24
Message-ID: AANLkTi=Bs8ZUjtXGqjqzaBT66SB=NknxtWRwWdkddVQG@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-rrreviewers

This is a basic review of Fujii Masao's synchronous replication patch
from http://archives.postgresql.org/message-id/AANLkTik2c3kV7HgJnM4MjkCWVG-QvDJXD3iR9TqsCnpP@mail.gmail.com

Review Description
==================
This patch extends existing asynchronous streaming replication with
options to enable different levels of synchronous behaviour. On the
primary, the is a new standbys.conf file containing a manifest of
standbys it seeks a form a confirmation from before committing
transactions. These contain standby name, level of synchronicity (if
it wasn't a word, it is now), and a timeout value specifying how long
the primary is willing to wait for confirmation before aborting the
transaction. On the standby, the new option "standby_name" has been
added to publish a named identity of the standby server to the
primary.

Patch application
=================
The patch applies cleanly to HEAD. All regression tests pass
successfully as expected.

Testing
=======
I configured the primary's standby.conf to provide synchronous
replication to a single slave using fsync as it's replication level
and a timeout of 100ms. The wal_level was set to hot_standby in
postgresql.conf. The standby's recovery.conf had its standby_name
value set to match that expected by the primary's standby.conf. This
is summarised as follows:

## primary postgresql.conf:
wal_level = hot_standby
max_wal_senders = 2
wal_keep_segments = 2

## primary standbys.conf
# STANDBY NAME SYNCHRONOUS TIMEOUT
cougar fsync 100ms

## primary pg_hba.conf
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host replication postgres 192.168.102.17/32 trust

## standby postgresql.conf
hot_standby = on

## standby recovery.conf
standby_name = 'cougar'
standby_mode = 'on'
primary_conninfo = 'host=192.168.102.125 port=5432'

Issues
======

The primary started up fine and was accepting connections. A base
backup was taken for the standby, and after configuring the standby, I
attempted to bring it up, but received the following error:

postgres(at)cougar:~/project/data$ pg_ctl start
server starting
postgres(at)cougar:~/project/data$ LOG: database system was shut down in
recovery at 2010-09-29 22:52:24 BST
LOG: entering standby mode
LOG: redo starts at 0/1000020
LOG: record with zero length at 0/10000B0
FATAL: could not connect to the primary server: invalid connection
option "standby_name"

I believe I am using the correct parameter as I followed the
additional documentation provided in the patch.

Conclusion
==========

It at least appears to me that it isn't functional in its current
state, or there is setup information missing from the
documentation.... or I've make a stupid mistake somewhere (likely).

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thom Brown 2010-09-29 22:57:33 Re: Review: Patch for Synchronous Replication
Previous Message Kevin Grittner 2010-09-29 21:45:11 Re: Using streaming replication as log archiving

Browse pgsql-rrreviewers by date

  From Date Subject
Next Message Thom Brown 2010-09-29 22:57:33 Re: Review: Patch for Synchronous Replication
Previous Message Marko Tiikkaja 2010-09-29 19:14:07 Re: [HACKERS] top-level DML under CTEs