Hi all,
After realizing that 'clustering' in the PgSQL docs means multiple
DBs behind one server, and NOT multple machines, I am back at square
one, feeling somewhat the fool. :P
Can anyone point me to docs/websites that discuss options on
replicating in (as close as possible to) realtim
On 6/1/07, Madison Kelly <[EMAIL PROTECTED]> wrote:
After realizing that 'clustering' in the PgSQL docs means multiple
DBs behind one server, and NOT multple machines, I am back at square
one, feeling somewhat the fool. :P
I remember being similarly disappointed in this rampant co-opting of
On 6/3/07, Madison Kelly <[EMAIL PROTECTED]> wrote:
> Slony is indeed intended for near-real-time replication; it's
> asynchronous, so slaves always lag behind the master. The amount of
> discrepancy depends on a bunch of factors -- individual node
> performance, network performance, and system l
On 6/3/07, Alexander Staubo <[EMAIL PROTECTED]> wrote:
As a side-note, I sat up pgpool-II today, and was pleasantly surprised
about how easy it all was; within two minutes I had two databases in
perfect sync on my laptop. It has limitations (such as in its handling
of sequences), but compared to
Alexander Staubo wrote:
On 6/1/07, Madison Kelly <[EMAIL PROTECTED]> wrote:
After realizing that 'clustering' in the PgSQL docs means multiple
DBs behind one server, and NOT multple machines, I am back at square
one, feeling somewhat the fool. :P
I remember being similarly disappointed in t
Alexander Staubo wrote:
As a side-note, I sat up pgpool-II today, and was pleasantly surprised
about how easy it all was; within two minutes I had two databases in
perfect sync on my laptop. It has limitations (such as in its handling
of sequences), but compared to Slony it's like a breath of fre
Madison Kelly wrote:
Being a quite small company, proprietary hardware and fancy software
licenses are not possible (ie: 'use oracle' won't help).
How much data do you put in the DB? Oracle has a free version, but it has
size limits.
(Ducking the slings and arrows of outraged PG fans: I p
Lew wrote:
Madison Kelly wrote:
Being a quite small company, proprietary hardware and fancy software
licenses are not possible (ie: 'use oracle' won't help).
How much data do you put in the DB? Oracle has a free version, but it
has size limits.
(Ducking the slings and arrows of outraged
On Sun, Jun 03, 2007 at 01:35:49PM -0400, Lew wrote:
> How much data do you put in the DB? Oracle has a free version, but it has
> size limits.
AFAIK, Oracle's free version doesn't include RAC, which is what would
be needed to satisfy the request anyway.
A
--
Andrew Sullivan | [EMAIL PROTECT
Madison Kelly wrote:
Hi all,
After realizing that 'clustering' in the PgSQL docs means multiple
DBs behind one server, and NOT multple machines, I am back at square
one, feeling somewhat the fool. :P
Can anyone point me to docs/websites that discuss options on
replicating in (as close a
Chander Ganesan wrote:
Madison Kelly wrote:
Hi all,
After realizing that 'clustering' in the PgSQL docs means multiple
DBs behind one server, and NOT multple machines, I am back at square
one, feeling somewhat the fool. :P
Can anyone point me to docs/websites that discuss options on
re
On Mon, Jun 04, 2007 at 04:21:32PM +0200, Chander Ganesan wrote:
> I think you'll typically find that you can get one or the other -
> synchronous replication, or load balancing...but not both. On the other
Hi,
I am in very similar position, but I am more failover oriented. I am
considering us
On Mon, 2007-06-04 at 10:21 -0400, Chander Ganesan wrote:
> It's not too hard to put together a "warm standby" synchronous
> replication mechanism with overhead that isn't too much more than what
> you incur by enabling PITR... Such systems can also have very fast
> failover on failure detection
Simon Riggs wrote:
On Mon, 2007-06-04 at 10:21 -0400, Chander Ganesan wrote:
It's not too hard to put together a "warm standby" synchronous
replication mechanism with overhead that isn't too much more than what
you incur by enabling PITR... Such systems can also have very fast
failover on f
Although I rarely see it mentioned, Skype has some replication tools that
they opensourced.
https://developer.skype.com/SkypeGarage/DbProjects/SkyTools
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
I hava a db server (mysql) in my web application, it include 550
tables and about 10 rows in each table. Now, I want to change the
db server to postgresql and construct a HA environment.
I have two 2U servers to build postgresql server (one is master, the
other is slave), and two 1U servers f
> I hava a db server (mysql) in my web application, it include 550
> tables and about 10 rows in each table. Now, I want to change the
> db server to postgresql and construct a HA environment.
>
> I have two 2U servers to build postgresql server (one is master, the
> other is slave), and two 1
Hello,
> Third idea:
> I install the Slony-I, linux-ha and postgresql on the same server of
> the two 2U servers. The web application access to the db server
> directly and without pgpool.
AFAIK, Slony does not have failover capabilities you need in HA solution:
http://gborg.postgresql.org/pr
> First idea:
> I install the pgpool on each web server (the web server farm include
> 16 web servers), and configure the pgpool as replication mode. The web
> application (written by php) access to the db server through the local
> pgpool daemon.
> The idea sounds a little unusual, dose it seems
Ivan Zolotukhin wrote:
Hello,
> Third idea:
> I install the Slony-I, linux-ha and postgresql on the same server of
> the two 2U servers. The web application access to the db server
> directly and without pgpool.
AFAIK, Slony does not have failover capabilities you need in HA solution:
http:/
Hello,
My company looking for some solution for High availability with Postgres.
Our optional solution is as follows :
Two DB servers will be using a common external storage (with raid). Both
servers are going to use the same DB files on the storage (as
active/passive)
Now I'm trying to understa
Hi Guys,
I have been testing / working with Postgres for a work project, and so
far I am really impressed with this DB system. Takes a little getting
used to, but I am really beginning to love it.
I am looking now at a scenario that does not seem to be a native
ability of Postgres, but might poss
On Sun, Jun 20, 2010 at 07:34:10PM +0300, Elior Soliman wrote:
> Hello,
>
> My company looking for some solution for High availability with Postgres.
>
> Our optional solution is as follows :
> Two DB servers will be using a common external storage (with raid).
Stop right there. This is the Ora
On 21/06/10 00:34, Elior Soliman wrote:
> Hello,
>
> My company looking for some solution for High availability with Postgres.
>
> Our optional solution is as follows :
> Two DB servers will be using a common external storage (with raid). Both
> servers are going to use the same DB files on the s
On 06/20/10 10:36 AM, David Fetter wrote:
On Sun, Jun 20, 2010 at 07:34:10PM +0300, Elior Soliman wrote:
My company looking for some solution for High availability with Postgres.
Our optional solution is as follows :
Two DB servers will be using a common external storage (with raid).
On 20/06/2010 17:34, Elior Soliman wrote:
> Hello,
>
> My company looking for some solution for High availability with Postgres.
There's quite a bit of information in the documentation here:
http://www.postgresql.org/docs/8.4/static/high-availability.html
HTH,
Ray.
--
Raymond O'Donnell ::
Hi,
On 21/06/2010, at 3:37 AM, Raymond O'Donnell wrote:
On 20/06/2010 17:34, Elior Soliman wrote:
Hello,
My company looking for some solution for High availability with
Postgres.
There's quite a bit of information in the documentation here:
http://www.postgresql.org/docs/8.4/static/high
John R Pierce writes:
>>> Two DB servers will be using a common external storage (with raid).
>
> This is also one of the only postgres HA configurations that won't lose
> /any/ committed transactions on a failure. Most all PITR/WAL
> replication/Slony/etc configs, the standby storage runs severa
On 06/21/10 12:23 PM, Dimitri Fontaine wrote:
John R Pierce writes:
Two DB servers will be using a common external storage (with raid).
This is also one of the only postgres HA configurations that won't lose
/any/ committed transactions on a failure. Most all PITR/WAL
replicatio
John R Pierce wrote:
the commercial cluster software vendors insist on using dedicated
connections for the heartbeat messages between the cluster members and
insist on having fencing capabilities (for instance, disabling the
fiber switch port of the formerly active server and enabling the port
On 06/21/10 8:08 PM, Greg Smith wrote:
The hard part of shared storage failover is always solving the "shoot
the other node in the head problem", to keep a down node from coming
back once it's no longer the active one. In order to do that well,
you really need to lock the now unavailable node
On Mon, 2010-06-21 at 23:08 -0400, Greg Smith wrote:
>
> The hard part of shared storage failover is always solving the "shoot
> the other node in the head problem", to keep a down node from coming
> back once it's no longer the active one. In order to do that well,
> you really need to lock th
John R Pierce writes:
> failure modes can
> include things like failing fans (which will be detected, resulting in a
> server shutdown if too many fail), power supply failure (redundant PSUs, but
> I've seen the power combining circuitry fail). Any of these sorts of
> failures will result in a f
John R Pierce wrote:
I don't like power cycling servers, so I'd prefer not to use power
switch based fencing, although I believe my blade box's management
unit is supported as a power fencing device.
I consider power control fencing to be a secondary resort if you don't
have hardware where a
On 06/22/10 1:58 AM, Dimitri Fontaine wrote:
John R Pierce writes:
failure modes can
include things like failing fans (which will be detected, resulting in a
server shutdown if too many fail), power supply failure (redundant PSUs, but
I've seen the power combining circuitry fail). Any of
John R Pierce writes:
> yeah. generally when money is involved in the transactions, you gotta stick
> to the 'no committed data lost ever'. there's plenty of other use cases for
> that too.
Well, it's a cost/benefit/risk evaluation you have to make. It'd be bad
news that the cost for covering y
On 23/06/10 03:05, John R Pierce wrote:
> yeah. generally when money is involved in the transactions, you gotta
> stick to the 'no committed data lost ever'. there's plenty of other use
> cases for that too.
2PC is sometimes a reasonable alternative to shared-storage failover,
though. It can be
[EMAIL PROTECTED] wrote:
Hi Guys,
I have been testing / working with Postgres for a work project, and so
far I am really impressed with this DB system. Takes a little getting
used to, but I am really beginning to love it.
Good to hear it Mr ...Umm... Frog.
I am looking now at a scenario that
Richard Huxton wrote:
[EMAIL PROTECTED] wrote:
I am looking now at a scenario that does not seem to be a native
ability of Postgres, but might possibly be overcome with Sequoia. I am
hoping that there exists the possibility of using Sequoia to replicate
a DB between / among a number of machine
Thanks for the help guys,
I should clear up a little what I am trying to achieve I think.
The primary users of this db and application will be located in an
office, each user with a desktop machine, all networked. They need to
work with this DB in a fairly heavy kind of way, in so far as to say
t
We have an instance of PostgreSQL on Windows 2003 with some application
and our customer have asked for solution
24x7 without human intervention for problem on the hardware/software
primary instance.
Actualy there is a solution with standby.
Is there a product of High Availability for PostgreSQL on
On 18 nov 2008, at 17.09, Pietro Tedesco
<[EMAIL PROTECTED]> wrote:
We have an instance of PostgreSQL on Windows 2003 with some
application
and our customer have asked for solution
24x7 without human intervention for problem on the hardware/software
primary instance.
Actualy there is a so
There are a couple of solutions probably.
First off, search pgfoundry for possibilities, look into clustering and
replication.
A little more insight would make it easier to answer your question:
Determine what you exactly want, what kind of uptime at what expense.
How should it be made available (
There are a couple of solutions probably.
First off, search pgfoundry for possibilities, look into clustering and
replication.
A little more insight would make it easier to answer your question:
Determine what you exactly want, what kind of uptime at what expense.
How should it be made available (
On Tue, Nov 18, 2008 at 11:09 AM, Pietro Tedesco
<[EMAIL PROTECTED]> wrote:
> We have an instance of PostgreSQL on Windows 2003 with some application
> and our customer have asked for solution
> 24x7 without human intervention for problem on the hardware/software
> primary instance.
> Actualy there
Hi Todd,
Interesting you should bring that up, supporting high availability is
actually something we've talked about doing a bit further down the road.
Before we get to that though, there are still quite a few low hanging
fruit to pick.
If someone with experience in this field picks up the ball a
46 matches
Mail list logo
