Creating a new public instance

Multiple public instances are useful in many circumstances, including:

• Serving specific content of a single site to separate public instances. For example, /sports to one subscriber and /news to another.
• Managing multiple sites in the author instances but publishing each to an individual public instance located on servers in different geographic locations for example.
• Restoring corrupted data to an additional public instance.
• Adding a public instance to cope with unexpected high load on the public site.
• Having additional public instances for load balancing purposes to ensure high-availability.

Magnolia offers numerous ways to set up an additional public instance. The best practice depends on each use-case. The fastest and simplest way is to copy an existing, working public instance provided you have one. Before doing this, be sure to back up both the webapps folder and the database as there is always the risk of corrupting the existing instance.

Creating a new public instance

1. Duplicate the existing public instance. Copy the webapps folder and database of an existing public instance. The standard installation uses an embedded Derby database so it is not necessary to locate and copy the database in this instance.
   
   
   
   
2. Rename the duplicate folder. The duplicate is a clone of the original instance and the content of some folders are essential to the new instance, but some may be deleted to clean up the instance:
   
   • /cache contains cached entries of the original instance and may be deleted.
   • /docroot contains the Tomcat docBase static resources and should not be deleted.
   • /logs contains log entries of the original instance and may be deleted. The folder with empty log files will be recreated during server startup.
   • /META-INF is a mandatory folder and should not be deleted.
   • /repositories can be reindexed by deleting the index subfolders in each /repositories/magnolia/workspaces/* folder but the rest of the folders should remain intact.
   • /templates contains static resources and should not be deleted.
   • /tmp is a temporary folder which Tomcat or Jackrabbit uses for its processes during export/import and may be deleted.
   • /WEB-INF is a mandatory folder and should not be deleted.
     
     
3. Edit the database connection information. In the standard installation connection information is already set for Derby so you do not need to edit any of the files listed below.
   
   Jackrabbit configuration files are in /webapps/magnoliaPublic/WEB-INF/config/repo-conf. Magnolia ships with four options for persistent storage: Derby, Ingres, MySQL and in-memory.
   
   The MySQL InnoDB storage engine is supported by Magnolia, the MyISAM engine is not. InnoDB is the default engine in MySQL 5.5 and later.
   
   You can also include a custom XML configuration file for your database. The value of the magnolia.repositories.jackrabbit.config parameter in webapps/magnoliaPublic/WEB_INF/config/default/magnolia.properties needs to correspond to the selected XML configuration file. Please note that connection information should to be added twice, for workspace and versioning in all XML files. For more information see Content storage and structure, Configuration and Setting up a Jackrabbit persistence manager.
   
   
   
   Individual workspace XML files are in /webapps/magnoliaPublic/repositories/magnolia/workspaces/*.
   
   
   
   
4. Start Magnolia and run the Web update for the new public instance.
   
   
   
   
5. On the author instance, configure a new subscriber in Configuration > Subscribers at /server/activation/subscribers.
   
   

Other methods and modules

Other methods to create new public instances or situations where an additional public instance is useful include:

• Using the Restore function in the Backup module, which is available to EE users. This creates a new public instance for the restored data automatically. For CE users, backup and restore JSP scripts are available on the wiki.
• Using the Synchronization module  to create new public instances without shutting down existing ones.
• Programmatically writing a cloneInstanceCommand.
• Various options to repair a broken public instance using a second instance discussed in How to replicate a public instance.
• Using Jackrabbit DataStore for blobs in special cases.