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
