Re: 24x7x365 high-volume ops ideas

From: Karim Nassar <Karim(dot)Nassar(at)NAU(dot)EDU>
To: Christopher Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: 24x7x365 high-volume ops ideas
Date: 2004-11-08 18:30:17
Message-ID: 1099938617.27046.39.camel@denali.cse.nau.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, 2004-11-07 at 21:16, Christopher Browne wrote:
> None of these systems _directly_ address how apps would get pointed to
> the shifting servers.
<snip>
> Something needs to be "smart enough" to point apps to the right place;
> that's something to think about...

Seems like it would be pretty easy to be smart in PHP:

function db_connect() {
$conn = pg_connect("dbname='foo' user='dawg' password='HI!'
host='master'");
if (!($conn AND (pg_connection_status($conn) == 0))) {
// problem with master
$conn = pg_connect("dbname='foo' user='dawg' password='HI!'
host='replica'");
if ($conn AND (pg_connection_status($conn) == 0)) {
return $conn;
}
} else {
return $conn;
}
return NULL;
}

Whatever client-side language one uses, the technique is the same
(though the coding style might differ :P ), can be used for persistent
connections (eg: with pg_pconnect in PHP), and seems like it could be
extended to any reasonable number of database servers.

What is the problem with this? The only issue I can see is that
"replica" might be behind. Depending on the application, this might not
be bad. If the app MUST have the very most accurate DB, you could remove
the logic that connects to the replica, but then that nullifies this
whole conversation...

\<.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message ru.igarashi 2004-11-08 18:50:26 Re: I spoke with Marc from the postgresql mailing list.
Previous Message Woodchuck Bill 2004-11-08 18:13:25 List of postgresql rogue groups (was Re: Important Info on comp.databases.postgresql.general)