Well, the first obvious suggestion is to use RAID to avoid "hiccups" with disk failure. You probably already have that.
At my last job we setup all our servers so that everything was stored on an external RAID. The only thing on the internal (software mirrored) disks was the OS and whatever config files couldn't be stored on the external disks. A cron ran nightly to copy the config files on the internal drive to a backup machine, usually the development machine. If a problem occurred on the production machine, the cables to the external disks would be connected to the backup machine and a script run to reconfigure (change IP address, put config files in place, etc.) the backup machine as the production machine. Reboot and you're back online. Not exactly a hot backup, but the complete switchover could be done within 20 minutes. The longest part being the reboot. The size of the database was not an issue because you weren't restoring or copying anything, except small config files. There were some very large Oracle databases that grew by about 40 million records per month (HBO/Cinemax monthly subscribers). This setup does you no good in the event of database corruption. > Good Friday Morning to you all! > > Some of our MySQL databases are approaching the extrememly large size (10's > of millions of records) and while we do regularly scheduled maintenance via > CRON, and we do nightly differential back-ups couple with full back-ups on > the weekends. Data is added at a fairly brisk pace, we archive data older > than 90 days either in seperate tables (AWK script running SELECT ...INTO > statements via CRON) or by running queries to get specific information (AWK, > CRON) into other tables and deleting records, plus a couple of other ways. > We maintain back-ups for a long, long time. > > Yesterday I was told that we could expect our incoming data to grow by a > factor of 3 in the next 4 months and that incoming data would grow by a > factor of 10 over the next year. We're growing! Yippee for us! (he says, > while trying to maintain a non-facetious look on his face) I always picture > the worst possible scenario, because if something happens to the data my > butt will be the one in the sling. Unless I can put if off on our hardware > guys. > > So I am curious, how are you performing maintenance? I have a written > maintenance plan which is reviewed periodically so that adjustments can be > made if needed, but this plan looks a little thin to me when it comes to > maintaining the size and scope of data that seems to be headed down the road > towards me. Any suggestions you have would be most appreciated. > > Thanks! > > Jay > > --------------------------------------------------------------------- > Before posting, please check: > http://www.mysql.com/manual.php (the manual) > http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > -- Brent Baisley Systems Architect Landover Associates, Inc. Search & Advisory Services for Advanced Technology Environments p: 212.759.6400/800.759.0577 --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
