Managing Catalogs : Securing Catalogs : Database Mirroring
   
Database Mirroring
Mirroring enables you to use the Cumulus database as a ‘caching engine’ that for example saves data into an external SQL-compatible database. In this role, a Cumulus catalog serves as a permanent cache.
Saving the data in an SQL database offers the advantage that any SQL analyses are possible. However, changes made to the catalog data from within the SQL database are not copied back to Cumulus and therefore should not be made. When a mirrored catalog is rebuilt, the SQL database serves as master. Each catalog requires its own SQL database.
Canto provides a plug-in that includes support for different SQL database systems. (The support for Oracle is available with Cumulus Enterprise only.) If you require support for another database system, contact Canto. Each database system requires it own JDBC driver. The JDBC drivers for most systems are pre-installed; except one: The official JDBC driver for MySQL must be downloaded from the MySQL website (www.mysql.com). Currently the driver is available under:
http://dev­.mysql.com/downloads/­. The driver must be copied to the appropriate subfolder of the esp folder in your Cumulus Server installation folder. The subfolder dbmirror contains a folder named lib. Copy the downloaded driver into this lib folder (e.g to ..esp/dbmirror/lib).
Cumulus catalogs of a second Cumulus Server installation can also serve as mirroring target databases. For more information, see “Using Cumulus Catalogs as Mirroring Target Databases” .
A catalog is set up for mirroring on the Mirroring tab of a catalog’s settings ( Cumulus /  Edit > Preferences > Catalog Settings.)
PRECONDITIONS: To set up a catalog for mirroring, you must have the appropriate Administrator permissions (Permissions > Administrator Permissions > Manage Mirroring (option for the Modify Catalog Settings permission.)
If you want to use mirroring, you should activate it directly after you have installed Cumulus, or after new catalogs are created. Note that once you activate the mirroring option for a catalog, the initialization can take some time, depending on the size of the catalog. (And the process cannot be paused – if interrupted, it must be started from the beginning.)
NOTE: Never set up multiple catalogs for mirroring at once!
Start the process for a subsequent catalog only after the previous catalog has been completely processed.
If mirroring is activated, the events to be saved in the SQL database are written in a task queue. For safety reasons, each task is saved in a temporary internal file. This file is deleted after the task is successfully processed. Storage locations for the queues and safety files are defined in the server.xml file found in the conf folder in the Cumulus Server installation folder. You define the basic or “root” folder for the files. This folder will house the subfolders for the queues—one subfolder for each queue (named as the unique identifier given for the queue). The default storage location is the Cumulus Server installation folder. If you want to use mirroring, you should define the storage location directly after you install Cumulus. The collection of these files can become quite large, requiring ample storage space. The required space depends on the SQL database system and the amount of data stored in each asset. There is a difference between the initial process and normal operation. As rule of thumb: twice the size of the mirrored catalog file is recommended.
Note that if you have a catalog mirrored to a SQL database, you should back up the target database and not the original Cumulus catalog. For information on how to repair a mirrored catalog using the target database, see “Repairing Catalogs” .
NOTE: Mirroring catalogs employing Solr index
When mirroring a catalog that uses the Solr index, the mirrored catalog uses the same Solr instance as the original catalog. When using the mirrored catalog, it might be possible that the Solr indexes need to be rebuilt.