Cloud Spanner for global distribution in GCP - Commands & Configuration

Introduction

Cloud Spanner is a database service that stores data across the world. It helps keep your data safe and available everywhere, so your app works fast no matter where users are.

When you want your app's data to be available quickly to users in different countries.

When you need a database that can handle lots of users at the same time without slowing down.

When you want to avoid losing data even if one data center has a problem.

When you want to manage your database easily without worrying about servers.

When you need strong consistency so all users see the same data instantly.

Config File - instance-config.yaml

instance-config.yaml

apiVersion: spanner.cnrm.cloud.google.com/v1beta1
kind: SpannerInstance
metadata:
  name: global-spanner-instance
spec:
  config: regional-us-central1
  displayName: "Global Spanner Instance"
  nodes: 3
  labels:
    environment: production
---
apiVersion: spanner.cnrm.cloud.google.com/v1beta1
kind: SpannerDatabase
metadata:
  name: global-database
spec:
  instanceRef:
    name: global-spanner-instance
  ddlStatements:
    - "CREATE TABLE Users (UserId STRING(36) NOT NULL, UserName STRING(1024)) PRIMARY KEY (UserId)"
    - "CREATE TABLE Orders (OrderId STRING(36) NOT NULL, UserId STRING(36), OrderDate TIMESTAMP) PRIMARY KEY (OrderId)"

This file creates a Cloud Spanner instance named global-spanner-instance in the us-central1 region with 3 nodes for capacity. It also creates a database called global-database inside that instance. The database has two tables: Users and Orders. The tables have primary keys defined to organize data efficiently.

The config field sets the instance location. The nodes field controls how much power the instance has. Labels help identify the environment.

Commands

This command creates a Cloud Spanner instance named 'global-spanner-instance' in the us-central1 region with 3 nodes. Nodes determine the capacity and performance of the instance.

Terminal

gcloud spanner instances create global-spanner-instance --config=regional-us-central1 --description="Global Spanner Instance" --nodes=3

Expected Output

Created instance [global-spanner-instance].

→

--config - Sets the geographic location of the instance.

→

--nodes - Specifies the number of nodes for capacity.

This command creates a database named 'global-database' inside the 'global-spanner-instance' instance. It also creates two tables: Users and Orders with their columns and primary keys.

Terminal

gcloud spanner databases create global-database --instance=global-spanner-instance --ddl='CREATE TABLE Users (UserId STRING(36) NOT NULL, UserName STRING(1024)) PRIMARY KEY (UserId)' --ddl='CREATE TABLE Orders (OrderId STRING(36) NOT NULL, UserId STRING(36), OrderDate TIMESTAMP) PRIMARY KEY (OrderId)'

Expected Output

Created database [global-database] on instance [global-spanner-instance].

→

--instance - Specifies the instance where the database will be created.

→

--ddl - Defines the schema for tables in the database.

This command shows details about the 'global-spanner-instance' instance, including its configuration, nodes, and state. It helps verify the instance is created correctly.

Terminal

gcloud spanner instances describe global-spanner-instance

Expected Output

name: projects/my-project/instances/global-spanner-instance

config: projects/my-project/instanceConfigs/regional-us-central1

description: Global Spanner Instance

nodeCount: 3

state: READY

This command lists all databases inside the 'global-spanner-instance' instance. It confirms that 'global-database' exists and is ready to use.

Terminal

gcloud spanner databases list --instance=global-spanner-instance

Expected Output

NAME

-----

global-database

→

--instance - Specifies the instance to list databases from.

Key Concept

If you remember nothing else from this pattern, remember: Cloud Spanner lets you store and access your data quickly and safely across the world by creating instances and databases with the right location and capacity.

Common Mistakes

Creating an instance without specifying the correct config region.

The instance may be created in a default or undesired location, causing higher latency for users.

Always use the --config flag with the region closest to your users or your app servers.

Not defining primary keys in table creation DDL statements.

Cloud Spanner requires primary keys for tables; missing them causes errors.

Include PRIMARY KEY clauses in every CREATE TABLE statement.

Trying to create a database before the instance is ready.

The database creation will fail because the instance does not exist or is not ready.

Wait for the instance creation to complete and verify with describe command before creating databases.

Summary

Create a Cloud Spanner instance with a specific region and number of nodes to set capacity.

Create a database inside the instance with tables and primary keys using DDL statements.

Verify the instance and database exist and are ready using describe and list commands.

Practice

1. What is the main benefit of using Cloud Spanner's global distribution feature?

easy

A. It keeps applications fast and reliable by storing data across multiple regions.

B. It reduces the cost of storage by using local disks only.

C. It automatically deletes old data to save space.

D. It limits access to data to a single region for security.

Solution

1. Step 1: Understand global distribution purpose

   Cloud Spanner stores data in multiple regions to improve speed and reliability.

2. Step 2: Compare options

   Only It keeps applications fast and reliable by storing data across multiple regions. correctly describes the benefit of global data storage for performance and reliability.

3. Final Answer:

   It keeps applications fast and reliable by storing data across multiple regions. -> Option A

4. Quick Check:

   Global data storage = fast and reliable apps [OK]

Hint: Global means data spread worldwide for speed and reliability [OK]

Common Mistakes:

• Thinking global distribution saves storage cost
• Believing data is deleted automatically
• Assuming data is limited to one region

2. Which of the following is the correct way to specify a multi-region configuration in Cloud Spanner?

easy

A. multi_region_config = "europe-west1"

B. multi_region_config = "us-central1"

C. multi_region_config = "asia-east1"

D. multi_region_config = "nam3"

Solution

1. Step 1: Identify multi-region config names

   Cloud Spanner uses specific multi-region config names like "nam3" for North America multi-region.

2. Step 2: Check options

   Only A is a valid multi-region config. Options B, C, and D are single-region names.

3. Final Answer:

   multi_region_config = "nam3" -> Option D

4. Quick Check:

   Multi-region config uses names like nam3 [OK]

Hint: Multi-region configs have short codes like nam3, not single region names [OK]

Common Mistakes:

• Using single region names instead of multi-region codes
• Confusing region names with zone names
• Misspelling multi-region config strings

3. Given this Cloud Spanner instance configuration:
instance_config = "nam3"
nodes = 3
What is the expected behavior of this setup?

medium

A. Data is globally distributed across North America with 3 nodes handling requests.

B. Data is stored in a single region with 3 nodes for processing.

C. Data is stored only in Europe with 3 nodes.

D. Data is stored in Asia with 3 nodes but no replication.

Solution

1. Step 1: Interpret instance_config "nam3"

   "nam3" is a multi-region config for North America, so data is distributed across multiple regions there.

2. Step 2: Understand nodes setting

   3 nodes means the instance has 3 processing units to handle workload.

3. Final Answer:

   Data is globally distributed across North America with 3 nodes handling requests. -> Option A

4. Quick Check:

   nam3 = North America multi-region + 3 nodes [OK]

Hint: Multi-region config + nodes = distributed data with processing power [OK]

Common Mistakes:

• Assuming single region storage with multi-region config
• Ignoring the meaning of nodes
• Confusing region names with multi-region configs

4. You configured a Cloud Spanner instance with instance_config = "nam3" but your app experiences high latency in Europe. What is the likely cause?

medium

A. The instance_config "nam3" is invalid and causes errors.

B. You need to increase the number of nodes to reduce latency.

C. The multi-region config "nam3" only covers North America, not Europe.

D. Cloud Spanner does not support multi-region configurations.

Solution

1. Step 1: Understand "nam3" coverage

   "nam3" is a multi-region config limited to North America regions only.

2. Step 2: Analyze latency cause

   High latency in Europe happens because data is not stored close to European users.

3. Final Answer:

   The multi-region config "nam3" only covers North America, not Europe. -> Option C

4. Quick Check:

   nam3 excludes Europe, causing latency there [OK]

Hint: Check if multi-region config covers your app's user locations [OK]

Common Mistakes:

• Assuming multi-region covers all continents
• Thinking node count fixes geographic latency
• Believing "nam3" is invalid

5. You want to deploy a Cloud Spanner instance that serves users in Asia, Europe, and North America with low latency. Which configuration should you choose?

hard

A. Use a single-region config in Asia with 5 nodes.

B. Use the multi-region config "nam-eur-asia1" with enough nodes.

C. Use multiple single-region instances in each continent.

D. Use the multi-region config "nam3" with 3 nodes.

Solution

1. Step 1: Identify multi-region config covering Asia, Europe, North America

   "nam-eur-asia1" is a multi-region config spanning these continents.

2. Step 2: Understand node allocation

   Choosing enough nodes ensures capacity and low latency across regions.

3. Step 3: Compare other options

   Single-region configs or multiple instances increase complexity or limit coverage.

4. Final Answer:

   Use the multi-region config "nam-eur-asia1" with enough nodes. -> Option B

5. Quick Check:

   nam-eur-asia1 covers all needed continents [OK]

Hint: Pick multi-region config covering all user continents [OK]

Common Mistakes:

• Choosing single-region config for global users
• Using nam3 which excludes Europe and Asia
• Deploying multiple instances instead of one multi-region