Home › Forums › Product Support Forums › Ajax Search Pro for WordPress Support › Indices disappear after database migration
This topic contains 15 replies, has 2 voices, and was last updated by qwerty389 1 week, 3 days ago.
- AuthorPosts
- March 18, 2023 at 2:34 am #41853
We just migrated to a new db server at a new AWS instance at a new IP but noticed that all the indices for Ajax Search Pro are gone. How do we restore all the indices?
March 18, 2023 at 2:34 am #41854You cannot access this content.March 18, 2023 at 11:22 am #41856If you deactivate/activate the plugin it will check for the indices and create them if needed. That will very likely solve the issue.
If not, then you can try this:
Best,
– Deactivate the plugin
– Delete the wp_asp_index database table
– Activate the plugin again
– Reindex the contents
This process should create the index table from scratch, and will include the fresh indexes.
Ernest Marcinko
If you like my products, don't forget to rate them on codecanyon :)
March 18, 2023 at 12:58 pm #41857You cannot access this content.March 18, 2023 at 1:03 pm #41858Oh wait, I thought you meant the actual table indexes on the database level were not transfered to the new database.
If it took you 12 hours, that could mean that the counting process simply fails and reports back 0. In MySQL/MariaDB databases counting large number of rows can timeout very easily – it is a known flaw. You probably have multi million rows and that explains it.
Your data is very likely completely fine if you migrated, the counter is only reporting the incorrect numbers.
Best,
Ernest Marcinko
If you like my products, don't forget to rate them on codecanyon :)
March 18, 2023 at 3:07 pm #41859You cannot access this content.March 18, 2023 at 3:12 pm #41860You cannot access this content.March 18, 2023 at 3:16 pm #41861You cannot access this content.March 18, 2023 at 4:22 pm #41868That could indicate a database related issue then. Just to be sure, check if the index table is indeed enabled.
I strongly suggest running a database repair and table optimize queries on the whole database to make sure the data was correctly imported and it’s not fragmented. 15 million rows is a lot, but not tragic. Fragmentation can cause a huge memory issue with the actual table index structure on the database level.
Best,
I would also suggest looking at the server memory and space usage, just to make sure it has enough resources.
Ernest Marcinko
If you like my products, don't forget to rate them on codecanyon :)
March 19, 2023 at 4:07 am #41876Actually, i don’t have 15 mil rows. I have like 700k custom posts.
Here’s what I did so far,
* Click Delete Index Table button on your index table page on WP admin
* “Initializing…..” text appears and lingers for 1.5 hours.
* Finally I refresh the page but WP admin is not reloading…browser spinning and “Waiting for mysite.com….” appears on bottom left of browser. Stays for like 10 minutes and I give up.
* Open a new tab and enter WP admin. Success. But when I clicked on Ajax Search Pro menu on WP admin, again, it hangs…..spinning.
* Finally I went to deactivate your plugin. But when reactivating, the screen just hangs there – browser spinning and spinning.So, I don’t know what I should do now. I can’t access your plugin at all. I’m hoping for a better solution than just a simple REDO everything from scratch.
Should I just go to my DB and empty the wp_asp_index table directly?
March 19, 2023 at 11:40 am #41879By 15 million rows I meant the index table size.
Okay, this sounds like a serious issue with the actual database, I suspect fragmentation or data corruption. I strongly recommend doing table repair commands, checking the memory usage and the available space for the database.
It might be the best to completely delete the wp_asp_index table, deactivate and re-activate the plugin so it is recreated automatically, then doing a full database repair, as well as optimize table commands on all of the database tables. Those are crucial. There is no other reason for the plugin not to work on this server, if it worked just fine on the other – unless there is an underlying issue on the database/server layer.
Best,
Ernest Marcinko
If you like my products, don't forget to rate them on codecanyon :)
March 21, 2023 at 2:35 pm #41911You cannot access this content.March 21, 2023 at 2:37 pm #41913You cannot access this content.March 21, 2023 at 4:47 pm #41916What will happen if I accidentally hibernated my PC while indexing? I just did that
March 22, 2023 at 11:28 am #41919Nothing will happen if you hibarnate, you can click continue and that’s it.
1600 items in 10 hours? There is something very wrong with the database there. I just tested a single core virtual machine with 512MB of ram with 50 000 items, and it indexed in like 45 minutes and almost 0 CPU load, that should be a piece of cake for that machine.
The server specification is definitely all right, that is a super high specification for such small amount of data.Do you have any strong data replication or data restoration service running on that server? I mean a service which lets you roll back to any point in time on your database?
Best,
That could explain the problem, as it has to store a a lot of redundant data before every single database row insertion. The plugin tries to insert thousands of rows and the server might be trying to remember and log all of the changes and it basically kills the CPU.
Ernest Marcinko
If you like my products, don't forget to rate them on codecanyon :)
- AuthorPosts
You must be logged in to reply to this topic.