Re: PostgreSQL and 2-node failover cluster solutions
От | Chris Miles |
---|---|
Тема | Re: PostgreSQL and 2-node failover cluster solutions |
Дата | |
Msg-id | 20021008215716.E27389@psychofx.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL and 2-node failover cluster solutions (Ragnar Kjørstad <postgres@ragnark.vestdata.no>) |
Список | pgsql-admin |
On Sun, Oct 06, 2002 at 03:21:14PM +0200, Ragnar Kjørstad wrote: > Well; if you have a single NetApp then you still have a single point of > failure (avoiding that is the whole purpose of failover, right?), and if > you have two of them then it's one pretty damn expensive > postgresql-server :) Indeed we run our Netapps as a clustered pair. If you already have the facilities available or can get them for a good price second hand, then I am happy to let the group know that running PostgreSQL servers on Linux and Netapps is not only possible, it is a fast, reliable and stable platform. > Anyway..... > > I presume you are using it to failover PostgreSQL servers? > > No, currently we're only using it for failover lvs- and file-servers. > The principle is the same though: Heartbeat runs on two servers > connected with multiple "heartbeat-channels" (ethernet, serial....). > They constantly monitor each other, and if the secondary server looses > contact with the primary it will start the "services" locally. In your > case the services would be an IP-address and the postgresql-server. > > You also need some "fencing" to make sure that the two servers don't > both start postgresql by accident. This is done with "stonith" (Shoot > the other node in the head) - before the secondary server starts > postgresql it will cut the power to the primary server to make sure it's > not up. > > That's pretty much it. Great, sounds very similar to Kimberlite, and also to our requirements. I will give it a test. > Be awere that failover doesn't solve any problem in the world though: If > postgresql corrupts it's files, both servers are screwed. Also, failover > will complicate the setup, and in general a more complicated setup means > more downtime (operator-error) - so, make sure you read the > documentation and understand how it works (or pay someone to do it for > you). Naturally, that's why we are after as simple a solution as possible. That is also why we went for a simple, free and open database like PostgreSQL rather than a more complex system like Oracle (of course, cost was a factor also :). Thanks for the cluster info. If anyone wants to discuss HA PostgreSQL setups more, drop me a line. Cheers, Chris.
В списке pgsql-admin по дате отправления: