Good point, should have included in my post. We were already using
mysqlhotcopy to make snapshots of our data in another directory, which
were then subsequently backed up to tape by the backup agent. We set
the backup agent to specifically exclude the live data directory,
/usr/local/mysql/data (varies by install so check yours), and our
crashing problem went away.
I would think a NAS snapshot would be a very different process, more
akin to a Veritas Volume Manager or Sun disk suite disk mirror operation
than a filesystem backup, and so would not interfere with MySQL.
However, my NAS experience is limited to little Quantum Snap! servers,
which may be a very different animal (and which don't do snapshots).
I wouldn't necessarily regard the fact that the times are different as
an indicator that it's not the cause of the problem - it could be that a
process (like the snapshot) is corrupting the table but MySQL is able to
keep going for some time, until the next time it needs to access a
portion of the table (issuing an UPDATE command perhaps).
Can you uncover more info about what exactly the snapshot operation entails?
Dan
[EMAIL PROTECTED] wrote:
The NAS does make snapshots periodically (every few hours), but it
doesn't look like the timestamps of the records match up with when the
backup would have run (the records are written each minute) so I
don't think that that is the cause.
What did you do to resolve the issue?
--
Mark P. Hennessy
Dan Buettner wrote:
---
Mark, any chance that a process on the NAS is accessing your data files
for some reason? Backups?
We had some severe crashing problems with MySQL years ago we eventually
traced to a backup process accessing the live data directory.
Dan
[EMAIL PROTECTED] wrote:
*** This happens for me using FreeBSD 6.0 or FreeBSD 6.1 with the most
recent MySQL 4.1 or 5.0 built from ports and when the DBMS data files
reside on a NetApp NAS share shared over NFS. It only seems to happen
with very frequently written-to tables. I sent this to the list last
week and no one responded. ***
Hi, I was wondering if anyone else had encountered this issue and/or
come
up with what needs to be done to resolve it:
I currently have MySQL 5.0.22 built from ports on a FreeBSD 6.1 machine
with the DB data residing on a NetApp share connected via NFS. A
strange
thing happens often after a few hours or a couple of days, some tables
that are very active start to crash for no apparent reason as far as I
can tell.
Example output from check table tablename:
+----------------------------+-------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text
|
+----------------------------+-------+----------+-------------------------------------------------------------------+
| dbname.tablename | check | warning | Table is marked as crashed |
| dbname.tablename | check | error | Found key at page 18259968 that
points to record outside datafile |
| dbname.tablename | check | error | Corrupt
|
+----------------------------+-------+----------+-------------------------------------------------------------------+
I've seen this happen on FreeBSD 6.0 and 6.1 with MySQL 4.1.x and MySQL
5.0.x built from ports. Has anyone else seen this and if so has a
resolution been found?
--
Mark P. Hennessy
--
Dan Buettner
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
