Database Access High Availability (HA)
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
- Get started by connecting your database.