Overview: Clustering and Jackrabbit
Artifactory uses the Java Content Repository (JCR) standard for storage with the Apache Jackrabbit implementation. Jackrabbit has out of the box support for full HA cluster of 2 (or more) active/active servers. These servers run in parallel, notifying each other about changes in a fully transactional way using journaling. For that, the two servers need to work with a common database.
The default installation of Artifactory comes with an embedded Derby database, which cannot be accessed by multiple processes. However, starting with version 1.3.0 (beta-6 and above), Artifactory supports MySql out-of-the-box (in theory it should be possible to configure Artifactory to run on any JDBC compliant database), making it easier to set up a Jackrabbit cluster.
That being said, there are currently a couple of areas in Artifactory that are not ready to be clustered in an active/active mode (the Jackrabbit way). These are:
- Internal (scheduled) services that cannot run in parallel on the same storage and need to synced.
- The main configuration file (
artifactory.config.xml) is stored on disk and does not propagate changes automatically between nodes (This does not affect security changes, which are fully propagated).
Due to the current constraints, it is recommended to run Artifactory in an active/standby mode where the two instances share a single MySql database and the same
artifactory.config.xml file. There are Artifactory users using this setup successfully in production (even with Derby, BTW). Since
artifactory.config.xml rarely changes after the initial setup and since most changing parts - security definitions and repository content - come from the database, this proved to be a very practical solution.
Future versions of Artifactory will store/replicate all configuration in JCR and fully take advantage of Jackrabbit's native active/active cluster support.