Hi, me and Alessio are looking for a way to perform a live backup and restore of the GeoServer data directory without having to stop the instance.
Now, there is a number of issues to be faced but let me start with the major one: concurrent catalog modifications. During a backup nothign should be able to write, during a restore nothing should be able to even read. Actually the same problem occurs in GeoServer today in other occasions and I have the impression it's also the cause of those null pointer exceptions that are getting reported on the user list: - concurrent admin operations, either via GUI or REST (hello Justin and his multi-admin proposal) - concurrent reload/reset operations (eventually with other stuff going on) Now, if every single configuration bit was in a db and we had a transaction api for config changes this would not be a problem, but we're not there yet, and that would require a very significant investment that we don't have the funding for, so we are going to propose a simpler solution instead. What about a global configuration read/write lock? GS 1.7 used to have it. At the very least GUI and REST config would take a read lock when accessing configuration data, and a write lock every time they are about to write on the catalog, to protect the whole sequence of oprations and the associated side effects happening via catalog/configuration listeners. Reload would get a write lock, reset a read one. The backup operation (probably implemented via rest) a read one, the restore one a write one. OGC operations might also get a read lock, that would prevent at least part of the reasons why the stores die on their back while they are running (the other would be the lru cache pushing out the stores, that's another story). However I'm concerned that a long WFS download or a long WPS request might make the configuration untouchable for a very long time. So we might want to let these fail in face of configuration changes. Btw, backup wise we'd like to backup the entire data directory (data, fonts, styling icons and whatnot included), and restore would wipe it out, replace it with the new contentes, and force a reload. GWC is actually putting a wrench in this plan since it keeps a database open, wondering if there is any way to have it give up on the db connections for some time? As an alternative we could have the backup and restore tools work on selected directories and files, configurable in the request (which could be a post) and with some defaults that only include the gwc xml config file, I guess GWC would just reconfigure itself after the reload and wipe out the caches, right? Anyways... opinions? Other things that might go pear shaped that we did not account for? Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
