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
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 |
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 |