Ben wrote:
> On May 20, 2007, at 3:01 AM, Thomas Lopatic wrote:
> The problem comes when the primary is cannot replicate to the secondary
> but can, for whatever reason, still talk to clients. If a client is told
> something is committed but that commit isn't replicated, you have a
> problem.
Righ
Thomas Lopatic wrote:
>> So what happens in those cases where the primary node gets in trouble
>> but isn't actually dead yet?
>
> Hmmm. Is this really a problem? Couldn't the secondary DRBD node simply
> stop accepting replicated data from the primary node before firing up
> postmaster? Then the
On May 20, 2007, at 3:01 AM, Thomas Lopatic wrote:
So what happens in those cases where the primary node gets in trouble
but isn't actually dead yet?
Hmmm. Is this really a problem?
The problem comes when the primary is cannot replicate to the
secondary but can, for whatever reason, still
On Sun, May 20, 2007 at 12:01:46PM +0200, Thomas Lopatic wrote:
> Hmmm. Is this really a problem? Couldn't the secondary DRBD node simply
> stop accepting replicated data from the primary node before firing up
> postmaster? Then the postmaster on the primary DRBD node would only
> write locally and
> So what happens in those cases where the primary node gets in trouble
> but isn't actually dead yet?
Hmmm. Is this really a problem? Couldn't the secondary DRBD node simply
stop accepting replicated data from the primary node before firing up
postmaster? Then the postmaster on the primary DRBD n
Alvaro Herrera wrote:
Ben wrote:
If you're just looking for a way to have high availability and you're ok
being tied to linux, DRBD is a good way to go. It keeps things simple in
that all changes are replicated, it won't say an fsync is finished until
it's finished on the remote host too,
Oh
Er, yes, sorry, I didn't mean to imply that you should run without
some kind of STONITH solution, to catch the case when the link DRDB
uses goes down but the other network links are still working fine.
It's in the common case, when everything is working, that DRBD won't
accidentally let you
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of
>Andrew Sullivan
>Sent: zaterdag 19 mei 2007 15:28
>To: pgsql-general@postgresql.org
>Subject: Re: [GENERAL] Data replication through disk replication
>
>On Fri, May 18, 20
On Fri, May 18, 2007 at 05:03:30PM -0700, Ben wrote:
> that all changes are replicated, it won't say an fsync is finished until
> it's finished on the remote host too, and it won't let you mount the block
> device on the slave system (at least with 0.7x).
How can it guarantee these things? Th
You pay a price writes, but with write caching enabled on your
(battery-backed, of course) RAID card and using gigabit, it's easy to
get >100MB/s throughput. It's also easy to replicate different block
devices over separate network links, if that becomes your bottleneck.
On May 18, 2007, a
Ben wrote:
> If you're just looking for a way to have high availability and you're ok
> being tied to linux, DRBD is a good way to go. It keeps things simple in
> that all changes are replicated, it won't say an fsync is finished until
> it's finished on the remote host too,
Oh, so that's how i
If you're just looking for a way to have high availability and you're ok
being tied to linux, DRBD is a good way to go. It keeps things simple in
that all changes are replicated, it won't say an fsync is finished until
it's finished on the remote host too, and it won't let you mount the block
d
On Fri, May 18, 2007 at 07:55:24PM +0200, Thomas Lopatic wrote:
> For Slony-I it seems to me that my risk is losing a couple of rows in my
> database, which is something that I could live with. For disk-level
> replication it seems to me that, in case of a master failure, I could
> easily end up w
[Disk-level replication instead of using Slony-I]
> What are the reasons they recommend this? (See my blathering in
> another thread about how often the hand-wavy recommendations that are
> made on this topic can really bite you hard if you don't know all the
> intimate details underneath.)
The
On Fri, May 18, 2007 at 02:48:03PM +0200, Thomas Lopatic wrote:
> I am currently looking into replicated two-node master/slave PostgreSQL
> environments. Lately I've heard more and more people recommend
> replicating data from the master to the slave at the disk device level
> as opposed to the DB
On Fri, May 18, 2007 at 02:48:03PM +0200, Thomas Lopatic wrote:
> What I keep wondering: Isn't there substantial risk involved?
> I mean, suppose the master fails in the middle of a write. Isn't there
> the possibility that this corrupts the database? How robust is
> PostgreSQL's on-disk file forma
Hi there,
I am currently looking into replicated two-node master/slave PostgreSQL
environments. Lately I've heard more and more people recommend
replicating data from the master to the slave at the disk device level
as opposed to the DBMS level (Slony-I). On Linux, usually DRBD is
recommended for
17 matches
Mail list logo
