Re: [ADMIN] Recovery plan for DRDB setup - recovery tool

2006-12-11 Thread Simon Riggs 
On Thu, 2006-12-07 at 09:36 +, Morten Andersen wrote:
 Our initial tests also shows that the failovers are problem free. But
 we
 would like to have a plan for how to handle the case where a failover
 fails.

With respect to DRBD, you'd need to look at how that works specifically
since it isn't part of the basic distrubution.

 So are there any Postgresql tools for analyzing and repairing the
 offline database files (like e.g. the MySQL 'myisamchk'-tool). Or
 are
 there only online tools like 'vacuumdb --full --analyze'. 

The philosophy is different.

PostgreSQL tries to bring up your database and make it available as
quickly as possible, even after a crash. The checking of any changed
data blocks is performed automatically during recovery - so no need to
run a manual tool while the server is down.

The idea that you'd need a checking tool comes from not trusting your
database. The PostgreSQL way is to ensure you don't lose that trust
because there are no short-cuts and leaps of faith taken to make the
database go faster.

-- 
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [ADMIN] Recovery plan for DRDB setup - recovery tool

2006-12-07 Thread Peter Eisentraut 
Morten Andersen wrote:
 So are there any Postgresql tools for analyzing and repairing the
 offline database files (like e.g. the MySQL 'myisamchk'-tool).

No.

 So, how do other DRDB Postgresql sites handles failovers. Do you do
 anything pro-active on the slave before starting Postgresql, or do
 you trust DRDB and Postgresql completely.

If you don't trust PostgreSQL, why would you trust its offline recovery 
tools?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(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