Partition by region
Use partition-by-region clusters to geo-locate data in specific regions.
Clusters consist of a primary region and any number of additional secondary regions, where the partitioned, region-specific data resides. You can add or remove regions as required. When first deploying, you can deploy a single cluster in the primary region.
Tablespaces
You place data in regions of the cluster using tablespaces. Tables that don't belong to any tablespace are stored in the primary region.
YugabyteDB Managed automatically creates tablespaces in the regions of your cluster named region_name_ts. For example, if you add the us-central1 region, the tablespace is named us_central1_ts.
To view your cluster tablespaces, you can enter the following command:
SELECT * FROM pg_tablespace;
Note that data pinned to a single region via tablespaces is not replicated to other regions, and remains subject to the fault tolerance of the cluster (Node- or Availability Zone-level).
For more information on specifying data placement for tables and indexes, refer to Tablespaces.
Features
Partition-by-region clusters include the following features:
- Multi node clusters with availability zone- or node-level fault tolerance.
- No limit on cluster size - choose any cluster size based on your use case.
- Size each region to its load - add extra horsepower in high-traffic regions, and provision lower-traffic regions with fewer nodes.
- Horizontal and vertical scaling - add or remove nodes and vCPUs, and add storage to suit your production loads.
- VPC networking required.
- Automated and on-demand backups.
- Available in all regions.
- Enterprise support.
Prerequisites
- Partition-by-region clusters must be deployed in a VPC. Create a VPC for each region where you want to deploy the nodes in the cluster. Refer to VPC network overview.
- By default, clusters deployed in VPCs do not expose any publicly-accessible IP addresses. Unless you enable Public Access, you can only connect from resources inside the VPC network. Refer to VPC network overview.
- A billing profile and payment method. Refer to Manage your billing profile and payment method.
Create a partition-by-region cluster
To create a partition-by-region cluster, on the Clusters page, click Add Cluster, and choose Dedicated to start the Create Cluster wizard.
The Create Cluster wizard has the following pages:
General Settings
Set the following options:
- Cluster Name: Enter a name for the cluster.
- Provider: Choose a cloud provider.
- Database Version: Dedicated clusters are deployed using a stable release. If you have arranged a custom build with Yugabyte, it is also be listed here.
Cluster Setup
Select Multi-Region Deployment and set the following options.
Select data distribution mode
Set Data Distribution to Partition by region.
Select a Fault Tolerance for the regions. Fault tolerance determines how resilient each region is to node and zone outages (planned or unplanned). Choose one of the following:
| Fault tolerance | Description | Scaling |
|---|---|---|
| Zone | Resilient to a single zone outage. Minimum of 3 nodes spread across 3 availability zones. This configuration provides the maximum protection for a data center outage. Recommended for production deployments. | Nodes are scaled in increments of 3 (each zone has the same number of nodes). |
| Node | Resilient to 1, 2, or 3 node outages, with a minimum of 3, 5, or 7 nodes respectively, deployed in a single availability zone. Not resilient to zone outages. | Nodes are scaled in increments of 1. |
| None | Minimum of 1 node, with no replication or resiliency. Recommended for development and testing only. | Nodes are scaled in increments of 1. |
Fault tolerance is applied to all regions in the cluster, including those added after cluster creation.
Select regions and node size
Regions - For each region, choose the following:
- region where the nodes will be located.
- VPC in which to deploy the nodes. Only VPCs using the selected cloud provider and available in the selected region are listed. For multi-region GCP clusters, the same VPC is used for all regions. VPCs must be created before deploying the cluster. Refer to VPC networking.
- number of nodes to deploy in the region.
- number of virtual CPUs per node.
- disk size per node.
- disk input output (I/O) operations per second (IOPS) per node (AWS only).
To add additional regions to the cluster, click Add Region.
Partiton-by-region clusters support both horizontal and vertical scaling; you can add regions and change the cluster configuration after the cluster is created. Refer to Scale and configure clusters.
Monthly total costs for the cluster are based on the number of vCPUs and estimated automatically. + Usage refers to any potential overages from exceeding the free allowances for disk storage, backup storage, and data transfer. For information on how clusters are costed, refer to Cluster costs.
Network Access
Trusted IP Addresses
YugabyteDB Managed only allows access to clusters from trusted IP addresses. For applications in peered VPCs to be able to connect, you need to add the CIDR of the peered VPC to the cluster IP allow list. You can also assign IP allow lists to your cluster any time after the cluster is created.
You can add IP addresses using any combination of the following options.
| Option | Description |
|---|---|
| Add Current IP Address | Creates an allow list using the public IP address of your computer and adds it to the cluster IP allow list. |
| Add Peered VPC Networks | Only available for clusters being deployed in a VPC. VPCs must be peered, and the peering connection active for the peered networks to be added to the IP allow list. Choose Add All Peered Networks to create an IP allow list from every network peered with the cluster VPC, and add it to the cluster. Choose Add Individual Peered Networks to select specific peered networks to add to the cluster IP allow list. |
| Add Existing IP Allow List | Choose from a list of IP allow lists already created for your account. |
| Create New IP Allow List | Create a new IP allow list and manually enter the CIDR and public IP addresses. |
Enable Public Access for this Cluster - To connect to a cluster deployed in a VPC from a public IP address (including your current address), you must enable Public Access for the cluster. When enabled, a public IP address is added to each region of the cluster. You can view the private and public host addresses under Connection Parameters on the cluster Settings > Infrastructure tab.
Private Service Endpoint
For clusters in AWS and Azure, you can connect your cluster to your application VPC using a private link. To do this, you add a private service endpoint (PSE) to each region in your cluster.
You can also add PSEs after your cluster is created.
To use a private link for network isolation and security, choose Create Private Service Endpoint, then add security principals. A security principal is a cloud provider account with permissions to manage endpoints. In AWS, this would be Amazon resource names, and in Azure, Subscription IDs.
After the cluster is created, you still need to complete the private link setup by adding an endpoint on your application VPC for each region in your cluster, and linking them to the PSEs on your cluster.
For more information, refer to Private service endpoints.
Security
In addition to the volume encryption that YugabyteDB Managed uses to encrypt your data, you can enable YugabyteDB encryption at rest (EAR) for clusters. When enabled, your YugabyteDB cluster (including backups) is encrypted using a customer managed key (CMK) residing in a cloud provider Key Management Service (KMS).
To use a CMK to encrypt your cluster, make sure you have configured the CMK in AWS KMS, Azure Key Vault, or Google Cloud KMS. Refer to Prerequisites.
To use a CMK, select the Enable cluster encryption at rest option and set the following options:
-
KMS provider: AWS, Azure, or GCP.
-
For AWS:
- Customer managed key (CMK): Enter the Amazon Resource Name (ARN) of the CMK to use to encrypt the cluster.
- Access key: Provide an access key of an IAM identity with permissions for the CMK. An access key consists of an access key ID and the secret access key.
-
For Azure:
- The Azure tenant ID, the vault URI (for example,
https://myvault.vault.azure.net), and the name of the key. - The client ID and secret for an application with permission to encrypt and decrypt using the CMK.
- The Azure tenant ID, the vault URI (for example,
-
For GCP:
- Resource ID: Enter the resource ID of the key ring where the CMK is stored.
- Service Account Credentials: Click Add Key to select the credentials JSON file you downloaded when creating credentials for the service account that has permissions to encrypt and decrypt using the CMK.
Database Credentials
The database admin credentials are required to connect to the YugabyteDB database that is installed on the cluster.
You can use the default credentials generated by YugabyteDB Managed, or add your own.
For security reasons, the database admin user does not have YSQL superuser privileges, but does have sufficient privileges for most tasks. For more information on database roles and privileges in YugabyteDB Managed, refer to Database authorization in YugabyteDB Managed clusters.
After the cluster is provisioned, you can add more users and change your password.
Download the credentials, and click Create Cluster.
Important
Save your database credentials. If you lose them, you won't be able to use the database.After you complete the wizard, the Clusters page appears, showing the provisioning of your new cluster in progress.
When the cluster is ready, the cluster Overview tab is displayed.
You now have a fully configured YugabyteDB cluster provisioned in YugabyteDB Managed with the database admin credentials you specified.