Professional Cloud Database Engineer — Questões de prática e simulado

O Spanner é o banco de dados relacional do Google, com escalabilidade horizontal e consistência forte. A disponibilidade depende da configuração da instância: configurações regionais mantêm as réplicas dentro de uma única região e têm SLA de 99.99%, enquanto as multirregionais distribuem as réplicas de leitura e escrita entre regiões e têm o SLA mais alto, de 99.999% (menos de cinco minutos de indisponibilidade por ano). As configurações multirregionais têm pelo menos três regiões e cinco réplicas, e o Spanner faz o failover automaticamente quando uma região fica indisponível. Isso contrasta com o Cloud SQL, em que a alta disponibilidade é apenas zonal dentro de uma região. Por isso, escolher a configuração da instância é a principal alavanca de design tanto para disponibilidade quanto para residência de dados. Dica de prova: associe o número mágico 99.999% diretamente ao Spanner multirregional, e 99.99% (Spanner regional) ou 99.95% (Cloud SQL HA) aos níveis mais baixos.

O Cloud SQL permite configurar uma janela de manutenção especificando o dia e a hora das atualizações. A documentação do Google recomenda agendar a manutenção em períodos de pouco tráfego para reduzir o impacto nos usuários. As janelas de manutenção padrão já ficam fora do pico: dias úteis das 10 PM às 6 AM e fins de semana. O próprio exemplo do Google mostra um varejista agendando a manutenção à meia-noite de domingo — o período de menor tráfego. Com pico de uso das 9 AM às 6 PM nos dias úteis, agendar em horários de baixo movimento (fins de semana ou tarde da noite) é o correto. A manutenção é totalmente agendável (a opção “A manutenção não pode ser agendada e acontece de forma aleatória” está errada — ela não acontece de forma aleatória). Agendar depois das janelas de backup não tem relação nenhuma com baixo impacto. No horário de pico, a interrupção seria máxima. Você também pode definir períodos de bloqueio de manutenção de até 90 dias para impedir atualizações em momentos críticos para o negócio. Ref: cloud.google.com/sql/docs/mysql/maintenance

O Cloud SQL oferece um failover manual justamente para testar a recuperação de desastres em alta disponibilidade. A documentação do Google diz: “Testar o failover é opcional, mas é recomendado para que você veja como sua aplicação responde quando ocorre um failover.” Você o aciona com gcloud sql instances failover INSTANCE_NAME, pela Cloud SQL Admin API (instances.failover) ou pelo botão Failover no Console. Isso simula a falha de uma zona e dispara o mecanismo de failover automático para a instância standby, permitindo validar a lógica de reconexão da sua aplicação e medir o tempo real de failover. Excluir a instância primária a destrói de forma permanente — isso não é um teste. Desligar uma zona pelo Console não é possível para usuários individuais. Desconectar a rede é pouco confiável e não testa o mecanismo real de failover do Cloud SQL. Ref: cloud.google.com/sql/docs/postgres/configure-ha#initiate-failover

Migrar de Oracle para Spanner exige uma abordagem em fases porque é uma migração heterogênea — o Spanner tem um modelo de dados fundamentalmente diferente (sem stored procedures, sem triggers, design de chaves diferente). O guia oficial de migração do Google determina: (1) converter o schema e o modelo de dados, (2) traduzir as consultas SQL, (3) alterar a aplicação para gravar nos dois bancos (escrita dupla), (4) exportar/importar os dados em massa via Dataflow, (5) manter a consistência usando CDC (por exemplo, Striim ou Oracle LogMiner), (6) validar e fazer o cutover. Essa abordagem em fases permite zero indisponibilidade porque mantém os dois sistemas sincronizados até haver confiança suficiente. O Datastream não consegue transmitir diretamente para o Spanner. O DMS não oferece suporte à migração direta de Oracle para Spanner. Exportar/importar CSV exige indisponibilidade e não sincroniza as mudanças. Ref: cloud.google.com/spanner/docs/migrating-oracle-to-cloud-spanner