Cloud SQL read pools support load balancing for your large read workloads.

## What are read pools?

A *read pool* is a collection of read replica instances used to distribute
your large read workloads. These workloads can be redirected from the primary
instance to the read pool to reduce load on the primary instance.

Each read replica in the read pool is called a *read pool node*.

You can scale your read pool in several ways:

- **Scale in or out**: scale load balancing capacity horizontally by modifying the number of read pool nodes in the read pool. Each read pool supports between 1 and 7 read pool nodes.
- **Scale up or down**: scale load balancing capacity vertically by modifying the machine type associated with a read pool node. Once defined, configuration is uniformly applied across each read pool node in the read pool.

When you modify read pool node settings such as storage, connectivity, or
database configuration flags, the changes are automatically applied uniformly
across each read pool node in the read pool.

### Access a read pool through a single read endpoint

The read pool is accessible through a *single read endpoint* with
an immutable IP address. Connections made through the endpoint are
automatically redirected to one of the read pool nodes. When you want the
read pool to scale in or scale out, applications that were previously
connected to this single read endpoint don't need to be reconfigured, even
though you can create new read pool nodes in the read pool or delete previous
ones.

Each read pool node also has its own IP address. While not
recommended as an efficient approach for accessing your data, you can use
these IP addresses to troubleshoot individual read pool node performance.

For more information on how to retrieve the connection information for the
read pool or the read pool nodes (either IP addresses or a connection string),
see
[View read pool information](https://docs.cloud.google.com/sql/docs/sqlserver/create-read-pool.md.txt#view-read-pool).

## Replication

Cloud SQL read pool replication is implemented using
[SQL Server Read Scale Availability Groups](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/read-scale-availability-groups?view=sql-server-linux-2017#read-scale-availability-groups-without-cluster).

For more information, see [About replication](https://docs.cloud.google.com/sql/docs/sqlserver/replication.md.txt).

## Read pool autoscaling

You can configure your read pool to automatically resize to adapt to
your application's changing workload needs. For more information, see
[Read pool autoscaling](https://docs.cloud.google.com/sql/docs/sqlserver/read-pool-autoscaling.md.txt).

## Read pool characteristics

The following characteristics apply:

- Read pools don't have a unique Cloud SQL-supported API. Any operation to create, configure, or view a read pool is done using the Cloud SQL instance API.   

  For example, when using the `gcloud CLI` to create a
  read pool, you use the `gcloud sql instances create`
  command. Similarly, to check the number of read pool nodes configured on a
  read pool, you use the `gcloud sql instances describe` command.
- A read pool with two or more nodes is covered under the [Service Level Agreement (SLA)](https://cloud.google.com/sql/sla).
- Read pool nodes of the read pool always reside in the same region, as specified by the user. Google Cloud alternates read pool node residency among all zones in the region.
- A primary instance can have one or more read pools.
- The following operations incur sub-second downtime:
  - Scaling out or in (adding or removing read pool nodes).
  - Scaling up or down (changing the machine type of the nodes in the pool).
  - Converting an existing zonal read replica to a read pool.
- A read pool receives maintenance before its primary instance, similar to read replicas. Like read replicas, read pools receive maintenance during the primary instance's maintenance window.
- Each read pool node has the same metrics available as a Cloud SQL read replica.
- When using `gcloud` or the Google Cloud console to describe the details of a project, the read pool name is listed, individual read pool node names are not.

### Maximum read pool node count per primary instance

You can assign a maximum of seven read replicas per primary instance.

The combined number of read replicas and read pool nodes replicating from the
same primary instance can't exceed seven.

#### How to calculate maximum read pool node count per primary instance

Conceptually, you can think of a read replica as a single read pool node.

You can convert a read replica to a read pool, and then change the number of
read pool nodes to some number greater than one.

You can then assign autoscaling to the read pool so that the read pool node count
dynamically adjusts up or down to match workload needs.

When autoscaling is enabled on a read pool, you must indicate a valid maximum
node count for the read pool. That number, combined with the number of existing
read replicas replicating from the same primary, or read pool nodes belonging to
other read pools replicating from the same primary, can't exceed seven.

As an example, if a primary instance has two read replicas, and one read pool
with two read pool nodes, and a second read pool with autoscaling enabled, the
maximum read pool node count for the second read pool can't be a value greater
than three.

For more information, see [Read pool autoscaling](https://docs.cloud.google.com/sql/docs/sqlserver/read-pool-autoscaling.md.txt).

## Limitations

The following limitations apply:

- Read pools are only available for [Cloud SQL Enterprise Plus edition](https://docs.cloud.google.com/sql/docs/sqlserver/editions-intro.md.txt) instances on the [new network architecture](https://docs.cloud.google.com/sql/docs/sqlserver/upgrade-cloud-sql-instance-new-network-architecture.md.txt#check-single-instance). The primary instance associated with a read pool must also be a Cloud SQL Enterprise Plus edition instance.
- You can assign a maximum of 7 read replicas per primary instance. For more information, see [Maximum node count](https://docs.cloud.google.com/sql/docs/sqlserver/about-read-pools.md.txt#maximum-node-count).
- [Advanced disaster recovery](https://docs.cloud.google.com/sql/docs/sqlserver/use-advanced-disaster-recovery.md.txt) isn't compatible with read pools. Primary instances can't use both read pools and [cascadable replicas](https://docs.cloud.google.com/sql/docs/sqlserver/replication.md.txt#cascading-replicas-sqlserver).
- Traffic is served from read pool nodes based on whether the database is healthy, but regardless of how high replication lag on that read pool node is. Traffic can be served from a lagging read pool node even if another read pool node is available that isn't lagging. A database is considered healthy if the database process is up and can answer queries, but there is no requirement on how fresh the data being served is.
- No guarantee is made about a single logical session connecting to multiple read pool nodes in the read pool.
- The following types of updates aren't supported:
  - While read pools still receive Cloud SQL maintenance updates, you can't update your read pool or its associated primary instance to a new major database version.
  - Starting or stopping nodes of the read pool.
- In addition to operations that aren't supported on read replicas, the following operations aren't supported on read pools:
  - Enable and disable replication
  - [Customer-managed Active Directory](https://docs.cloud.google.com/sql/docs/sqlserver/cmad.md.txt)
  - [Managed Microsoft AD](https://docs.cloud.google.com/sql/docs/sqlserver/ad.md.txt)
  - Promote replica
  - Restart
  - Import
  - Export
  - Failover
  - Re-encrypt
  - Clone
- SSL/TLS certificates with shared CA or customer-managed CA can't be used with a read pool.
- A read pool can't replicate to another instance, for example, a cascading replica or another read pool.
- A read pool must replicate directly from a primary instance. It can't be a cascading replica.
- When creating or scaling a read pool, you must wait for previous create pool, scale in, or scale out operations associated with the read pool to finish. This restriction applies to any other read pool associated with the same primary instance. If you want to scale multiple read pools associated with the same primary instance, then you must wait for scaling operations associated with the first read pool to finish before you start scaling the next read pool. If you issue concurrent requests, then you might receive the following error: `Operation failed because another operation was already in progress.`.
- Only a zonal replica located in the same region as the primary can be converted for use in a read pool.
- Read pool nodes might experience varying levels of replication lag, which can result in inconsistent reads. If your application requires high-read consistency, we recommend vertically scaling a single read replica instead of using a read pool.
- Cloud SQL automatically repairs read pool nodes in the following conditions:
  - When the instance is down.
  - When the replication is broken.

  In these scenarios, if you create additional logins from the primary instance,
  then you won't be able to sign in using those logins after the read pool node
  is recreated. Make sure that the login you use for the read endpoint is available
  from the primary instance.
- Microsoft doesn't support server object replication. Any server-level objects you create on a read replica must also be created and
  managed on the primary instance. These objects are not automatically replicated.

  This behavior applies in the following scenarios, though not an exhaustive list:
  - Repairing a read pool.
  - Converting a read replica to a read pool.
    - Server level objects such as logins become inaccessible.
    - If you create a login which exists on the original read replica but not on the primary instance, then the login isn't replicated to the new read pool node.
  - Converting a read pool to a read replica.
    - If you create a login on a read pool and not the primary instance, and then later disable the read pool, then the login no longer exists.

  Some examples of server-level objects not replicated include the following:
  - Logins.
  - Linked server configuration.
  - Database audit files created by [SQL Server Audit](https://docs.cloud.google.com/sql/docs/sqlserver/db-audit.md.txt).
  - [XEvents](https://docs.cloud.google.com/sql/docs/sqlserver/extended-events.md.txt) sessions and their configuration settings.

  For more information, see [Microsoft](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/logins-and-jobs-for-availability-group-databases?view=sql-server-ver17)
  documentation.
- The [transparent data encryption (TDE)](https://docs.cloud.google.com/sql/docs/sqlserver/about-tde.md.txt) certificate is blocked for both import and export operations.
- You must always import and export TDE certificates from the primary instance. The TDE certificates will be automatically replicated to all read replicas in the read pool, no matter the type of replica.
- TDE import and export operations aren't supported. Always import the TDE certificate from the primary instance.

## What's next

- [Create and manage read pools](https://docs.cloud.google.com/sql/docs/sqlserver/create-read-pool.md.txt)