Hi Arnaud, perhaps you can still use Slony-I for replication and have another tool automatically handle connections (check out PgPool[1] or SQLRelay[2]). Or go for a middleware replication solution. Check C-JDBC[3], perhaps there is something similar for ODBC? LifeKeeper seems to handle replication at a lower level (filesystem, distributed memory, or such) and does not seem to be very well suited for database replication. However, I've had just a quick glance at the website. Hope that helps Markus [1]: http://pgfoundry.org/projects/pgpool/ [2]: http://sqlrelay.sourceforge.net/ [3]: http://c-jdbc.objectweb.org/ On Wed, 2006-05-31 at 09:36 +0200, Arnaud Lesauvage wrote: > Hi list ! > > I have a small enterprise network (~15 workstations, 1 server), > all running windows OSes. Most of our work is done on a PostgreSQL > DB (on the windows server). > I am the only IT here, and my boss asked me to find a way to have > the database always online, without my intervention. > Last time I went on vacation, the server crashed and no one was > able to repair it. > > Our application connects to PostgreSQL through ODBC, with a simple > TCP/IP connection. > I though that I would first install a Slony-I cluster. That would > be fine for data replication, but still if the main server > crashes, the database connections will not work anymore because > the name of the backup-server will be different than the name of > the master, so all ODBC connection should be changed to use the > new machine name. > Since I cannot ask anyone to do some DNS changes or things like > that, I am looking for a simple way to have my database always > online (note that I already have a UPS and RAID1 on the server to > prevent most failures). > > After some searches, I found LifeKeeper, which looks very good but > is quite expensive ! > Are there easier and/or better solutions than that ? > > Thanks for your advices on this matter ! > > -- > Arnaud > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match
