Difference between revisions of "Upgrading from 3.1"
(→Minimising downtime) |
m (add to category:upgrading and out of date) |
||
| (5 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | One of the core parts of upgrading from 3.1 is converting all database tables and data to the utf8 charset (previous version of EPrints used latin1). There are a couple of pitfalls in this process - the following tips are from the EPrints Services team, after carrying out many upgrades to 3.2. Please note that you follow this advice at your own risk. | |
==Avoiding subject__index_grep key length error== | ==Avoiding subject__index_grep key length error== | ||
| Line 7: | Line 7: | ||
DBD::mysql::db do failed: Specified key was too long; max key length is 1000 bytes at /opt/eprints3/perl_lib/EPrints/Database.pm line 3213, <STDIN> line 1. | DBD::mysql::db do failed: Specified key was too long; max key length is 1000 bytes at /opt/eprints3/perl_lib/EPrints/Database.pm line 3213, <STDIN> line 1. | ||
| − | To avoid this error | + | To avoid this error clear the tables before running ''bin/epadmin upgrade'': |
| − | + | delete from subject__index_grep | |
| − | + | delete from subject__rindex | |
Then reindex when ''bin/epadmin upgrade'' has completed: | Then reindex when ''bin/epadmin upgrade'' has completed: | ||
| Line 20: | Line 20: | ||
Whilst ''bin/epadmin upgrade'' is running, your repository will be offline. | Whilst ''bin/epadmin upgrade'' is running, your repository will be offline. | ||
| − | + | If you have a LARGE repository the conversion to utf8 can take a LONG time (12+ hours). However some of the tables are volatile (ie. the data can be generated) so you can reduce downtime by clearing these tables beforehand, and then regenerating the content afterwards (whilst your repository is back online). | |
You only really need to consider this if your eprint__rindex table contains MILLIONS of rows. | You only really need to consider this if your eprint__rindex table contains MILLIONS of rows. | ||
| Line 27: | Line 27: | ||
DELETE FROM eprint__rindex; | DELETE FROM eprint__rindex; | ||
| − | |||
After running ''bin/epadmin upgrade'' and getting your repository back online: | After running ''bin/epadmin upgrade'' and getting your repository back online: | ||
bin/epadmin reindex ARCHIVEID eprint | bin/epadmin reindex ARCHIVEID eprint | ||
| − | |||
| − | + | Note that your search won't be at full capacity until the indexes are fully regenerated, but we have found that getting the repository back online ASAP is more desirable so worth the trade off. | |
| + | |||
| + | ==Post-upgrade: Migrating Apache Configuration== | ||
| + | |||
| + | See [[ApacheConfigMigration]] | ||
| + | |||
| + | [[Category:Upgrading]] | ||
| + | [[Category:Out of Date]] | ||
Latest revision as of 05:55, 30 August 2018
One of the core parts of upgrading from 3.1 is converting all database tables and data to the utf8 charset (previous version of EPrints used latin1). There are a couple of pitfalls in this process - the following tips are from the EPrints Services team, after carrying out many upgrades to 3.2. Please note that you follow this advice at your own risk.
Avoiding subject__index_grep key length error
When converting subject__index_grep and subject__rindex to utf8, bin/epadmin upgrade will generate an error:
DBD::mysql::db do failed: Specified key was too long; max key length is 1000 bytes at /opt/eprints3/perl_lib/EPrints/Database.pm line 3213, <STDIN> line 1.
To avoid this error clear the tables before running bin/epadmin upgrade:
delete from subject__index_grep delete from subject__rindex
Then reindex when bin/epadmin upgrade has completed:
bin/epadmin reindex ARCHIVEID subject
Minimising downtime
Whilst bin/epadmin upgrade is running, your repository will be offline.
If you have a LARGE repository the conversion to utf8 can take a LONG time (12+ hours). However some of the tables are volatile (ie. the data can be generated) so you can reduce downtime by clearing these tables beforehand, and then regenerating the content afterwards (whilst your repository is back online).
You only really need to consider this if your eprint__rindex table contains MILLIONS of rows.
Clear these tables before running bin/epadmin upgrade:
DELETE FROM eprint__rindex;
After running bin/epadmin upgrade and getting your repository back online:
bin/epadmin reindex ARCHIVEID eprint
Note that your search won't be at full capacity until the indexes are fully regenerated, but we have found that getting the repository back online ASAP is more desirable so worth the trade off.
