C
ChUIMonster
Guest
The cleverness of users should never be underestimated 
Imagine this: 1) You start an offline backup. 2) Someone notices that the db is not running -- so they execute their usual scripts to restart things. 3) Step #1 is to shutdown down any running databases and stop any left over processes. The *scripted* method is: a) kill -9 any running _pro* processes, b) sleep 5 seconds and then do the same for _mpro* processes, do it again just in case you missed any, c) wait 5 more seconds and kill -9 any _sql processes, d) wait 3 seconds and rm *.lk, and then, finally, ipcrm any shared memory segments that might be lying around. 3a) The shutdown script never even attempts a "proshut". The very first thing it does is to "kill -9" stuff. 4) Now you can go ahead and start your db. 5) Notice that in step #3 no attempt is made to stop probkup? 6) After running for some time the db suddenly announces that the .lk file has disappeared and it shuts itself down. 7) When you try to restart it you discover that the bi file timestamp is out of sync with the database. 8) Interestingly -- the last message prior to the .lk file disappearing is that the backup completed. 9) If you restore that backup it is corrupt. Something that I did not know: probkup does not notice when its .lk file is deleted. It also does not check when it is finished running to see if the .lk file is the same .lk file that it created.
Continue reading...
Imagine this: 1) You start an offline backup. 2) Someone notices that the db is not running -- so they execute their usual scripts to restart things. 3) Step #1 is to shutdown down any running databases and stop any left over processes. The *scripted* method is: a) kill -9 any running _pro* processes, b) sleep 5 seconds and then do the same for _mpro* processes, do it again just in case you missed any, c) wait 5 more seconds and kill -9 any _sql processes, d) wait 3 seconds and rm *.lk, and then, finally, ipcrm any shared memory segments that might be lying around. 3a) The shutdown script never even attempts a "proshut". The very first thing it does is to "kill -9" stuff. 4) Now you can go ahead and start your db. 5) Notice that in step #3 no attempt is made to stop probkup? 6) After running for some time the db suddenly announces that the .lk file has disappeared and it shuts itself down. 7) When you try to restart it you discover that the bi file timestamp is out of sync with the database. 8) Interestingly -- the last message prior to the .lk file disappearing is that the backup completed. 9) If you restore that backup it is corrupt. Something that I did not know: probkup does not notice when its .lk file is deleted. It also does not check when it is finished running to see if the .lk file is the same .lk file that it created.Continue reading...