Re: 24x7x365 high-volume ops ideas

Поиск
Список
Период
Сортировка
От Chris Browne
Тема Re: 24x7x365 high-volume ops ideas
Дата
Msg-id 60r7muiwk7.fsf@dba2.int.libertyrms.com
обсуждение исходный текст
Ответ на 24x7x365 high-volume ops ideas  ("Ed L." <pgsql@bluepolka.net>)
Список pgsql-general
Karim.Nassar@NAU.EDU (Karim Nassar) writes:
> 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...

The "problem" is that this requires modifications to the application,
and communicating configuration changes gets that bit more
complicated.

Supposing, for instance, the code that accesses connections has
already gotten wrapped in some more-or-less arcane object class
specific to the application, it may be somewhat troublesome to make
the modification.

It would be attractive to allow the configuration change to take place
outside the application in a manner that allows the application to be
completely ignorant about it.

By the way, your db_connect() suggestion doesn't cope with the problem
where a connection is broken and the application continues to use that
broken connection.  There may be a need to cope with that...
--
let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];;
http://www.ntlug.org/~cbbrowne/linuxxian.html
A VAX is virtually a computer, but not quite.

В списке pgsql-general по дате отправления:

Предыдущее
От: jseymour@linxnet.com (Jim Seymour)
Дата:
Сообщение: Re: "q" with psql display paging dumps out of psql
Следующее
От: CSN
Дата:
Сообщение: Preventing connections during vacuum and reindex