You use read replicas to power your read-intensive apps and business intelligence tooling. Using read replicas to serve reads for your app removes load from the primary data instance, and enables your service to improve ingest performance. This is particularly useful when read traffic is very spiky and risks impacting ingest performance, or where reads have a lower priority to writes.
This page shows you how to create and manage read replicas.
A read replica is a read-only copy of the primary data instance in your Timescale Cloud service. Queries on read replicas have minimal impact on the performance of the primary data instance. This enables you to interact with up-to-date production data for analysis or to scale out reads beyond the limits of your primary data instance. You use read replicas for read scaling. To limit data loss for your Timescale Cloud services, use High availability.
You can create as many read replicas as you need. Each read replica appears as its own service. You use a unique connection string to interact with each read replica. This provides both security and resource isolation. To restrict access without isolation, you can create a read-only role for each Timescale Cloud service. Users with read-only permissions cannot access the primary data instance directly.
Read replicas can be short-lived and deleted when the analysis is complete, or long-running to power a business intelligence (BI) tool. To create a secure read replica for your read-intensive apps:
Best practice is to create a read-only role for the person using the replica.
You create the read-only user on the primary data instance. This user is propagated to the read replica when you create it.
In Timescale Console, select the service to replicate.
Click
Operations, then clickRead replicas.Click
Add read replica, then select the configuration you want and clickAdd read replica.Note the connection information for the read replica.
The connection string for each read replica is unique, and different to one you use for the primary data instance.
Read replicas use asynchronous replication. This can cause slight lag in data to the primary data instance. Replica lag is measured in bytes against the current state of the primary database. To see the lag for both read and high-availability replicas replicas running on Timescale Cloud:
To check the status and lag for your read replicas:
In Timescale Console, select a service.
The status of the read-replica and data lag is displayed:
You can also see this information in the
Operationstab.To reduce the allowable lag, adjust the
max_standby_streaming_delay, andmax_standby_archive_delayparameters.This is not best practice where changes must be immediately represented, such as for user credentials.
Keywords
Found an issue on this page?Report an issue or Edit this page in GitHub.