Using Artifactory 6.x ?
JFrog Artifactory 6.x User Guide
Still using Artifactory 4.x ?
JFrog Artifactory 4.x User Guide
Have a question? Want to report an issue? Contact JFrog support
Artifactory HA is an Active/Active clustered installation of Artifactory that provides a full set of true High Availability features and is supported with an Artifactory Enterprise License.
For full details please refer to Artifactory High Availability.
Artifactory clustered Active/Passive architecture provides fast disaster recovery and can be implemented in one of the following two ways:
Using a fault-tolerant disk mounted on another machine allows for a very short MTR (Mean Time to Recovery) in case the "active" server goes down. If Artifactory is deployed on a NAS or SAN the "passive" machine can immediately mount the storage, bootstrap Artifactory from it and start accepting requests in place of the originally "active" machine that is has gone down.
To set this up quickly and efficiently, we recommend using the built-in Virtual Machine Failover feature offered by virtualization software providers as follows:
Create a VM image that runs the Artifactory startup script and mounts the auxiliary storage.
The storage should contain the full Artifactory installation along with the data in a location defined as $ARTIFACTORY_HOME.
Use the VM image on two Virtual Machines and have Artifactory running on one machine while the other machine is readily available as a failover target by the virtualization monitor.
If deployment on fault-tolerant storage, as described in the previous section, is not possible (or if redundancy is required), fault-tolerance can be achieved by correctly replicating the data folder to a warm standby server.
The setup of an up-to-date passive replication server for the active Artifactory server requires database replication and synchronization of file system directories.
To synchronize the data and configuration directories you need to run
This can be done by running the
rsync command on
$ARTIFACTORY_HOME while excluding the directories that are not required as follows:
For the above example the
rsync-excludes.txt file appears as follows:
rsync should be executed from the passive stand-by server
Database replication must run before executing
The procedure to synchronize a database varies between the different database vendors. Please refer to the relevant documentation for your specific database.
For example, instructions on how to synchronize with MySQL can be found in the MySQL documentation for How to Set Up Replication.
It is also possible to use a full dump/restore procedure on the database to synchronize the database and filestore state. In this case, we recommend that you perform the dump in a single routine along with
rsync (in case of File System Storage Types).
It is very important that the metadata stored in the database and the data stored on the file system are synchronized on the standby server.
A straightforward way to achieve this, is to make sure that the database synchronized is in a state that is prior to the file system (data/filestore) state.
This allows you to:
Since the sync operations are not atomic, there may be a gap between the data from
rsync and data from database replication.