Review: Patch for Synchronous Replication - Mailing list pgsql-rrreviewers
From | Thom Brown |
---|---|
Subject | Review: Patch for Synchronous Replication |
Date | |
Msg-id | AANLkTi=Bs8ZUjtXGqjqzaBT66SB=NknxtWRwWdkddVQG@mail.gmail.com Whole thread Raw |
Responses |
Re: Review: Patch for Synchronous Replication
Re: Review: Patch for Synchronous Replication |
List | 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@cougar:~/project/data$ pg_ctl start server starting postgres@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
pgsql-rrreviewers by date: