I'm running bacula under Linux, and I'm experiencing sporadic segmentation
faults when dumping the catalog database. The seg faults seem to appear about
every 10~20 days, and seem to keep re-occuring (once they start) until the
database is restarted.

Even after the database is restarted, it sometimes takes a few successive dumps 
to get a dumpfile written successfully.

The command being used to dump the database is:

    /usr/bin/mysqldump -u $2$MYSQLPASSWORD -f -v \
                --skip-opt      \
                --add-drop-table        \
                --add-locks     \
                --create-options        \
                --extended-insert       \
                --flush-logs    \
                --quick         \
                --set-charset   \
                --single-transaction    \
         $1 >$1.sql 2> $1.sqldump.errs

When the dump is unsucessful, the bacula.sqldump.errs file simply ends with the 
lines:
        -- Retrieving table structure for table File...
        -- Sending SELECT query...
        -- Retrieving rows...


The seg faults began when the database was using ISAM tables, and have continued
through a few db upgrades, and even after dropping and reloading the database.

All other bacula and db operations seem fine (backups, restores, creating/
dropping indices, optimizing the database). The bacula server runs other 
functions as well (cluster head node and computational server)--and there 
aren't any indications of memory or other hardware errors.

I am clearly not a DBA, but I suspect some data within the database as causing 
the 
problem. Does that sound reasonable?


Here's the environment:

        Bacula 1.38.11 (soon to upgrade)
        Linux 2.4.26 (FC1 based)
        Mysql 5.0.22
        About 20 clients

Currently, the database is about 11GB while running, and about 3.3GB when 
dumped. I'm using the InnoDB engine. 

Here are some database stats:
        File table contains             26654181 rows
        Filename table contains          6482800 rows
        Job table contains                  1883 rows
        Jobmedia table contains            28763 rows
        Path table contains               597237 rows

The database has File_PathId_idx and File_FilenameId_idx indicies.

Full backups are run monthly, and retained for 6 months plus 2 weeks.
Differential backups are run weekly and retained for a month plus a week.
Incremental backups are run nightly and retained for a month plus a week. 

The database has been in production use since August.

Running dbcheck shows:

        Found 0 bad Filename records.
        Found 0 bad Path records.
        Found 0 duplicate Filename records.
        Found 0 duplicate Path records.
        Found 0 orphaned JobMedia records.
        Found 0 orphaned File records.
        Found 194350 orphaned Path records.
        Found 1212673 orphaned Filename records.
        Found 3 orphaned FileSet records.
        Found 0 orphaned Client records.
        Found 2 orphaned Job records.
        Found 0 Admin Job records.
        Found 11 Restore Job records.

My questions are:

        [1] Are segmentation faults from "mysqldump" a known problem, and is 
                there a known solution?

        [2] Do the database statistics seem "normal", given the usage that I 
                described?

        [3] Are the number of orphaned Path and Filename entries found by 
                dbcheck reasonable?

        [4] Is it safe to have dbcheck delete the orphaned records?

        [5] Are there any obvious things that can be done to improve the 
                database reliability, stability, or performance?

I understand that there's probably too little information in this post to give 
detailed answers to all these questions, and that doing database tuning via 
e-mail is difficult at best, but I'd appreciate your insight.

Thanks,

Mark

----
Mark Bergman                      [EMAIL PROTECTED]
System Administrator
Section of Biomedical Image Analysis             215-662-7310
Department of Radiology,           University of Pennsylvania

http://pgpkeys.pca.dfn.de:11371/pks/lookup?search=mark.bergman%40.uphs.upenn.edu




The information contained in this e-mail message is intended only for the 
personal and confidential use of the recipient(s) named above. If the reader of 
this message is not the intended recipient or an agent responsible for 
delivering it to the intended recipient, you are hereby notified that you have 
received this document in error and that any review, dissemination, 
distribution, or copying of this message is strictly prohibited. If you have 
received this communication in error, please notify us immediately by e-mail, 
and delete the original message.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to