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 [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]
