Обсуждение: Recovery plan for DRDB setup - recovery tool

Hello,

We are analyzing a master-slave setup of Postgresql 8.1 using DRDB
(v.0.7, type 'C'), and judging from the mailing list, this setup is
succesfully in production at several places.

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.

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'.

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.

Best regards, and thanks for any input on both the usage of DRDB as well
as on usage of recovery tools.

Morten Andersen and Peter Bagger-Hansen,
Instadia, Denmark

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/

Hi Peter,

Peter Eisentraut wrote:
> 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?

:-) - sorry, I probably misphrased the question a little. It is not
really Postgresql I don't trust. It is more the combination of HW on two
machines, network and DRDB. And it is not really an issue about not
trusting any of the components involved, but about knowing what to do if
we ever find us self with a group of erroneous DB files.

But since you answered that no offline tools exist, and due to phrases
like this:

".. Since the postmaster can now clean up by itself, it is unlikely that
ipcclean will be improved upon in the future." (from the notes section
in the 'ipcclean' utility description:
http://www.postgresql.org/docs/8.1/static/app-ipcclean.html)

I assume that Postgresql is partly "self-repairing", and will handle any
  required cleaning when a DRDB slave starts after a DRDB master failure.

Best Regards
Morten Andersen,
Instadia, Denmark

On Thu, 2006-12-07 at 09:36 +0000, 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