That's great, Scott!
So 3.4 allows a more elegant work around, but you still need intelligence
in your bpstart_notify/bpend_notify. The intelligence is needed to pass on
to the other bpstarts whether the "parent" bpstart worked. (If the parent
one got a 73, you wouldn't want the others to continue.)
Here's the logic as I see it now, and I still see an issue below.
bpstart_notify
1. Am I STREAM_NUMBER 1 or 0? If so, run the necessary script (e.g.
shutdown oracle).
If not, skip to step 4.
2. Did it work? Touch a file that will tell the other bpstarts that it worked.
(e.g. 'echo 0 > /usr/openv/netbackup/logs/bpstart/$class.exitcode)
3. If it worked, exit 0. If it didn't exit with a 1.
4. If you're not in charge, look for
/usr/openv/netbackup/logs/bpstart/$class.exitcode
If it's not there, wait. If it's there, read the number in it.
5. If the number was 0, exit 0. If not, exit 1.
bpend_notify
1. Does my STREAM_NUMBER=STREAM_COUNT?
If so, run the necessary script (e.g. startup oracle).
If not, skip to step 4.
2. Did it work? Touch a file that will log that it worked.
(e.g. 'echo 0 > /usr/openv/netbackup/logs/bpend/$class.exitcode)
3. If it worked, exit 0. If it didn't exit with a 1.
4. If you are not in charge, just exit
This all sounds great. There's only one problem. The STREAM_COUNT is per
client, class, and SCHEDULE. Due to how Netbackup schedules backups with
frequency, it is not uncommon for full, incremental, and cumulative
incremental backups to run all in the same night. For example, /, /usr,
and /var may be due for their full backup, /home1 and /home3 for their
incremental backup, and /home4 and /home2 for their cumulative incremental
backup. In this scenario, /, /usr and /var would get a STREAM_COUNT of 3,
and / would be STREAM_NUMBER 1. Then /home1 and /home3 would get a
STREAM_COUNT of 2, and /home1 would be STREAM_NUMBER 1. The same would
happen to /home4 and /home2.
So...
The logic above ONLY works if you do NOT use schedule-based bpstart_notify
scripts. If you do, chaos would result. In the scenario above, three
different jobs would all think they were "in charge," and would attempt to
run the script. If the script for the incremental is different than that
for a full, and has no relationship to it, then that would be
fine. HOWEVER, what if you shut down oracle during full backups, but put
it in hot backup mode during incremental backups? One script would really
collide with the other.
So...
The logic above ONLY works if you do NOT use schedule-based bpstart_notify
scripts. (BTW, the same is true for my 3.2 work-around.)
So who wants to code this?
At 11:41 PM 10/20/00 -0500, you wrote:
>A new feature in 3.4 is the ability of bpstart_notify & bpend_notify to work
>with multiple data streams.
>
>Check out the new variables STREAM_NUMBER and STREAM_COUNT.
>
>STREAM_NUMBER is 0 if multiple data streams is disabled. If multiple data
>streams is enabled it will start with 1 and increment for each stream.
>
>STREAM_COUNT is the total number of streams generated.
>
>
>Scott Kendall
>Hospital Products Division
>Abbott Laboratories
>
>
>
>
>
>curtis AT colltech DOT [email protected] on 10/20/2000 04:15:59 PM
>Sent by: veritas-bu-admin AT Eng.Auburn DOT EDU
>To: veritas-bu AT mailman.eng.auburn DOT edu, steingra AT pprd.Abbott DOT Com
>cc:
>Subject: Re: [Veritas-bu] Any decision reached on multi-streaming and
>
>It was REAL tricky.
>
>How to figure out which job is first is not too bad. Essentially, we have
>them all touch a file pattern, and whichever one touches it first is "in
>charge." However, since several may start at the exact same second, you
>need to have them sleep a unique time before touching the file. We use the
>last two digits of the process id times 2.
>
>HOWEVER, how do you figure out which job is LAST? The ONLY way to do it is
>to use bpdbjobs, and bpdbjobs is not on the client unless its a media
>server. We cheated and put it there.
>
>As simple as all this may sound, it took weeks of trial and error to get it
>right. The biggest time loss was the 'jobs start all at once'
>problem. Before adding the sleep, we couldn't figure out why some would
>work and some would not -- especially on HPs. Go figure. Five scripts
>would touch five files, then they would do an ls to see who touched the
>pattern first, and the five scripts would not AGREE! That's why we had to
>add the sleep.
>
>I don't envy anyone having to go through that. That's why we offer this
>workaround free for anyone who wants it.
>
>At 06:38 PM 10/18/00 -0500, Andrew Steingruebl wrote:
> >A while ago there was a discussion about how to make sure that the
> >bpstart/end
> >scripts for a class with multi-streaming were only executed once. It
> appears
> >that the only good way to do it is to write some sort of checkpoint that
> >stores state for each time a start is called, and then only calls the end
> >script when the checkpoint decrements to 0.
> >
> >This doesn't seem extremely difficult to do, but Curtis indicated back in
> >November that it was a little tricky, so I'm not sure I'm thinking of
> all the
> >issues.
> >
> >Anyone want to volunteer the answer?
> >
> >Thanks.
> >
> >--
> >Andy Steingruebl | e-mail: steingra AT pprd.abbott DOT com
> >Unix Systems Admin/Programmer | phone: (847) 935-4728
> >Unix/Network Security | fax: (847) 935-0142
> >Abbott Laboratories, PPDR&D | post: 100 Abbott Park Road, D472 - AP9A
> > | Abbott Park, IL 60064-6115
> >
> >
> >_______________________________________________
> >Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> >http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>---
>W. Curtis Preston, Principal Consultant at Collective Technologies
>Email: curtis AT colltech DOT com (Best way to contact me)
>Work : 408 452 5555 (Leave a message.)
>Pager: 800 946 4646, pin#1436065 (If urgent.)
>
>Tap into the Collective Intellect (TM): http://www.colltech.com
>Backup & Restore resources: http://www.backupcentral.com
>
>_______________________________________________
>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
>_______________________________________________
>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
---
W. Curtis Preston, Principal Consultant at Collective Technologies
Email: curtis AT colltech DOT com (Best way to contact me)
Work : 408 452 5555 (Leave a message.)
Pager: 800 946 4646, pin#1436065 (If urgent.)
Tap into the Collective Intellect (TM): http://www.colltech.com
Backup & Restore resources: http://www.backupcentral.com
|
