Skip to end of metadata
Go to start of metadata
Table of Contents
Expand all   Collapse all

Changing Storage Overview

Artifactory comes with a built-in Derby database that can be reliably used to store data for production-level repositories (up to hundreds of gigabytes).

Artifactory's storage layer supports pluggable storage implementations, allowing you to use the most supported and popular databases:

You can work in two different modes:

  • Metadata in the database and binaries stored on the file system (default and recommended)
  • Metadata and binaries as BLOBs stored in the database

PostgreSQL support will be added in a future minor release

 

Once-And-Only-Once Identical Content Storage

Artifactory stores identical binary files only once. When a new file about to be stored in Artifactory is found to have the same checksum as a previously stored file, Artifactory does not store the new file content, but creates a link to it in the metadata of the newly deployed file.

This principle applies regardless of which repository and path artifacts are deployed - you can deploy the same file to many different coordinates, and as long as identical content is found in the storage, it is reused.

Changing the Storage Type Used

Changing the storage does not automatically transfer your data to the new storage! Read below on backing-up and restoring your data before and after the change.

Removing the old $ARTIFACTORY_HOME/data folder

If you have previously run Artifactory with a different storage type you must remove (or move-aside) the existing $ARTIFACTORY_HOME/data folder, or Artifactory continues to use part of the old storage definitions and will fail to start up (not found exceptions are displayed on startup).

Starting with a clean or no $ARTIFACTORY_HOME/data folder fixes this.

Backing up your existing installation

When changing the storage type for an exiting installation you must import the old Artifactory content and configuration from backup. Make sure to back-up your older Artifactory system before using a different storage type.

If the file $ARTIFACTORY_HOME/etc/storage.properties does not exist Artifactory automatically generates the file with the default settings for a Derby database.

To change the storage used by Artifactory:

  1. Create a database instance to which Artifactory connects. 
  2. Create an Artifactory user for this database and grant full permissions to this user (database tables are auto-created).
  3. Download the appropriate JDBC driver and install it in your server's shared lib directory ($ARTIFACTORY_HOME/tomcat/lib).
  4. Copy the relevant database configuration file from $ARTIFACTORY_HOME/misc/db to $ARTIFACTORY_HOME/etc/storage.properties
  5. Change the database details in the storage.properties file to match your database.  See below for comprehensive details of each parameter.

When Artifactory is Deployed as a WAR

If you Deployed Artifactory as a WAR and have not specified a location for the $ARTIFACTORY_HOME directory, it is auto-created after it is run for the first time by Artifactory under '$USER_HOME/.artifactory'.

To use the bundled configuration files for common storage types, you may want to copy the etc/misc folder from the Artifactory distribution to your $ARTIFACTORY_HOME/misc.  

The Bundled Storage Configurations

For each of the supported databases you can find the  <database>.properties file inside $ARTIFACTORY_HOME/misc/db as listed below:

  • derby.properties
  • mssql.properties
  • mysql.properties
  • oracle.properties

Each file contains the mandatory parameters and definitions to be configured to work with your database.

  • binary.provider.type (If no parameter is set filesystem is used by default)
    • filesystem (default)
      This means that all the metadata is stored in the database and the binaries are stored in the file system $ARTIFACTORY_HOME/data/filestore (by default).
      This setting typically yields the best performance with large repositories.
    • fullDb 
      All the metadata and the binaries are stored as BLOBs in the database 
  • pool.max.active 
    The maximum number of pooled database connections (100 by default).
  • pool.max.idle
    The maximum number of pooled idle database connections (10 by default).
  • binary.provider.cache.maxSize
    If fullDb mode is being used, this value (in bytes) determines the maximum cache size to use on the system for caching BLOBs. 
  • binary.provider.filesystem.dir
    If filesystem mode is being used, this value determines the location of the binaries ($ARTIFACTORY_HOME/data/filestore by default).

If using filesystem, for raw Artifactory data backup, the folder $ARTIFACTORY_HOME/data/filestore must be backed-up in parallel with a database dump since both are required. The database must be dumped first.

This does not impact Artifactory's own backup system which is storage-agnostic.

Accessing a Remote Database

To avoid network latency issues when reading and writing artifacts data, it is highly recommended to either create the database on the same machine on which Artifactory is running or on a fast SAN disk.

This is critical if the files are served from database BLOBs and the file system cache size is low (relevant only to fullDb).

 

 
  • No labels