Operar bases de datos

Consultar datos de cada base de datos

Casi todas las bases de datos tienen un editor integrado en la consola, así que no hace falta instalar un cliente de terceros para lanzar una consulta.

gcloud sql connect my-instance --user=root

gcloud spanner databases execute-sql example-database \
  --instance=example-instance --sql='SELECT * FROM MyTable WHERE MyKey = 1'

bq query --use_legacy_sql=false 'SELECT COUNT(*) FROM `my-project.sales.orders`'

gcloud components install cbt
cbt listinstances

La CLI cbt no implementa reintentos inteligentes ni gestión de errores; para producción Google recomienda las bibliotecas cliente de Bigtable o la consola. Sus opciones (proyecto, instancia…) se pueden guardar en un archivo .cbtrc.

Un dry run valida la consulta sin ejecutarla y devuelve una estimación de los bytes que procesaría (el coste en modo bajo demanda). No usa slots y no se cobra. La estimación se puede llevar a la calculadora de precios.

bq query --use_legacy_sql=false --dry_run \
  'SELECT name FROM `my-project.sales.customers` WHERE country = "ES"'

Las copias de Cloud SQL son incrementales y se cifran con claves de Google o con CMEK. Al crear una instancia nueva hay que elegir entre dos opciones de copia:

gcloud sql backups create --async --instance=my-instance
gcloud sql backups list --instance=my-instance
gcloud sql backups restore BACKUP_ID --restore-instance=target-instance

• Restaurar sobre una instancia existente sobrescribe todos sus datos, incluidos los registros previos para la recuperación a un momento dado.
• Al borrar una instancia, sus copias bajo demanda y automáticas pasan a ser copias retenidas a nivel de proyecto, que se pueden restaurar en una instancia nueva o existente.
• Restaurar desde una copia no conserva la IP de la instancia borrada. Para recuperarla con su IP, Cloud SQL guarda las copias de las instancias borradas durante 4 días, y en ese plazo se puede pedir a Customer Care que la recupere tal como estaba.

Recuperación a un momento dado (PITR)

PITR restaura una instancia principal al estado de un instante concreto, esté activa o borrada. Siempre crea una instancia nueva: no se puede aplicar sobre una instancia existente. En MySQL necesita el registro binario y las copias activados, con registros continuos desde la última copia anterior al incidente. El método recomendado es indicar una marca de tiempo; en la consola se hace con Create clone y Clone from an earlier point in time.

gcloud sql instances clone SOURCE_INSTANCE NEW_INSTANCE \
  --point-in-time='2026-10-24T08:15:00.000Z'

Los cambios que ocurren en esa marca de tiempo o después no aparecen en la instancia nueva.

Copias en Spanner, Firestore, AlloyDB y Bigtable

gcloud spanner backups create my-backup --instance=my-instance \
  --database=my-db --retention-period=2w

gcloud firestore backups schedules create --database='(default)' \
  --recurrence=daily --retention=4w

gcloud firestore databases restore \
  --source-backup=projects/PROJECT_ID/locations/LOCATION/backups/BACKUP_ID \
  --destination-database=restored-db

gcloud bigtable backups create my-backup --instance=my-instance \
  --cluster=my-cluster --table=my-table --retention-period=7d

Todos los datos de Google Cloud se cifran en reposo con AES-256 y claves de Google, sin configurar nada. Con CMEK las claves las creas tú en Cloud KMS: controlas su rotación, su acceso y su estado, ves sus registros de uso y cumples normativas que exigen claves propias. El cifrado y descifrado lo hace el agente de servicio del recurso de forma transparente.

• Cloud KMS Autokey crea los llaveros y claves al crear el recurso y concede los roles a los agentes de servicio. Google lo recomienda si sus claves cumplen tus requisitos.
• Con copias mejoradas de Cloud SQL y CMEK, el agente de servicio de Backup and DR necesita roles/cloudkms.cryptoKeyEncrypterDecrypter sobre la clave.
• Cloud KMS cobra por versión de clave y por operación criptográfica; el cifrado por defecto es gratuito.

Cada carga, exportación, consulta o copia crea un trabajo asíncrono. Sus estados son PENDING, RUNNING y DONE; si un trabajo terminado falló, incluye errorResult. El coste se factura al proyecto que ejecuta el trabajo.

bq ls --jobs --filter="states:RUNNING,PENDING"
bq show --jobs JOB_ID
bq cancel JOB_ID
bq wait JOB_ID

La interfaz de supervisión de la consola muestra la lista de trabajos (en ejecución y los de los últimos 30 días), el grafo del trabajo con cada paso, los detalles de ejecución, métricas, coste estimado, recomendaciones, gráficos de autoescalado, alertas preconfiguradas para streaming, los registros del pipeline y muestreo de datos.

gcloud dataflow jobs list --region=europe-west1
gcloud dataflow jobs describe JOB_ID --region=europe-west1
gcloud dataflow jobs drain JOB_ID --region=europe-west1
gcloud dataflow jobs cancel JOB_ID --region=europe-west1

Los trabajos de Dataflow no se pueden borrar, solo archivar; los terminados se eliminan a los 30 días. Antes de parar un pipeline de streaming conviene hacer un snapshot para conservar su estado.

Database Center

Panel con asistencia de IA que ofrece una vista centralizada de toda la flota de bases de datos, de todos los proyectos. Usa datos de los proyectos y de Security Command Center para mostrar problemas de salud y recomendaciones, y tiene un chat de Gemini para preguntar por ellos.

• Muestra el inventario, los motores y versiones en uso, qué bases críticas no están optimizadas para la disponibilidad, cuáles no tienen copias, cuáles no siguen buenas prácticas de seguridad y cuáles no cumplen estándares del sector.
• Monitoriza la salud de AlloyDB, Bigtable, Cloud SQL (MySQL, PostgreSQL y SQL Server), Firestore, Memorystore for Redis y Redis Cluster, Spanner y Oracle Database@Google Cloud. De BigQuery solo muestra el inventario.
• Los datos no son en tiempo real: suelen actualizarse en minutos, pero pueden tardar hasta 24 horas.

Escenarios de examen

Trampas frecuentes del examen