I have MySQL 3.23.58 running on Solaris 9 x86, and it's been working fantastically.
I recently added this to a crontab:
/usr/local/mysql/bin/mysqldump --all-databases --opt -u jklett > /storage/backup/mysql-all-databases.sql 2>&1
And the backup file gets created with the right amount of data. However, after a short while, the applications that I have running against this database will start to get spurious errors, which eventually result in the infamous "127" error from the table handler. A quick shutdown and myisamchk fixes the problem, but then when the backup runs again the next day at 4 am... you get the picture, I think.
I commented out the backup in the crontab and my applications have been running for over a week with no problems whatsoever.
Now, I was under the impression that using the --opt option in mysqldump would keep me from having to completely shutdown the database in order to do the dump, since it does a LOCK TABLES and a FLUSH TABLES before doing the copy.
I read that it only does a read lock - is it possible that a write lock is more appropriate here?
I've looked at mysqlhotcopy and it makes me nervous. Plus, I'd like to have the backup be in SQL.
So, my questions are:
a.) What am I doing wrong?
b.) Is there a proven way to backup MySQL databases that have to be up and running 24/7/365?
Thanks very much!
cheers,
- Jared
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
