Re: scripted log backup/recovery

Filip Sergeys wrote:

hello!

> 2) dynamically build a command script that will be executed by dbmcli in
> the very last step. Start with bringing database in admin mode and do
> util_connect

this is what i wanted to do "interactivly" so that the controlling 
script notices errors when they happen. but creating that all-in-one 
scriptfile is a start.

> 3) look for the counter file and extract the lognumber of the last
> applied log file

that's what i do by looking at the backup-history. or at least that was 
the plan.

> 6) if the lognumber in the .arch file is equal to the last applied log
> number -> apply that log again. (this is needed because then you are
> sure to have applied the last log PAGE, as already described in earlier
> mails). The first log you apply should always start with "recover_start
> ARCH LOG $lognr"
> 7) subsequent logfiles are applied with the command "recover_replace
> ARCH </path/to/logfiles/> $lognr"

those two points i learned the hard way, yesterday. seems my guessing 
was correct.

> 9) end with recover_cancel

this is where my kernel crashes. but this probably (?) happens because 
my LOG_SEGMENT_SIZE is too small. i added another log-volume once and 
did not increase it. do i have to set this parameter on both the 
exporting and the importing host?

> 10) util_release (don't forget this one)

oh-kay :) i did not do that yet, but only due to the above.

> 11) bring the database back to sleep

would it do any harm to leave it in admin mode?

> I have been using this for over a year and it works perfectly. So hope
> it can help you too.

thank you very much. i'll look into it. your messages makes me hope that 
it is possible :)

> if recover_replace fails at a certain point and you need to restart.
> First do a db_restartinfo because the last file your
> imported is not the last file in the database (has something to do with
> save points)
> You also have to start with recover_start again for the first log and
> then recover_replace for subsequent logs.
> So if the script fails, it needs a manual interaction. I guess I can
> improve the script on that point, but I haven't had the time.

i guess that's what tilo mentioned. i hope it's enough to look at the 
last log-restore that returned Errorcode 0 and start with this one.

do you inspect the Errorcodes of the recover_start / recover_replace 
calls? how do you know that manual inspection is required? or can you 
send me the output of your script when it runs successfully?

thanks again,
        Raimund

--
7. RedDot Anwendertagung der RedDot Usergroup e.V. am 31.1.2005
Pinuts präsentiert neue Entwicklung, http://www.pinuts.de/news

Pinuts media+science GmbH                 http://www.pinuts.de
Dipl.-Inform. Raimund Jacob               Raimund.Jacob@xxxxxxxxx
Krausenstr. 9-10                          voice : +49 30 59 00 90 322
10117 Berlin                              fax   : +49 30 59 00 90 390
Germany


--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe:    http://lists.mysql.com/maxdb?unsub=gcdm-maxdb@xxxxxxxxxxx