>
> because you quickly get trapped into OS specific quicksand with these
> features.
>
Isn't that an issue with just about every feature? Besides the issues
have already been solved mostly. Pgpool already exists. Tatsuo Ishii
says porting a windows is just a resource issue as he doesn't have the
On 01/17/12 12:33 PM, Tim Uckun wrote:
I think I am probably going to explore this option first. I don't
know why automatic failover, failback, etc are not built in already. I
guess even connection pooling ought to be built in. Seems like
everybody would need that no?
because you quickly get
>
> I have a few clusters running on EC2 using DRBD to replicate between
> availability zones. It's not fast, but it works. If your write load is under
> 30MB/sec it's definitely an option. I run DRBD over SSH tunnels to get around
> the random IP address issue. I use heartbeat on top for resource
On Tuesday, January 17, 2012 10:34:54 AM Tim Uckun wrote:
> http://www.drbd.org/ ??
> Built in hot standby and hand rolled scripts.
>
I have a few clusters running on EC2 using DRBD to replicate between
availability zones. It's not fast, but it works. If your write load is under
30MB/sec it's d
On Tue, Jan 17, 2012 at 12:31 PM, David Morton wrote:
> Have you looked at a 'shared storage' solution based on DRBD ? I configured
> a test environment using SLES HAE and DRBD with relative ease and it behaved
> very well (can probably supply a build script if you like), there are lots
> of peopl
On Tuesday, January 17, 2012 10:34:54 AM Tim Uckun wrote:
> Hey Guys.
>
> It's been a while since I looked into this and it seems like new
> options have cropped up for postgres HA and scalability. Is there a
> consensus on the "best" way to achieve HA. My primary concern is HA
> but of course a
gresql.org
Sent: Tuesday, 17 January 2012 12:21 PM
Subject: Re: [GENERAL] HA options
>
> I wonder. If its a write heavy database, I totally agree with you. But if
> its mostly read-only, and mostly fits in ram, then a pgpool of servers
> should be faster.
>
> Be nice to kno
>
> I wonder. If its a write heavy database, I totally agree with you. But if
> its mostly read-only, and mostly fits in ram, then a pgpool of servers
> should be faster.
>
> Be nice to know the usage patterns of this database. (and size).
>
In this case the databases are small to medium and the
On 1/16/2012 4:13 PM, Andy Colson wrote:
On 1/16/2012 4:09 PM, John R Pierce wrote:
On 01/16/12 2:04 PM, Tim Uckun wrote:
I realize that. Eventually we might have to go to physical machines
but for now we are using virtual servers and I have to make it work
within that structure.
quite the ca
On 1/16/2012 4:09 PM, John R Pierce wrote:
On 01/16/12 2:04 PM, Tim Uckun wrote:
I realize that. Eventually we might have to go to physical machines
but for now we are using virtual servers and I have to make it work
within that structure.
quite the catch-22. a single well built dedicated serv
On 01/16/12 2:04 PM, Tim Uckun wrote:
I realize that. Eventually we might have to go to physical machines
but for now we are using virtual servers and I have to make it work
within that structure.
quite the catch-22. a single well built dedicated server likely would
be MORE reliable than a c
>
> virtual servers tend to have lousy storage performance, for what thats
> worth. the actual physical resources are being shared by who knows what
> other workloads, and they tend to be higher latency than direct-attach
> storage, or proper SAN.
I realize that. Eventually we might have to go to
On 01/16/12 1:34 PM, Tim Uckun wrote:
the servers will be virtual on either rackspace or amazon so that's
possibly a complication.
virtual servers tend to have lousy storage performance, for what thats
worth. the actual physical resources are being shared by who knows what
other workloads,
On Tue, Jan 17, 2012 at 10:47 AM, David Morton wrote:
> Is shared storage an option for you ? We've had a fairly pleasant experience
> with shared storage partnered up with SLES and its HAE (high availability
> extension) suite using a Pacemaker cluster for resource control. On top of
> this we re
d for reporting and
not failover for us.
From: Tim Uckun
To: pgsql-general
Sent: Tuesday, 17 January 2012 10:34 AM
Subject: [GENERAL] HA options
Hey Guys.
It's been a while since I looked into this and it seems like new
options have cropped up for postg
Hey Guys.
It's been a while since I looked into this and it seems like new
options have cropped up for postgres HA and scalability. Is there a
consensus on the "best" way to achieve HA. My primary concern is HA
but of course any scalability gains would be more than welcome. All
the servers will
16 matches
Mail list logo
