Re: 24x7x365 high-volume ops ideas - Mailing list pgsql-general

Hi Chris and Karim,

I haven't been following this thread, so excuse me if I suggest something
that has already been tossed out.

Solaris allows multiple IP addresses to be assigned to a single NIC.  I
just looked at the man page for Linux ifconfig but didn't see quickly how
to do this.  If Linux doesn't allow this, the same thing can be
accomplished using multiple NICs per server.

We reserve a special IP for the DB server.  This IP can be assigned to the
NIC of the machine currently hosting the database.  If you want apps to
connect to a different server, remove the IP from one machine and reassign
it to the other.  This special DB IP is assigned on top of the regular IP
for the machine.

Newly connecting apps are never the wiser, but existing connections must be
terminated.

machine A: (DB server)

ifconfig hme0 192.1.1.1 up
ifconfig hme0:1 192.1.1.100 up #special DB IP

To change DB server from machine A to B:

MachineB: (New DB server)
ifconfig hme0 192.1.1.2 up
ifconfig hme0:1 192.1.1.100 up

Machine A:
ifconfig hme0:1 down

Hope this helps,

Rick



                     
                      Chris Browne
                     
                      <cbbrowne@acm.org>             To:       pgsql-general@postgresql.org
                     
                      Sent by:                       cc:
                     
                      pgsql-general-owner@pos        Subject:  Re: [GENERAL] 24x7x365 high-volume ops ideas
                     
                      tgresql.org
                     

                     

                     
                      11/15/2004 05:20 PM
                     

                     

                     




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.

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org