From cs_dba@consistentstate.com Tue Jul 7 17:45:52 2015 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZCWwK-0007AK-9t for pgsql-admin@arkaria.postgresql.org; Tue, 07 Jul 2015 17:45:52 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZCWwJ-0007gz-B9 for pgsql-admin@arkaria.postgresql.org; Tue, 07 Jul 2015 17:45:51 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZCWwH-0007eR-Iy for pgsql-admin@postgresql.org; Tue, 07 Jul 2015 17:45:49 +0000 Received: from mail-ig0-f173.google.com ([209.85.213.173]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1ZCWwF-0008HO-0B for pgsql-admin@postgresql.org; Tue, 07 Jul 2015 17:45:48 +0000 Received: by igcqs7 with SMTP id qs7so38210926igc.0 for ; Tue, 07 Jul 2015 10:45:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=9+4SEAHWJw75N7otmuq4Ewt7jvb7qGBuCzf83ypjrXk=; b=SQ4HNxeCQBqoaRt6T1j2BXNagKmGO8GvXrEkWspoEw7A816XkQmkLD6tMZH59csYZJ lbcyITt68zWStwzFFRt8PTJApPjmXndiimYPz2lhLVs1sjJZmEM5/YfPCCcJO5jx/wjU bBR1Ugb3QXHf8xsul2aCOXVQ4esJqvr/9IVlOUYgFg8Ur9/GNxnuEu/N9RTSt9OEu3HL y55ZO9J8Ip+3n3pAo4Vct4rv0ukAO4JsHHl4vjzvJvUTySB2bWDPtygYGYLqGgTgw3iD SygTdxj/qe1WYy7+o/02h+rh100PPm+qGDpcaxHHbuBrKLBjC6cnj7ScTBl14F9Xf3A/ x8cw== X-Gm-Message-State: ALoCoQnYXy0Bk7YILntJJWDxXAsS4trIc4XZZJn9DwBJ+nTB1DgYwwS0wynrQcjRp1fAeYqZ4bsO X-Received: by 10.107.8.7 with SMTP id 7mr8348836ioi.15.1436291145835; Tue, 07 Jul 2015 10:45:45 -0700 (PDT) Received: from [10.16.0.110] ([50.246.199.241]) by mx.google.com with ESMTPSA id f126sm15049190ioe.21.2015.07.07.10.45.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2015 10:45:44 -0700 (PDT) Message-ID: <559C1046.6010007@consistentstate.com> Date: Tue, 07 Jul 2015 11:45:42 -0600 From: CS DBA User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: pgsql-admin@postgresql.org Subject: Synchronous replication question Content-Type: multipart/alternative; boundary="------------000806010805030504040502" X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org This is a multi-part message in MIME format. --------------000806010805030504040502 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit All; The docs specify this (9.4 docs): Synchronous replication offers the ability to confirm that all changes made by a transaction have been transferred to /*one*/ synchronous standby server. This extends the standard level of durability offered by a transaction commit. This level of protection is referred to as 2-safe replication in computer science theory. Does this mean that Synchronous replication only works with one standby? Thanks in advance --------------000806010805030504040502 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit All;

The docs specify this (9.4 docs):

Synchronous replication offers the ability to confirm that all changes made by a transaction have been transferred to one synchronous standby server. This extends the standard level of durability offered by a transaction commit. This level of protection is referred to as 2-safe replication in computer science theory.

Does this mean that Synchronous replication only works with one standby?

Thanks in advance
--------------000806010805030504040502-- From keith@keithf4.com Tue Jul 7 18:02:26 2015 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZCXCM-0007x3-In for pgsql-admin@arkaria.postgresql.org; Tue, 07 Jul 2015 18:02:26 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZCXCL-00026o-CT for pgsql-admin@arkaria.postgresql.org; Tue, 07 Jul 2015 18:02:25 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZCXCC-0001uy-Jn for pgsql-admin@postgresql.org; Tue, 07 Jul 2015 18:02:16 +0000 Received: from mail-la0-f46.google.com ([209.85.215.46]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1ZCXC7-0007wI-TE for pgsql-admin@postgresql.org; Tue, 07 Jul 2015 18:02:15 +0000 Received: by labgy5 with SMTP id gy5so53474927lab.2 for ; Tue, 07 Jul 2015 11:02:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1COcYPwIEPbeZ51WPDbSLZcPbxAhdQyaR/JzfwOV77o=; b=ddwHZDwwHpCFUxy8CGVcY9uzp5CalDo5DOWWOy5tACqu+D5xaQCP6bna5Lbp+9FIkX hYbMV2sODtocallqFZMXxBnt8jpjy1sYmle0ywdLt0t7jVYMlnXQhfjGoJp53UhVvsDo n+iXufd50ZpEzZocwQjHUXgij8sapdwyGUxq9pL7DuRbxIWGAJZXymEQ10RByVmmztuY /xyO57+D0kzxfA/JluEcjZN1d6tqah70JO/vl50FEu01LdL2i4dptUBMEhREckKzeOTk V2EVQteRESy9Daeh4q03MAS2/M4NTJweuqqjV3qNuNpdNWOXWSTl/D6YZjcNzF8Iqg3E SgRQ== X-Gm-Message-State: ALoCoQlLiXRAliQ67+NUi8epLAiot2CsS+Z+QgR6H107CUOXc4hVJmuH5spm6k373QLP+6qFRZ+k X-Received: by 10.112.126.42 with SMTP id mv10mr5276705lbb.58.1436292129801; Tue, 07 Jul 2015 11:02:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.76.202 with HTTP; Tue, 7 Jul 2015 11:01:30 -0700 (PDT) X-Originating-IP: [108.48.124.82] In-Reply-To: <559C1046.6010007@consistentstate.com> References: <559C1046.6010007@consistentstate.com> From: Keith Date: Tue, 7 Jul 2015 14:01:30 -0400 Message-ID: Subject: Re: Synchronous replication question To: CS DBA Cc: pgsql-admin@postgresql.org Content-Type: multipart/alternative; boundary=001a11c36bc630decf051a4cd261 X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org --001a11c36bc630decf051a4cd261 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 7, 2015 at 1:45 PM, CS DBA wrote: > All; > > The docs specify this (9.4 docs): > > Synchronous replication offers the ability to confirm that all changes > made by a transaction have been transferred to *one* synchronous standby > server. This extends the standard level of durability offered by a > transaction commit. This level of protection is referred to as 2-safe > replication in computer science theory. > > Does this mean that Synchronous replication only works with one standby? > > Thanks in advance > No, it means that it requires, at minimum, one standby to confirm that the transaction has been committed there before the master confirms it back to the client. Look at this section of the docs http://www.postgresql.org/docs/9.4/static/warm-standby.html#SYNCHRONOUS-REPLICATION http://www.postgresql.org/docs/9.4/static/runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES --001a11c36bc630decf051a4cd261 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 7, 2015 at 1:45 PM, CS DBA <cs_dba@consistentstat= e.com> wrote:
=20 =20 =20
All;

The docs specify this (9.4 docs):

Synchronous replication offers the ability to confirm that all changes made by a transaction have been transferred to one synchronous standby server. This extends the standard level of durability offered by a transaction commit. This level of protection is referred to as 2-safe replication in computer science theory.

Does this mean that Synchronous replication only works with one standby?

Thanks in advance

No, it means that i= t requires, at minimum, one standby to confirm that the transaction has bee= n committed there before the master confirms it back to the client. Look at= this section of the docs

http://www.postgresql= .org/docs/9.4/static/warm-standby.html#SYNCHRONOUS-REPLICATION
http://www.postgresql.org/docs/9.4/stat= ic/runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES
--001a11c36bc630decf051a4cd261-- From payal@omniti.com Tue Jul 7 18:08:04 2015 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZCXHo-0008Cw-23 for pgsql-admin@arkaria.postgresql.org; Tue, 07 Jul 2015 18:08:04 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZCXHn-0007s3-C6 for pgsql-admin@arkaria.postgresql.org; Tue, 07 Jul 2015 18:08:03 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZCXDs-0003jM-HM for pgsql-admin@postgresql.org; Tue, 07 Jul 2015 18:04:00 +0000 Received: from mail-ig0-f172.google.com ([209.85.213.172]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1ZCXDk-0000AZ-GO for pgsql-admin@postgresql.org; Tue, 07 Jul 2015 18:03:58 +0000 Received: by igcqs7 with SMTP id qs7so38584276igc.0 for ; Tue, 07 Jul 2015 11:03:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mBOkIKXngnpo/XCffIRu6Itixs5LozZWyUHESgnzPiE=; b=lzbfSAK38fPx4/ohrP3/Z/A6AvgRv3rmqjOcPWcqUUQ4iHQBi554oRnnZ6l999fnid qGO5La92EeKS6A17MN0a9Yh0SBgGrrS8wwyqpqQNEZOBX6FW/uAvrivEhkcm/ArCEfkU Lujib9Fm09J0Sg11EZMfvR0wf6lDsrbFeZSwMgEIs5uMWw7s7uYLg681Uc6VgBWEEQkq Us1VFXUEWvxoYUCvG2tcHcfbMcJ8okUrbt2zgq5ACrNL5PQzxN+MT9kqzUztjeFR+2YG ve5LbhAI03KjmWKEk0QBi9Gc4ShNl8BHZzVAYJTOO5q5253SZzBN/3TnfMmymO5k2RWU SD0Q== X-Gm-Message-State: ALoCoQkLXFMN/4hj2ViODhOy/0nJivi473E0OmD3Um8bwciiOsKjAN/WUKuCuA6BxsG/nWUk6kSN X-Received: by 10.50.117.66 with SMTP id kc2mr53783912igb.31.1436292231198; Tue, 07 Jul 2015 11:03:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.117.137 with HTTP; Tue, 7 Jul 2015 11:03:31 -0700 (PDT) In-Reply-To: <559C1046.6010007@consistentstate.com> References: <559C1046.6010007@consistentstate.com> From: Payal Singh Date: Tue, 7 Jul 2015 14:03:31 -0400 Message-ID: Subject: Re: Synchronous replication question To: CS DBA Cc: "pgsql-admin@postgresql.org" Content-Type: multipart/alternative; boundary=089e0112c4cc3c187b051a4cd86c X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org --089e0112c4cc3c187b051a4cd86c Content-Type: text/plain; charset=UTF-8 As per http://www.postgresql.org/docs/9.4/static/runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES at any time the primary waits for ACK from just one standby server in the list. (The first one, and if its not available, the second one and so on). So even if something goes amiss with the synchronous slave, the secondary slave will become synchronous provided its listed in synchronous_standby_names. Payal Singh, Database Administrator, OmniTI Computer Consulting Inc. Phone: 240.646.0770 x 253 On Tue, Jul 7, 2015 at 1:45 PM, CS DBA wrote: > All; > > The docs specify this (9.4 docs): > > Synchronous replication offers the ability to confirm that all changes > made by a transaction have been transferred to *one* synchronous standby > server. This extends the standard level of durability offered by a > transaction commit. This level of protection is referred to as 2-safe > replication in computer science theory. > > Does this mean that Synchronous replication only works with one standby? > > Thanks in advance > --089e0112c4cc3c187b051a4cd86c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As per=C2=A0http:= //www.postgresql.org/docs/9.4/static/runtime-config-replication.html#GUC-SY= NCHRONOUS-STANDBY-NAMES at any time the primary waits for ACK from just= one standby server in the list. (The first one, and if its not available, = the second one and so on). So even if something goes amiss with the synchro= nous slave, the secondary slave will become synchronous provided its listed= in synchronous_standby_names.=C2=A0

Payal Singh,
Database Administrator= ,
O= mniTI Computer Consulting Inc.
Phone:=C2=A0240.646.0770=C2=A0x 253

On Tue, Jul 7, 2015 at 1:45 PM, CS DBA <cs_dba@consistentstate.com> wrote:
=20 =20 =20
All;

The docs specify this (9.4 docs):

Synchronous replication offers the ability to confirm that all changes made by a transaction have been transferred to one synchronous standby server. This extends the standard level of durability offered by a transaction commit. This level of protection is referred to as 2-safe replication in computer science theory.

Does this mean that Synchronous replication only works with one standby?

Thanks in advance

--089e0112c4cc3c187b051a4cd86c--