Re: scripted log backup/recovery

See my comment in between your reply.

On Thu, 2005-01-27 at 11:32, Raimund Jacob wrote:

    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?


Since both instances are failover of each other I keep them identical.
So I changed the parameter in both. I have not tested if it is required
on the exporting machine.

    > 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 guess not, it was just a decission I made.

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

I use a little different approach here. SInce there are many scripts
running I don't do error checking every script separatly because most of
the time when something goes wrong I want to solve it manually. Therefor
all scripts scheduled in cron send all output to log files. At regular
intervals (5 min) I run a watchers script. That script processes all
changed logfiles for certain error messages or the absence of "approved
OK" messages(I use awk to do that). If it encounters an error message it
sends me a mail with the content of the logfile. Then I intervene. 


    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=filip.sergeys@xxxxxxxxxxxxxxxx
    

-- 
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
* System Engineer, Verzekeringen NV *
* www.verzekeringen.be              *
* Oostkaai 23 B-2170 Merksem        *
* 03/6416673 - 0477/340942          *
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*