Aramaech Posted June 5, 2017 Posted June 5, 2017 Mugenfreeforall.com has been dealing with this bug for quite a long time at this point. This thing has resisted the efforts of IPS tech support, Bluehosts tech support, our on-staff coder and myself. Basically what happens is the search index table randomly corrupts after about a week, and the search index needs to be rebuilt.• The symptoms are: Status updates will post twice, or more. New forum posts will post anywhere between 2 and 10 times / copies of themselves in a row. Error 144 on view member profiles. Some posts inaccessible. Central error returned: Search index table is marked as crashed.• What worked before: After the first few months of dealing with this thing, our on-staff coder suggested converted all of the tables in our database to InnoDB format. IPS uses MyISAM by default, but after some reading and conversation with tech support, InnoDB seemed better faster and like it wasn't going to cause any problems with IPS. Worked great, solved the problem, for about 2 months. • What eventually stopped that from working: We crashed right after the IPS 4.1.1.91 update. The sites html was there, but all the css had gone and our site looked like something from 1996 on ie. So I ran the support tool in the AdminCP. It requested access to the database, and changed about half of our tables back to MyISAM format, including the search index table. Not only that, but the tables can no longer be converted back to InnoDB format. So now we're stuck with that bug again. Or as I like to see it, stuck with actually finding the source of the problem, rather than a fix for it.• Currently: Eventually we made our way out of that crash by installing the patch files provided by IPS for people experiencing issues with that upgrade. The patches got the site back up and running, for the most part. A lot of our pictures were gone, replaced with blue question blocks (never to return), and our database was/is half returned to MyISAM, but hey at least the site works now. Attempts to convert the tables back to InnoDB format result in the error: #1071 - Specified key was too long; max key length is 767 bytes So, there we have it. The bug persists. Optimal course = uncover source and resolve, find out if possible to convert all tables to InnoDB anyway, bc it's faster and more stable. Like I said, it's resisted the efforts of myself, my staff, the software and hosts tech support. I can answer questions with a moderate degree of understanding and I've taken screenshots, notes etc. Any help anyone would be willing to offer to this would be greatly appreciated!
Recommended Posts
Archived
This topic is now archived and is closed to further replies.