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.
Well, I forgot to tell that the main reason to use the counter was that
I found no way to link the log PAGE number retrieved from db_restartinfo
back to an actual logfile number. The counter was some kind of
replacement mechanism because I found no solution either with
backup-history.
> 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 [EMAIL PROTECTED]
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/[EMAIL PROTECTED]
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
* System Engineer, Verzekeringen NV *
* www.verzekeringen.be *
* Oostkaai 23 B-2170 Merksem *
* 03/6416673 - 0477/340942 *
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
