• Register
    • Help

    striker  0 Items
    Currently Supporting
    • Home
    • News
    • Forum
    • Wiki
    • Support
      • Manage Subscriptions
      • FAQ
      • Support For
        • VaultWiki 4.x Series
        • VaultWiki.org Site
    • What's New?
    • Buy Now
    • Manual
    • 
    • Support
    • VaultWiki 3.x Series
    • Bug
    • Database errors

    1. Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

      VaultWiki allows your existing forum users to collaborate on creating and managing a site's content pages. VaultWiki is a fully-featured and fully-supported wiki solution for vBulletin and XenForo.

      The VaultWiki Team encourages you to join our community of forum administrators and check out VaultWiki for yourself.

    Issue: Database errors

    • Issue Tools
      • View Changes
    1. issueid=1618 June 1, 2010 8:56 PM
      bigtree bigtree is offline
      Junior Member
      Database errors
      since rc3 I am experiencing database errors

      since rc3 I am experiencing database errors.
      Code:
      Database error in vBulletin 4.0.3:
      
      Invalid SQL:
      
      				UPDATE vault_link
      				SET targetid = 45020
      				WHERE namespace = 6
      					AND title_lower = 'preamp';
      
      MySQL Error   : Can't find record in 'vault_link'
      Error Number  : 1032
      Request Date  : Tuesday, June 1st 2010 @ 02:20:35 PM
      Error Date    : Tuesday, June 1st 2010 @ 02:20:36 PM
      Script        : http://recording.org/wiki/Preamp
      Referrer      : http://recording.org/pro-audio-gear/40460-focusrite-isa-828-focusrite-octpre-mk2-universal-audio-2-610-a.html
      IP Address    : removed for privacy
      Username      : Unregistered
      Classname     : vB_Database
      MySQL Version :
    Issue Details
    Issue Number 1618
    Issue Type Bug
    Project VaultWiki 3.x Series
    Category Performance
    Status Fixed
    Priority 2 - Fatal / Database Errors
    Affected Version 3.0.0 RC 3
    Fixed Version 3.0.1
    Milestone VaultWiki 3.0.5
    Software DependencyAny
    Users able to reproduce bug 0
    Users unable to reproduce bug 0
    Attachments 0
    Assigned Users (none)
    Tags (none)


    Page 1 of 2 12 Next LastLast


    1. June 2, 2010 12:48 AM
      pegasus pegasus is offline
      VaultWiki Team
      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.
      Reply Reply  
    2. June 5, 2010 5:29 PM
      pegasus pegasus is offline
      VaultWiki Team
      If you're still having problems, you'll need to drop the vault_link table and re-add it.
      Reply Reply  
    3. June 6, 2010 12:36 PM
      bigtree bigtree is offline
      Junior Member
      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.
      Reply Reply  
    4. June 6, 2010 12:47 PM
      bigtree bigtree is offline
      Junior Member
      Quote Originally Posted by pegasus
      If you're still having problems, you'll need to drop the vault_link table and re-add it.
      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?
      Reply Reply  
    5. June 6, 2010 6:01 PM
      pegasus pegasus is offline
      VaultWiki Team
      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.
      Reply Reply  
    6. June 6, 2010 6:44 PM
      bigtree bigtree is offline
      Junior Member
      So I should drop the table or dump the table?
      Reply Reply  
    7. June 6, 2010 7:06 PM
      pegasus pegasus is offline
      VaultWiki Team
      DROP it.
      Reply Reply  
    8. June 6, 2010 9:47 PM
      pegasus pegasus is offline
      VaultWiki Team
      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.
      Reply Reply  
    9. June 14, 2010 4:29 PM
      bigtree bigtree is offline
      Junior Member
      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?
      Reply Reply  
    10. June 14, 2010 4:46 PM
      pegasus pegasus is offline
      VaultWiki Team
      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?
      Reply Reply  
    11. June 14, 2010 5:14 PM
      bigtree bigtree is offline
      Junior Member
      I have no idea and this only started occuring after RC 1. I skipped RC 2
      Reply Reply  
    12. June 18, 2010 12:27 PM
      pegasus pegasus is offline
      VaultWiki Team
      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:
      Code:
      ALTER TABLE vault_link
      DROP INDEX title_lower,
      ADD INDEX title_lower ( title_lower ( 245 ) )
      Reply Reply  
    13. June 18, 2010 11:28 PM
      pegasus pegasus is offline
      VaultWiki Team
      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.
      Reply Reply  
    14. June 18, 2010 11:51 PM
      bigtree bigtree is offline
      Junior Member
      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.
      Reply Reply  
    15. June 19, 2010 1:21 AM
      pegasus pegasus is offline
      VaultWiki Team
      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.
      Reply Reply  
    Page 1 of 2 12 Next LastLast
    + Reply

    Assigned Users
    Loading Please Wait
    Tags
    Loading Please Wait
    • Contact Us
    • License Agreement
    • Privacy
    • Terms
    • Top
    All times are GMT -4. The time now is 6:27 PM.
    This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Learn more… Accept Remind me later
  • striker
    Powered by vBulletin® Version 4.2.5 Beta 2
    Copyright © 2023 vBulletin Solutions Inc. All rights reserved.
    Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2023 DragonByte Technologies Ltd.
    Copyright © 2008 - 2013 VaultWiki Team, Cracked Egg Studios, LLC.