Modifying a Cloud Bigtable Instance

After you create a Cloud Bigtable instance, you can update any of the following settings without any downtime:

  • The number of nodes in each cluster

    After you add or remove nodes, it typically takes a few minutes under load for Cloud Bigtable to optimize the cluster's performance.

  • The number of clusters in the instance

    After you add a cluster, it takes time for Cloud Bigtable to replicate your data to the new cluster.

  • The application profiles for the instance, which contain replication settings

  • The labels for the instance, which provide metadata about the instance
  • The display name for the instance

You can also upgrade a development instance to a production instance, also without any downtime. This change is permanent.

Before you begin

If you want to use the command-line tools for Cloud Bigtable, install the Cloud SDK and the cbt command-line tool if you haven't already.

Adding and removing nodes

Nodes are the compute resources that a Cloud Bigtable cluster uses to access your data and perform administrative tasks. You should monitor each cluster's CPU and disk usage to make sure the cluster has enough nodes. To learn more about how the number of nodes affects a cluster's performance, see Performance for typical workloads.

By default, you can provision up to 30 Cloud Bigtable nodes per zone in each Google Cloud Platform project. If you need to provision more nodes than the default limit, use the node request form.

To change the number of nodes in a cluster:

Console

  1. Open the list of Cloud Bigtable instances in the GCP Console.

    Open the instance list

  2. Click the instance you want to change, then click Edit instance.

  3. Click the cluster you want to update.
  4. Under Nodes, enter the number of nodes for the cluster.

    In many cases, each cluster in an instance should have the same number of nodes, but there are exceptions. Learn about nodes and replication.

  5. Click Save.

gcloud

  1. If you don't know the instance ID, use the beta bigtable instances list command to view a list of your project's instances:

    gcloud beta bigtable instances list
    
  2. If you don't know the instance's cluster IDs, use the beta bigtable clusters list command to view a list of clusters in the instance:

    gcloud beta bigtable clusters list --instances=INSTANCE_ID
    

    Replace INSTANCE_ID with the permanent identifier for the instance.

  3. Use the beta bigtable clusters update command to change the number of nodes:

    gcloud beta bigtable clusters update CLUSTER_ID \
        --instance=INSTANCE_ID \
        --num-nodes=NUM_NODES
    

    Provide the following values:

    • CLUSTER_ID: The permanent identifier for the cluster.
    • INSTANCE_ID: The permanent identifier for the instance.
    • NUM_NODES: The number of nodes in the cluster. Clusters in a production instance must have 3 or more nodes.

      In many cases, each cluster in an instance should have the same number of nodes, but there are exceptions. Learn about nodes and replication.

cbt

  1. If you don't know the instance ID, use the listinstances command to view a list of your project's instances:

    cbt listinstances
    
  2. If you don't know the instance's cluster IDs, use the listclusters command to view a list of clusters in the instance:

    cbt listclusters -instance=INSTANCE_ID
    

    Replace INSTANCE_ID with the permanent identifier for the instance.

  3. Use the updatecluster command to change the number of nodes:

    cbt updatecluster -instance=INSTANCE_ID CLUSTER_ID NUM_NODES
    

    Provide the following values:

    • INSTANCE_ID: The permanent identifier for the instance.
    • CLUSTER_ID: The permanent identifier for the cluster.
    • NUM_NODES: The number of nodes in the cluster. Clusters in a production instance must have 3 or more nodes.

      In many cases, each cluster in an instance should have the same number of nodes, but there are exceptions. Learn about nodes and replication.

Adding and deleting clusters

An instance can have either 1 or 2 clusters. Instances with 2 clusters automatically use replication.

Adding a cluster

If an instance has 1 cluster, and the cluster is in a region with at least 2 zones that support Cloud Bigtable, you can add a second cluster.

To add a cluster to an instance:

Console

  1. Open the list of Cloud Bigtable instances in the GCP Console.

    Open the instance list

  2. Click the instance you want to change, then click Edit instance.

  3. Under Clusters, click Add cluster.

    If this button is disabled, the instance already has 2 clusters, or its cluster is in a region that offers Cloud Bigtable in only 1 zone. An instance's clusters must be in unique zones that are within the same region.

  4. Enter a cluster ID, and select the cluster's region and zone.

  5. Enter the number of nodes for the cluster.

    In many cases, each cluster in an instance should have the same number of nodes, but there are exceptions. Learn about nodes and replication.

  6. Click Save. Cloud Bigtable creates the cluster and starts replicating your data to the new cluster. You may see CPU utilization increase as replication begins.

  7. If you've started using replication in an instance, your next step is to review the replication settings in the default app profile to see if they make sense for your replication use case. You might need to update the default app profile or create custom app profiles.

gcloud

  1. If you don't know the instance ID, use the beta bigtable instances list command to view a list of your project's instances:

    gcloud beta bigtable instances list
    
  2. If you don't know the instance's cluster IDs, use the beta bigtable clusters list command to view a list of clusters in the instance:

    gcloud beta bigtable clusters list --instances=INSTANCE_ID
    

    Replace INSTANCE_ID with the permanent identifier for the instance.

  3. Use the beta bigtable clusters create command to add a cluster:

    gcloud beta bigtable clusters create CLUSTER_ID \
        --async \
        --instance=INSTANCE_ID \
        --zone=ZONE \
        [--num-nodes=NUM_NODES] \
        [--storage-type=STORAGE_TYPE]
    

    Provide the following values:

    • CLUSTER_ID: The permanent identifier for the cluster.
    • INSTANCE_ID: The permanent identifier for the instance.
    • ZONE: The zone where the cluster runs.

      An instance's clusters must be in unique zones that are within the same region. For example, if the first cluster is in us-east1-b, then us-east1-c is a valid zone for the second cluster. View the zone list.

    The --async flag is not required but is strongly recommended. Without this flag, the command might time out before the operation is complete. Cloud Bigtable will continue to create the cluster in the background.

    The command accepts the following optional flags:

    • --num-nodes=NUM_NODES: The number of nodes in the cluster. Clusters in a production instance must have 3 or more nodes. The default value is 3.

      In many cases, each cluster in an instance should have the same number of nodes, but there are exceptions. Learn about nodes and replication.

    • --storage-type=STORAGE_TYPE: The type of storage to use for the cluster. Each cluster in an instance must use the same storage type. Accepts the values SSD and HDD. The default value is SSD.

  4. If you've started using replication in an instance, your next step is to review the replication settings in the default app profile to see if they make sense for your replication use case. You might need to update the default app profile or create custom app profiles.

cbt

  1. If you don't know the instance ID, use the listinstances command to view a list of your project's instances:

    cbt listinstances
    
  2. If you don't know the instance's cluster IDs, use the listclusters command to view a list of clusters in the instance:

    cbt listclusters -instance=INSTANCE_ID
    

    Replace INSTANCE_ID with the permanent identifier for the instance.

  3. Use the createcluster command to add a cluster:

    cbt createcluster -instance INSTANCE_ID CLUSTER_ID ZONE NUM_NODES STORAGE_TYPE
    

    Provide the following values:

    • INSTANCE_ID: The permanent identifier for the instance.
    • CLUSTER_ID: The permanent identifier for the cluster.
    • ZONE: The zone where the cluster runs.

      An instance's clusters must be in unique zones that are within the same region. For example, if the first cluster is in us-east1-b, then us-east1-c is a valid zone for the second cluster. View the zone list.

    • NUM_NODES: The number of nodes in the cluster. Clusters in a production instance must have 3 or more nodes.

      In many cases, each cluster in an instance should have the same number of nodes, but there are exceptions. Learn about nodes and replication.

    • STORAGE_TYPE: The type of storage to use for the cluster. Each cluster in an instance must use the same storage type. Accepts the values SSD and HDD.

  4. If you've started using replication in an instance, your next step is to review the replication settings in the default app profile to see if they make sense for your replication use case. You might need to update the default app profile or create custom app profiles.

Deleting a cluster

If an instance has 2 clusters, you can delete 1 of the clusters. Deleting a cluster automatically disables replication.

In some cases, Cloud Bigtable does not allow you to delete a cluster:

  • If one of your application profiles routes all traffic to a single cluster, Cloud Bigtable will not allow you to delete that cluster. You must edit or delete the application profile before you can remove the cluster.
  • If you add a new cluster to an existing instance, you cannot delete the original cluster until it has finished its initial data copy to the new cluster.

To delete a cluster from an instance:

Console

  1. Open the list of Cloud Bigtable instances in the GCP Console.

    Open the instance list

  2. Click the instance you want to change, then click Edit instance.

  3. Click the cluster you want to delete, then click the Delete icon in the upper right corner of the cluster settings.
  4. Click Save.

gcloud

  1. If you don't know the instance ID, use the beta bigtable instances list command to view a list of your project's instances:

    gcloud beta bigtable instances list
    
  2. If you don't know the instance's cluster IDs, use the beta bigtable clusters list command to view a list of clusters in the instance:

    gcloud beta bigtable clusters list --instances=INSTANCE_ID
    

    Replace INSTANCE_ID with the permanent identifier for the instance.

  3. Use the beta bigtable clusters delete command to delete the cluster:

    gcloud beta bigtable clusters delete CLUSTER_ID \
        --instance=INSTANCE_ID
    

    Provide the following values:

    • CLUSTER_ID: The permanent identifier for the cluster.
    • INSTANCE_ID: The permanent identifier for the instance.

cbt

  1. If you don't know the instance ID, use the listinstances command to view a list of your project's instances:

    cbt listinstances
    
  2. If you don't know the instance's cluster IDs, use the listclusters command to view a list of clusters in the instance:

    cbt listclusters -instance=INSTANCE_ID
    

    Replace INSTANCE_ID with the permanent identifier for the instance.

  3. Use the deletecluster command to delete the cluster:

    cbt deletecluster -instance=INSTANCE_ID CLUSTER_ID
    

    Provide the following values:

    • INSTANCE_ID: The permanent identifier for the instance.
    • CLUSTER_ID: The permanent identifier for the cluster.

Managing application profiles

Application profiles, or app profiles, control how your applications connect to an instance that uses replication. Every instance with more than 1 cluster has its own default app profile. You can also create many different custom app profiles for each instance, using a different app profile for each kind of application that you run.

To learn how to set up an instance's app profiles, see Configuring App Profiles. For examples of settings you can use to implement common use cases, see Examples of Replication Settings.

Managing labels

Labels are key-value pairs that you can use to group related instances and store metadata about an instance.

To learn how to manage labels, see Adding or updating an instance's labels and Removing a label from an instance.

Changing an instance's display name

To change an instance's display name, which the GCP Console uses to identify the instance:

Console

  1. Open the list of Cloud Bigtable instances in the GCP Console.

    Open the instance list

  2. Click the instance you want to change, then click Edit instance.

  3. Edit the instance name, then click Save.

gcloud

  1. If you don't know the instance ID, use the beta bigtable instances list command to view a list of your project's instances:

    gcloud beta bigtable instances list
    
  2. Use the beta bigtable instances update command to update the display name:

    gcloud beta bigtable instances update INSTANCE_ID \
        --display-name=DISPLAY_NAME
    

    Provide the following values:

    • INSTANCE_ID: The permanent identifier for the instance.
    • DISPLAY_NAME: A human-readable name that identifies the instance in the GCP Console.

cbt

This feature is not available in the cbt tool.

Upgrading a development instance

If you no longer want to use a development instance for development and testing, you can upgrade it to a production instance at any time. Upgrading a development instance is permanent.

To permanently upgrade a development instance to a production instance:

Console

  1. Open the list of Cloud Bigtable instances in the GCP Console.

    Open the instance list

  2. Find the text that says Type: Development, then click the Upgrade link next to the text.

  3. Edit the instance name if necessary.
  4. Under Instance type, select Production.
  5. If you need more than the default of 3 nodes in your cluster, click the box for the first cluster, then edit the number of nodes.

  6. If you want to use replication for the instance, click Add cluster, then update the cluster ID, zone, and number of nodes for the new cluster.

    In many cases, each cluster in an instance should have the same number of nodes, but there are exceptions. Learn about nodes and replication.

  7. Click Save to upgrade the instance.

    If you added a second cluster, Cloud Bigtable starts replicating your data to the new cluster.

  8. If you've started using replication in an instance, your next step is to review the replication settings in the default app profile to see if they make sense for your replication use case. You might need to update the default app profile or create custom app profiles.

gcloud

Use the beta bigtable instances upgrade command:

gcloud beta bigtable instances upgrade INSTANCE_ID

Replace INSTANCE_ID with the permanent identifier for the instance.

The upgraded instance has a single cluster with 3 nodes. After you upgrade the instance, you can add a cluster or add nodes to the existing cluster.

cbt

This feature is not available in the cbt tool.

What's next

Was this page helpful? Let us know how we did:

Send feedback about...

Cloud Bigtable Documentation