Project

General

Profile

Bug #3811

Spatial caches should be backed up and restored

Added by Michael Daigle over 11 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Normal
Category:
metacat
Target version:
Start date:
02/06/2009
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
3811

Description

Right now it takes over 40 minutes for the spacial caches to be generated every time metacat is upgraded on knb. These files should either be located outside of the webapps directories (which may not be possible) or the files should be backed up and restored at update time.

History

#1 Updated by Matt Jones over 11 years ago

Matt Perry and I discussed having them be located outside of the knb context dir many times. We both agreed it was a good idea, but he said it was difficult because GeoServer wasn't very flexible with respect to where the indices were stored. Reloading each time seems like a waste. If you can't relocate the data to /var/metacat/spatial or some such, then I think your backup/restore during upgrade is an excellent idea.

#2 Updated by Matt Jones over 8 years ago

Decided that its best to move these files to /var/metacat by default.

#3 Updated by ben leinfelder over 8 years ago

If someone wants to put the spatial cache in /var/metacat they will have to do it manually, then configure metacat (which reconfigures geoserver) to point to that directory.

The current default (because this is where all the required files are located in the shipped war) is: {tomcat}/webapps/knb/spatial/geoserver/data

There are MANY supporting files and subdirectories in that "data" directory, including the Metacat-specific shapefiles.
The entire structure must be maintained when copied/moved to /var/metacat

Before upgrading, we should backup the files in "spatial/geoserver/data/metacat_shps", then deploy the new Metacat.
Then copy the new data directory to var/metacat/geoserver.
Then copy the backup metacat_shp files into the new /var/metacat/geoserver/data directory.
Then configure Metacat to use that directory for geoserver.

#4 Updated by ben leinfelder over 8 years ago

The final step in the process should be to NOT regenerate the spatial cache during 2.0 configuration.

#5 Updated by Redmine Admin about 7 years ago

Original Bugzilla ID was 3811

Also available in: Atom PDF