Hi,
We have an Omeka Classic installation with a very large database - about 2.1 GB in size (and no, it’s nothing to do with sessions - it’s just a massive data set with 10,000+ items created from scanned documents). Trying to run the Omeka 3.2 upgrade on sites with just 500 MB databases runs inordinately long to the point that the web browser times out, so I’m not very keen on trying to run the upgrade on that giant site.
Is there any way to trigger the database upgrade from the command line, so that I can simply start it as a background process and let it run however long it needs to run (I’m guessing it will take over a half-hour)? I thought there was a way to do this, but my searches have not turned up anything pointing me to the magic command to run at the command line to trigger the database upgrade. (I was hoping for something along the lines of using Drush to upgrade a Drupal site database from the command line).
If there’s no command line option, is there any advice for making this massive site upgrade go a little smoother? It seems like something in the 3.2 upgrade wants to really rework some of the database tables, as I don’t recall having this problem with the smaller sites in the past.
Thanks and Cheers,
K
I can’t say for sure how long the upgrade would/should take as it depends on the sizes of your tables, what resources your database server has, and so on. In general I’d say it shouldn’t be anywhere near 30 minutes, though. Typically it’s a number of seconds.
If you’ve run the upgrade before, you can check the schema_migrations table to see which steps of the upgrade have completed, if any. The 3.2 upgrade has 5 steps, and each is recorded as a separate number in the schema_migrations table when it’s done, in order (you’ll have many lower/older numbers but these should be the highest, the only ones starting with 2024):
20240709181800 adds an index on the element_texts table20240713184500 adds indexes to the items and collections tables20240713211400 makes several changes to the sessions table20240717204800 makes changes to the users table20240917160000 adds a column to the files table
After you attempt the upgrade, are any of these recorded in the schema_migrations table? Looking at which are would identify which step is taking too long. Depending on which, if any, steps are finishing, you might be able to just run the upgrade multiple times to complete the whole thing, as any step that’s completed and recorded in that table won’t be re-run.
There’s no command-line tool for running the upgrade outside the web context. It’s possible to just do the migration steps manually by connecting to the database, and manually record the migrations as complete in the schema_migrations table, though… the migrations for 3.2 are all simple ALTER statements.
Okay, I see the problem now. I didn’t bother to look closely at the sessions bug (the one where sessions never get deleted from the sessions table) because our sites haven’t had hardly any logins in years - they’re being maintained as archives of the materials assembled by past researchers. However, it turns out that Omeka creates a session for every anonymous visitor - not just ones who log into the site. So, as you can imagine, that sessions table was huge (the smaller sites had ~150,000 session records, and the site I was writing about above had ~1,700,000 session records in it!) That’s got to be the culprit: doing any kind of ALTER statement on a table with that many records is going to be time consuming. The solution, of course, is to TRUNCATE the sessions table before you try to do the Omeka 3.2 upgrade.
Yeah, OK. That definitely tracks, and I think you saw the other thread where that came up as a culprit in a slow upgrade.
As was also mentioned at some point in that other thread, 3.2 includes a fix that makes the sessions table get periodically cleared as intended even on servers that otherwise disable that clearing process.