Global Read Replicas

Suggest Edits

📘

Enterprise Only Feature

bit.io's global read replica feature provides near-real-time read-only versions of your data around the globe, securely distributed across multiple cloud providers and multiple regions. By enabling this feature, you can markedly reduce latency and increase throughput on all your read and write operations. And, because bit.io is serverless, each replica will autoscale with demand in each region, too. If you have deployed software around the globe, it will have fast connections to bit.io.

Setting up read-replicas couldn't be easier: Toggle one checkbox and connect via replica.bit.io instead of db.bit.io.

Enabling Read Replicas

Navigate to the database for which you want read replicas and goto the "Config" tab (shown below). Toggle the "Global Read Replicas" setting (circled in red) to on.

1241

If you do not see the Global Read Replicas option, contact [email protected] to opt-in to the beta.

Connecting to Read Replicas

After enabling read replicas, you can can create a read-only connection by replacing db.bit.io with replica.bit.io in your connection parameters. That's all you need!

👍

bit.io automatically selects the closest replica

When you connect to replica.bit.io, bit.io dynamically routes your connection to the closest read replica.

When should I use read-replicas?

Generally, read replicas are best used to either (1) reduce latency on reads or (2) remove load from your primary. With bit.io serverless, the major benefit is reduced latency because bit.io automatically scales up your primary as load increases.

In most cases, read replicas are a strict benefit -- they reduce latency and increase throughput. However, there are several situations in which bit.io's configuration of read replicas are not appropriate or have tradeoffs:

  • Your reads must be always and exactly up-to-date -- If you need to be perfectly up-to-date, you must directly connect to the primary as necessary.

📘

Monitoring replication lag

You can check the lag on the read replica by running: select pg_current_wal_lsn() on the primary (db.bit.io) and select pg_last_wal_receive_lsn() on the replica (replica.bit.io) at the same time and comparing the LSNs. For more detail, review "27.2.5.2. Monitoring" in https://www.postgresql.org/docs/current/warm-standby.html.

  • You need to run long-running, read-only queries queries on a very active database -- these queries will likely be cancelled so that the read replica can accommodate data updates that it receives from the primary.

How should I use read replicas?

There are two general connection strategies. In either case, establish two connections to bit.io: one to the primary (db.bit.io) and one to the replica (replica.bit.io). Then, do one of the following strategies:

  1. Routing-based: If you or your application can determine in advance which queries will be read-only, route your queries over the appropriate connection. Those queries will run faster and help increase throughput.

  2. Retry-based: If you or your application cannot determine in advance which queries will be read-only, then first run your queries over the replica and if they fail, try again on the primary. Do not forget that the replica may have a slight lag from the primary and the delay in retry may impact your application or the data may be stale. If your use-case cannot tolerate or risk that retry delay, then this strategy is not appropriate.

Finally, ensure that you do not read information from the replica and use that as part of an open transaction with the primary -- the replica may lag behind the primary and using stale information may lead to inconsistencies. Instead, read from the primary inside the same transaction.

Technical Details

bit.io's read replication feature is built on top of postgres' warm standby log shipping functionality with asynchronous streaming replication enabled. The technical limitations of the feature are detailed in https://www.postgresql.org/docs/current/hot-standby.html. In short, it's read only and you will get errors if you try write operations.

You can determine if you're connected to a read replica by running SHOW in_hot_standby or checking whether the host of your connection is replica.bit.io.

Currently, all read replicas are configured for high TPS, short-running queries. In general, we see a <1s lag between changes on the primary and their appearance in the replica. If your use-case is particularly sensitive to lag, we recommend running SHOW [parameter name] to get the parameters in https://www.postgresql.org/docs/current/runtime-config-replication.html and reviewing these settings as they will describe the replication functionality.

Known Limitations
Beyond https://www.postgresql.org/docs/current/warm-standby.html, replicas that are unused after 72 active primary hours will have slower initial startup on first connection. That is, once the primary is active for 72 hours while the replica is not, the subsequent first connection to the replica will be slower while it warms back up.

Beta Limits

Supported Geographies:

  • North America
  • Southeast Asia

Updated 3 months ago