Professional Cloud Database Engineer — Preguntas de práctica y simulacro de examen

Spanner es la base de datos relacional de Google, escalable horizontalmente y con consistencia fuerte. Su disponibilidad depende de la configuración de la instancia: las configuraciones regionales mantienen las réplicas dentro de una sola región y tienen un SLA del 99.99%, mientras que las multirregionales distribuyen las réplicas de lectura y escritura entre regiones y tienen el SLA más alto, del 99.999% (menos de cinco minutos de inactividad al año). Las configuraciones multirregionales incluyen al menos tres regiones y cinco réplicas, y Spanner ejecuta el failover automáticamente cuando una región deja de estar disponible. Esto contrasta con Cloud SQL, donde la alta disponibilidad es solo zonal dentro de una región. Por eso, elegir la configuración de instancia es la palanca de diseño central tanto para la disponibilidad como para la residencia de los datos. Consejo de examen: asocia el número mágico 99.999% directamente con Spanner multirregional, y 99.99% (Spanner regional) o 99.95% (Cloud SQL HA) con los niveles inferiores.

Cloud SQL te permite configurar una ventana de mantenimiento en la que especificas el día y la hora de las actualizaciones. La documentación de Google recomienda programar el mantenimiento en periodos de poco tráfico para minimizar el impacto en los usuarios. Las ventanas de mantenimiento predeterminadas ya están fuera de las horas pico: de lunes a viernes de 10 PM a 6 AM, y los fines de semana. El propio ejemplo de Google muestra a un minorista que programa el mantenimiento a medianoche los domingos — el periodo de menor tráfico. Con un pico de uso de 9 AM a 6 PM de lunes a viernes, programarlo en horas de baja demanda (fines de semana o de noche) es lo correcto. El mantenimiento es totalmente programable (la opción “El mantenimiento no se puede programar y ocurre de forma aleatoria” es incorrecta — no ocurre de forma aleatoria). Programarlo después de las ventanas de backup no guarda ninguna relación con un menor impacto. Hacerlo en horas pico maximizaría la interrupción. También puedes definir periodos de denegación de mantenimiento de hasta 90 días para bloquear actualizaciones en fechas críticas para el negocio. Ref: cloud.google.com/sql/docs/mysql/maintenance

Cloud SQL ofrece una función de failover manual pensada específicamente para probar la recuperación ante desastres en alta disponibilidad. La documentación de Google dice: “Probar el failover es opcional, pero se recomienda para que puedas ver cómo responde tu aplicación cuando ocurre uno”. Lo activas con gcloud sql instances failover INSTANCE_NAME, con la Cloud SQL Admin API (instances.failover) o con el botón Failover de la Console. Esto simula la falla de una zona y dispara el mecanismo de failover automático hacia la instancia en espera, lo que te permite validar la lógica de reconexión de tu aplicación y medir el tiempo real de failover. Eliminar la instancia principal la destruye de forma permanente — eso no es una prueba. Apagar una zona desde la Console no es algo que un usuario pueda hacer. Desconectar la red es poco confiable y no prueba el mecanismo real de failover de Cloud SQL. Ref: cloud.google.com/sql/docs/postgres/configure-ha#initiate-failover

Migrar de Oracle a Spanner exige un enfoque por fases porque es una migración heterogénea — Spanner tiene un modelo de datos fundamentalmente distinto (sin stored procedures, sin triggers, otro diseño de claves). La guía oficial de migración de Google indica: (1) convertir el esquema y el modelo de datos, (2) traducir las consultas SQL, (3) modificar la aplicación para que escriba en ambas bases de datos (escritura dual), (4) exportar e importar los datos de forma masiva con Dataflow, (5) mantener la consistencia con CDC (por ejemplo, Striim u Oracle LogMiner), (6) validar y hacer el cutover. Este enfoque por fases permite cero inactividad porque mantiene ambos sistemas sincronizados hasta que hay confianza suficiente. Datastream no puede transmitir directamente a Spanner. DMS no admite la migración directa de Oracle a Spanner. La exportación e importación de CSV requiere inactividad y no sincroniza los cambios. Ref: cloud.google.com/spanner/docs/migrating-oracle-to-cloud-spanner