Configure Artifactory HA to Use PostgreSQL Database in HA

Available from Artifactory 7.31.10.

You can run an external PostgreSQL database in high availability for increased resiliency (available from Artifactory version 7.31.10 and Postgres 13). For information on setting up PostgreSQL database in high availability mode, see High Availability in PostgreSQL Database.

Stop the Artifactory service.

Edit the system.yaml file to update the following values.

Note

Because Artifactory uses multiple drivers and you need to configure the connection strings for these separately.

The url field under the shared database section in the following format.

jdbc:postgresql://<PostgreSQL Database 1 URL>,..., <PostgreSQL Database N URL>/artifactory?targetServerType=primary

The url field under the metadata database section in the following format.

jdbc:postgresql://<PostgreSQL Database 1 URL>,..., <PostgreSQL Database N URL>/artifactory?target_session_attrs=read-write"

The following sample shows an example system.yaml file configuration.

shared:
  logging:
  ...
  database:
    allowNonPostgresql: false
    type: postgresql
    url: "jdbc:postgresql://17.21.0.2:5432,17.21.0.3:5432/artifactory?targetServerType=primary"
    driver: org.postgresql.Driver
    username: "artifactory"
    password: "password"
artifactory:
  Database:
...
frontend:
...
access:
...
metadata:
  database:
    type: postgresql
    url: "jdbc:postgresql://17.21.0.2:5432,17.21.0.3:5432/artifactory?target_session_attrs=read-write"
    driver: org.postgresql.Driver
    username: "artifactory"
    password: "password"
...

Start the Artifactory service.

Best Practice

To avoid latency in the Artifactory database transactions, you should declare replication as asynchronous in PostgreSQL HA. Replication lag depends on several factors including setup, network latency and database load. In addition to declaring asynchronous replication, to minimize the potential for data loss in case of failover, you should also monitor the replication lag and takesteps to avoid it. For specific information about how to do this, read about the replay_lag column, which approximates the delay before recent transactions become visible to queries.