Sorry, I forgot to include my plan (for easier feedback). From the wiki documentation, it sounds like I want to:
1) Replace all instances of DerbyPersistenceManager with PostgreSQLPersistenceManager. 2) Leave LocalFileSystem alone; we're running nix in Production, so it should be fast enough. We don't need any special fs/disks for search indexes 3) Delete the "<DataStore class="org.apache.jackrabbit.core.data.FileDataStore"/>" config, so that Jackrabbit defaults large BLOBs to the PersistenceManager (PG) so we have one point of backup. On Mon, Aug 9, 2010 at 4:31 PM, Robert Campbell <[email protected]> wrote: > Right now we're using a default RAR distribution in JBoss which our > webapp connects to over JNDI. When the repository is booted for the > first time, it creates a default repository.xml, which contains: > > <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem"> > <param name="path" value="${rep.home}/repository"/> > </FileSystem> > > in the Repository, Versioning, and Workspace tags. There is also: > > <PersistenceManager > class="org.apache.jackrabbit.core.persistence.pool.DerbyPersistenceManager"> > <param name="url" value="jdbc:derby:${wsp.home}/db;create=true"/> > <param name="schemaObjectPrefix" value="${wsp.name}_"/> > </PersistenceManager> > > in the Versioning and Workspace tags, and: > > <DataStore class="org.apache.jackrabbit.core.data.FileDataStore"/> > > in the Repository tag. > > It's not clear to me how these entries interact, even after reading > the Wiki article on persistence. Do they mean that Jackrabbit persists > _everything_ to Derby, which then uses the local file system? Or - as > I suspect - does it mean that actual binary files/blobs are stored as > files (FileDataStore) on the local file system, but that version and > workspace data is stored in Derby? > > I'm trying to understand step by step how we can move _everything_ > over into Postgres. We're doing this because our operations folks have > heavily invested in PG knowledge/infrastructure/backup systems/etc. > We'd like the ability to flip the switch on our Postgres backup > solutions and have our entire repo backed up live (no downtime to the > app). > > Thank you, > > Rob Campbell >
