Meet us at KubeCon + CloudNativeCon: Paris, France - March 19
Book Demo
Teleport logoTry For Free
Fork me on GitHub

Teleport

Database Access High Availability (HA)

  • Available for:
  • OpenSource
  • Team
  • Cloud
  • Enterprise

You can deploy the Teleport Database Service in a Highly Available (HA) configuration using two methods, both of which involve pointing multiple Database Service instances to the same database instance:

  • Deploying multiple Database Service instances with the same dynamic resource watchers.
  • Deploying multiple Database Service instances configured to proxy the same database instances.

Dynamic resource watchers

You can configure multiple Database Service replicas to watch for the same dynamic db resources.

To configure the Database Service to watch for dynamic resources, add a labels field to its resources configuration:

db_service:
  enabled: "yes"
  resources:
  - labels:
      "region": "us-east-1"

When you create a dynamic db resource, all Database Service replicas configured to watch that db resource's labels will proxy the corresponding database instance. For example, the db_service configuration above instructs the Database Service to proxy any db resource with the region:us-east-1 label.

When connecting, Teleport will randomly pick the Database Service instance to connect through to provide some load balancing. If the selected instance is down (e.g. in case of a data center outage), Teleport will try to connect via other instances.

For information on setting up dynamic database resources, see Dynamic Database Registration.

Static Database Service configuration

You can explicitly configure Database Service replicas to connect to the same database instances using the Database Service's static configuration. This approach is useful if you expect the databases you will proxy via Teleport to remain stable over time.

There are two approaches to deploying the Database Service in high availability using static configuration, which we will describe below:

  • Combined replicas: Teleport load balances database traffic across Database Service replicas
  • Separate replicas: Clients choose which agent to use to connect to a database

Combined replicas

If you have two Database Services proxying the same database, configuration for both agents would be identical:

# Same config for both agents.
db_service:
  enabled: "yes"
  databases:
  - name: "postgres"
    protocol: "postgres"
    uri: "postgres.example.com:5432"

With this configuration, you will see only a single entry for the database in tsh db ls:

tsh db ls

Name

--------

postgres


tsh db connect postgres

As with dynamic resources, Teleport will randomly pick a Database Service instance to connect through to when connecting to a database.

Separate replicas

With separate replicas, each Database Service instance proxying the database assigns it a different name. This allows you to explicitly pick the agent you want to connect to the database over:

# Database service instance #1.
db_service:
  enabled: "yes"
  databases:
  # Note the name is different than instance #2 but the URI is the same.
  - name: "postgres-us-east-1a"
    protocol: "postgres"
    uri: "postgres.example.com:5432"
# Database service instance #2.
db_service:
  enabled: "yes"
  databases:
  # Note the name is different than instance #1 but the URI is the same.
  - name: "postgres-us-east-1b"
    protocol: "postgres"
    uri: "postgres.example.com:5432"

With this configuration, both services will appear as two separate entries in tsh db ls output and you will have to pick one explicitly when connecting:

tsh db ls

Name

-------------------

postgres-us-east-1a

postgres-us-east-1b


tsh db connect postgres-us-east-1a

This approach is useful when you want to have control over which replica you're using to connect.

Next steps