Thank you all for the quick replies.
John Wiencek
On 1/13/16, 2:43 PM, "Thomas Munro" wrote:
>On Thu, Jan 14, 2016 at 9:34 AM, Joshua D. Drake
>wrote:
>> On 01/13/2016 12:28 PM, jwienc...@comcast.net wrote:
>>>
>>> Is it possible to set up synchronous replication to more that one node
>>> in a
On Thu, Jan 14, 2016 at 9:34 AM, Joshua D. Drake wrote:
> On 01/13/2016 12:28 PM, jwienc...@comcast.net wrote:
>>
>> Is it possible to set up synchronous replication to more that one node
>> in a cluster? Or, am I limited to one synchronous node and one
>> asynchronous node?
>
>
> Yes you can hav
On 01/13/2016 12:28 PM, jwienc...@comcast.net wrote:
Is it possible to set up synchronous replication to more that one node
in a cluster? Or, am I limited to one synchronous node and one
asynchronous node?
Yes you can have N number of synchronous slaves. However, be careful. It
can be a huge
Is it possible to set up synchronous replication to more that one node in a
cluster? Or, am I limited to one synchronous node and one asynchronous node?
Assuming my replicated databases are on nodes: testqa1, testqa2. What would my
synchronous_standby_names entry in my postgresql.conf on my mas
Kevin Grittner schrieb am 29.07.2015 um 23:10:
No, it means that if the primary is hit by a meteor and you promote
the standby, the data will not have been lost. The time between
the successful return of the commit on the primary and the time at
which the change becomes visible on the standby is
On 07/29/2015 02:27 PM, Ravi Krishna wrote:
"Not necessarily. There has been discussion of adding a new mode
which will delay the commit on the primary until it is visible on a
synchronous standby, but I don't recall where that left off. "
Joshua: THis essentially contradicts your statement
"Not necessarily. There has been discussion of adding a new mode
which will delay the commit on the primary until it is visible on a
synchronous standby, but I don't recall where that left off. "
Joshua: THis essentially contradicts your statement to me.
On Wed, Jul 29, 2015 at 5:10 PM, Kevin
Ravi Krishna wrote:
> As per this:
>
> http://www.postgresql.org/docs/current/static/warm-standby.html#SYNCHRONOUS-REPLICATION
>
> "When requesting synchronous replication, each commit of a write
> transaction will wait until confirmation is received that the commit
> has been written to the tran
> Chris/Joshua
>
> I would like to know more details.
>
> As per this:
>
> http://www.postgresql.org/docs/current/static/warm-standby.html#SYNCHRONOUS-REPLICATION
>
> "When requesting synchronous replication, each commit of a write
> transaction will wait until confirmation is received that the
Chris/Joshua
I would like to know more details.
As per this:
http://www.postgresql.org/docs/current/static/warm-standby.html#SYNCHRONOUS-REPLICATION
"When requesting synchronous replication, each commit of a write
transaction will wait until confirmation is received that the commit
has been wri
> Does sync replication guarantee that any inserted data on primary is
> immediately visible for read on standbys with no lag.
Basically yes. Of course there is *some* latency, at the very least
from the network.
If I run a process on a standby machine that displays a value every
0.1 sec and upda
Does sync replication guarantee that any inserted data on primary is
immediately visible for read on standbys with no lag.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Fri, Nov 28, 2014 at 10:24 AM, Teresa Bradbury
wrote:
> I have a replication setup with a master and a single synchronous slave.
> If the slave dies (or the network goes down) I would like any transaction
> on the master that requires writing to fail so I can roll it back. At the
> moment, whe
> From: Teresa Bradbury
>To: "pgsql-general@postgresql.org"
>Sent: Friday, 28 November 2014, 2:24
>Subject: [GENERAL] Synchronous Replication Timeout
>
>
>Hi,
>
>I have a replication setup with a master and a single synchronous slave. If
>the slave
Hi,
I have a replication setup with a master and a single synchronous slave. If the
slave dies (or the network goes down) I would like any transaction on the
master that requires writing to fail so I can roll it back. At the moment, when
I commit it just hangs forever or (if I cancel it using ^
>> PostgreSQL's "synchronous" replication is actually not
>> synchronous
>
> Well, that statement is a bit misleading. What is synchronous with
> the COMMIT request is that data is persisted on at least two
> targets before the COMMIT request returns an indication of success.
> It guarantees that
Tatsuo Ishii wrote:
> I think your problem is not relevant to pgpool-II.
Agreed.
> PostgreSQL's "synchronous" replication is actually not
> synchronous
Well, that statement is a bit misleading. What is synchronous with
the COMMIT request is that data is persisted on at least two
targets befor
On Thu, Sep 25, 2014 at 8:40 AM, Tatsuo Ishii wrote:
> Postgres-XC (or Postgres-XL which is a fork of Postgres-XC) overcomes
> the issue by using "global transaction management" technique.
... At the cost of reducing data availability for sharded tables, and
increasing write load for replicated ta
I think your problem is not relevant to pgpool-II.
PostgreSQL's "synchronous" replication is actually not synchronous
(it's confusing but the naming was developer's decision). Primary
server sends the committed transaction's WAL record to standby and
wait for it is written to the standby's WAL fil
Hello,
we have a setup with Postgres 9.3.4 running on Ubuntu (don't know the exact
version) using streaming replication with a hot standby and pgPool 3.3.3 as a
loadbalancer in front of the two Postgres servers.
While running automated tests we noticed that despite the fact that replication
is
Hello,
We are currently testing Synchronous Streaming replication between two PG
9.1 boxes () in
a test environment, with the slave as hot_standby.
We appear to have it working correctly (changes appear on both) etc
However the following query from (
http://www.dansketcher.com/2013/01/27/monitori
Hi,
On 9 March 2012 02:23, dennis jenkins wrote:
> I've also looked at the Fusion-IO products. They are not standard
> flash drives. They don't appear as SATA devices. They contains an
> FPGA that maps the flash directly to the PCI bus. The kernel-mode
> drivers blits data to/from them via DM
I've also looked at the Fusion-IO products. They are not standard
flash drives. They don't appear as SATA devices. They contains an
FPGA that maps the flash directly to the PCI bus. The kernel-mode
drivers blits data to/from them via DMA, not a SATA or SAS drive (that
would limit transfer rates
On Wed, Mar 7, 2012 at 2:54 AM, Joel Jacobson wrote:
> My company is in the process of migrating to a new pair of servers, running
> 9.1.
>
> The database performance monetary transactions, we require
> synchronous_commit on for all transactions.
>
> Fusion-io is being considered, but will it giv
My company is in the process of migrating to a new pair of servers, running 9.1.
The database performance monetary transactions, we require
synchronous_commit on for all transactions.
Fusion-io is being considered, but will it give any significant
performance gain compared to normal SATA-based SS
On Wed, Feb 29, 2012 at 3:22 AM, Jameison Martin wrote:
> i don't think i've explained things very clearly. the implied contradiction
> is that i'd be using asynchronous replication to catch up a slave after a
> slave failure and thus i'm losing the transactional consistency that i
> suggest i nee
pgsql-general@postgresql.org"
Sent: Tuesday, February 28, 2012 7:32 AM
Subject: Re: [GENERAL] synchronous replication: blocking commit on the master
On Monday, February 27, 2012 10:21:24 pm Jameison Martin wrote:
> I have specific needs for wanting synchronous replication instead of
&g
On Tuesday, February 28, 2012 10:22:14 am Jameison Martin wrote:
>
> i hope that clears it up.
Yes, but before you roll your own you may want to take a look at whats already
out there:
A survey of what is out there:
http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Poolin
On Monday, February 27, 2012 10:21:24 pm Jameison Martin wrote:
> I have specific needs for wanting synchronous replication instead of
> asynchronous replication, notwithstanding my desire to continue processing
> work on the master if there are no active slaves. I would like to use
> replication
master.
Thanks.
From: Adrian Klaver
To: pgsql-general@postgresql.org; Jameison Martin
Sent: Monday, February 27, 2012 5:52 PM
Subject: Re: [GENERAL] synchronous replication: blocking commit on the master
On Monday, February 27, 2012 4:36:26 pm Jameison Martin wrote:
> I ha
On Monday, February 27, 2012 4:36:26 pm Jameison Martin wrote:
> I have observed that a commit on a replication master hangs if there are no
> slaves to communicate with if synchronous replication is enabled. I
> believe I have seen a posting that this behavior is deliberate.
>
> In my environment
I have observed that a commit on a replication master hangs if there are no
slaves to communicate with if synchronous replication is enabled. I believe I
have seen a posting that this behavior is deliberate.
In my environment I'd prefer to have the master continue processing
transactions if the
Tomas Vondra wrote:
> On 22 Listopad 2011, 18:16, Bruce Momjian wrote:
> > Tomas Vondra wrote:
> >> While I don't recommend it, fsync=off definitely is an option,
> >> especially
> >> with sync replication. The synchronous_commit is not a 1:1 replacement.
> >>
> >> Imagine for example a master with
On 22 Listopad 2011, 18:16, Bruce Momjian wrote:
> Tomas Vondra wrote:
>> While I don't recommend it, fsync=off definitely is an option,
>> especially
>> with sync replication. The synchronous_commit is not a 1:1 replacement.
>>
>> Imagine for example a master with lot of I/O, and a sync standby. B
On Tue, Nov 22, 2011 at 12:16 PM, Bruce Momjian wrote:
> Tomas Vondra wrote:
>> On 17 Listopad 2011, 17:07, Jaime Casanova wrote:
>> > On Thu, Nov 17, 2011 at 7:52 AM, Schubert, Joerg
>> > wrote:
>> >> Hello,
>> >>
>> >> I have two servers with battery backed power supply (USV). So it is
>> >> un
Tomas Vondra wrote:
> On 17 Listopad 2011, 17:07, Jaime Casanova wrote:
> > On Thu, Nov 17, 2011 at 7:52 AM, Schubert, Joerg
> > wrote:
> >> Hello,
> >>
> >> I have two servers with battery backed power supply (USV). So it is
> >> unlikely, that both will crash at the same time.
> >>
> >> Will syn
On 17 Listopad 2011, 17:07, Jaime Casanova wrote:
> On Thu, Nov 17, 2011 at 7:52 AM, Schubert, Joerg
> wrote:
>> Hello,
>>
>> I have two servers with battery backed power supply (USV). So it is
>> unlikely, that both will crash at the same time.
>>
>> Will synchronous replication work with fsync=o
On Thu, Nov 17, 2011 at 9:07 AM, Jaime Casanova wrote:
> On Thu, Nov 17, 2011 at 7:52 AM, Schubert, Joerg wrote:
>> Hello,
>>
>> I have two servers with battery backed power supply (USV). So it is
>> unlikely, that both will crash at the same time.
>>
>> Will synchronous replication work with fsy
On Thu, Nov 17, 2011 at 7:52 AM, Schubert, Joerg wrote:
> Hello,
>
> I have two servers with battery backed power supply (USV). So it is
> unlikely, that both will crash at the same time.
>
> Will synchronous replication work with fsync=off?
> That means we will commit to system cache, but not to
What if power supply goes ?
What if someone trips on the cable, and both servers go ?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hello,
I have two servers with battery backed power supply (USV). So it is unlikely,
that both will crash at the same time.
Will synchronous replication work with fsync=off?
That means we will commit to system cache, but not to disk. Data will not
survive a system crash but the second system s
I realize that synchronous replication is in the works for 9.1, but
for 9.0, could you hack your way to synchronous replication by polling
the standby's pg_last_xlog_receive_location() and waiting until it's
>= pg_current_xlog_location() from your last transaction? Any major
pitfalls here (besides
42 matches
Mail list logo
