Issue: Database errors

I have seen this happen only with one other user (before RC3: http://www.vaultwiki.org/threads/4425/) and it unfortunately means that the vault_link table was mysteriously corrupted. Some questions are: did you encounter problems during the upgrade process. Did you restore your database recently before or after upgrading to RC3?

I can check some other things while looking at your autolink issue. It's hard to say at the current time whether this is entirely VaultWiki related or if the table was corrupted some other way.

If you're still having problems, you'll need to drop the vault_link table and re-add it.

Since I upgraded to rc3 the wiki has not been good. I wish I could go back, but have no idea how to do this without costing me mass time.
Yes it's still doing this and autolink is not working again.

it shows ~157,488 for records. What does this mean? When you say drop it, and re add it, would I loose all the content I've added?

Yes you will lose the contents of that table, which would make certain Special page output inaccurate. This is cached content and will rebuild over time. As I mentioned in my post above, this issue is not new to RC 3.

So I should drop the table or dump the table?

DROP it.

I've made some changes to some vault_link queries in the next release, hopefully this should avoid any more corruption until 3.1.0 when the link queries will require significantly less resources.

I dropped the table but its re occurring again. Until your next build, is it necessary to drop the table every time the error starts up again? Does this error mean my members are seeing the error and is this creating problems other than just my notice?

This error occurs after the table has already become corrupt. This particular query only runs when a new article is created. Have you noticed in your logs anything that might signify WHY the table was corrupted in the first place? Were there any queries that timed out or were flagged as 'slow'? Were there any database errors that had incomplete or empty code?

I have no idea and this only started occuring after RC 1. I skipped RC 2

See if the following helps. My tests reveal that this query uses a key merge that exceeds the max key length in InnoDB when the character set is UTF8 which could be causing the problem:

Unfortunately this is not something we can simply fix. It's a bug that has eluded us for a long time and we have never been able to reproduce on our own servers. If you could provide a database dump of the vault_link table and upload this as an attachment, or email to support@vaultwiki.org, we might be able to create a server instance that duplicates the issue. Until then, this cannot be fixed with any certainty.

Hi, I unfortunately uninstalled it all an hour ago. Its gone. Having all those members not being able to post after sending a mass mail , people complaining and loosing their info and the embarrassment of it all that I'm done with the VW. Too many bugs.

Thanks for your support.

Well I created a test database with 300,000 rows (yours had 160,000) and still didn't encounter this problem on an UPDATE. That said, our server is using a much later version of MySQL than yours is. There have been quite a few MySQL bugs (not VaultWiki bugs) which caused 'can't find record in' messages that have been solved by its devs, but it's hard to say whether this is simply an update-MySQL-to-solve issue. For example, one of the bugs displayed that error message when a result set could not be found within the MySQL timeout limit. So I started looking into speeding up this UPDATE.

I did notice that performing UPDATEs of this sort on an InnoDB table with 300,000 rows started to get slow (roughly .24 seconds for me).
Changing the table engine back to MyIsam seemed to speed it up (.17 seconds). I think this is because of the number of indexes on the table, and InnoDB isn't optimized for that.
Once in MyIsam, I checked how FULLTEXT would perform, the results were over 1 second.
I reverted back to the current INDEX and reduced the key size by half. The query now took about .01 second.

This seems to be an acceptable increase to me, although it means some links won't be updated correctly if they don't differ in the first 125 characters. Perhaps this is an acceptable loss of functionality for the performance gain. Plus it can be worked-around by using a SELECT, check for match in PHP, UPDATE method.

To slow the growth of the size of vault_link, auto-links should not be cached, only intentional links.

In order to avoid similar problems scaling categories, articles, protection, likewise changes should be made to those tables. Also, the type index on the vault_link tables are not optimized. Should change to using content-type IDs to significantly reduce the key size.