Hi Ged,

The questions you're asking are in the direction of operational management of 
your mangolia setup. They are good questions, and I don't know if there is a 
perfect answer - it depends on your operations team, server infrastructure, 
etc...

For the Jackrabbit files, I think a good approach is to use a "generic" file 
that has variables in it. This file can be part of the deployed webapp. The 
variable values can be defined differently for each server using a 
magnolia.properties config file. I find it best to keep this .properties file 
outside the webapp, e.g. it isn't part of the deployment, it is part of the 
server setup. tomcat/conf can be a natural place to store it. You can define 
where to find it to magnolia using a -D parameter.

In this way all your nodes use the same jackrabbit configuration, but with 
different parameters like database host or schema name.

Regarding mysql setup, you have the full range of options: separate servers, 
separate databases, or different prefixes within the same database. Personally 
I don't see the advantage of putting everything in the same database, but maybe 
there is a good reason to do so.

Backing up your magnolia instances is a separate problem again. Really, a 
Jackrabbit Repository has to be stopped to guarantee a consistent backup at the 
database/datastore level. This means that you have to shut down the magnolia 
instance using it if you want to create a backup at the database level.
Some ideas for dealing with this:
1) some people back up on the JCR level rather than the database level, by 
using the JCR export functions. This then does not require a magnolia shutdown.
2) you can consider not backing up your public nodes, or at least not 
regularly. This is especially true if you have multiple public servers. If you 
have a fast way to restore a "naked" public node, the data can then be restored 
by publishing from the author instance (using the synchronization module, or 
manually).
3) and for your author instance, it is usually ok to shut it down at night in 
order to create a consistent backup...

If you are running a lot of magnolia instances, it really pays to take the time 
to think about these issues, and the management of the servers. By using 
virtualization or containerization, separating the per-node configuration from 
the webapp, and automating deployments you can really save a lot of time and 
effort in a large installation.

Regards from Vienna,

Richard



> -----Ursprüngliche Nachricht-----
> Von: [email protected] [mailto:dev-list-owner@magnolia- 
> cms.com] Im Auftrag von Gediminas Zalys (via Magnolia Forums)
> Gesendet: Samstag, 20. August 2016 08:17
> An: Magnolia Dev List
> Betreff: [magnolia-dev] Re: Problem with imaging module on clustered 
> environment
> 
> Many thanks for your support Richard!
> 
> I feel that derby is not a wise choice for production systems, so ill 
> leave this option out.
> 
> I am slightly concerned in regards to managing this setup.
> Lets say i have 10 nodes running magnolia public instances. This means 
> i will need 10 jackrabbit files pointing to different mysql databases.
> And also what about backups? backing up that many databases will 
> surely eventually create inconstancies.
> 
> feels to me that data will end up all over the place.
> 
> maybe there is a way to say use one jackrabbit file, that points to 
> one DB, however create tables with different prefixes, i.e node1_ mgnlVersion 
> etc?
> 
> Thanks again for your help,
> Ged
> 
> --
> Context is everything: http://forum.magnolia-
> cms.com/forum/thread.html?threadId=c9a18b1f-e47a-4d11-9c15-
> 448c5e14a519
> 
> 
> ----------------------------------------------------------------
> For list details, see: http://www.magnolia-cms.com/community/mailing-
> lists.html
> Alternatively, use our forums: http://forum.magnolia-cms.com/ To 
> unsubscribe, E-mail to: <[email protected]>
> ----------------------------------------------------------------



----------------------------------------------------------------
For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------

Reply via email to