Kern Sibbald wrote:
Hello,
It looks to me like MySQL 4.0 has changed the way they deal with indexing and keys since version 3.23.51. It appears as if they are using *only* the index to decide if the key is unique or not. The index was setup on the first 50 characters of the path. Previously, the index was used for indexing only and not to determine uniqueness.
Did you recently upgrade to MySQL 4.0? The solution I can see is to drop the index on Path and the index on Filename, then recreate them but create them on the full Path and the full Name rather than limiting it as is currently the case in the make_mysql_tables file.
Would just running an alter table fix it?
The MyISAM and (as of MySQL 4.0.14) InnoDB storage engines also support indexing on BLOB and TEXT columns. When indexing a BLOB or TEXT column, you must specify a prefix length for the index. For example:
CREATE TABLE test (blob_col BLOB, INDEX(blob_col(10)));
Prefixes can be up to 255 bytes long
So, you think changing the INDEX to 255 bytes long would fix it?
Though this seems kinda weird, as I don't see anything in the table definition which indicates that entries in Bacula.Path.Path have to be unique. :/
I am re-running the winserver backup to regenerate the errors. I will try and look for the first occurence and see if that sheds any light.
I will also re-run my basic sql statements to see if the output is the same or different.
Especially as I can't remember if I ran dbcheck before or after the last set of errors, and it may have deleted cluefull data as "orphaned".
-Mike
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
