Scegliere il database giusto per HA e scala

Il primo bivio di design riguarda l’ampiezza del dominio di guasto che devi coprire. Cloud SQL (managed MySQL, PostgreSQL, SQL Server) e’ un servizio regionale: l’high-availability si ottiene abilitando la configurazione HA, che mantiene una failover replica (standby) in una zona diversa della stessa region, con replica sincrona dello storage. Copre il guasto di una zona, non di un’intera region. AlloyDB e’ PostgreSQL-compatibile, aggiunge un motore colonnare per query analitiche e i read pool per scalare le letture; l’HA si costruisce con nodi ridondati nella region.

Spanner e’ l’unico database relazionale globalmente distribuito: scala orizzontalmente, offre strong/external consistency e, in configurazione multi-region, arriva a un SLA del 99.999%. E’ la scelta quando servono scrittura globale, capacita’ virtualmente illimitata e resilienza al guasto di una region intera, accettandone il costo superiore. Se il requisito e’ “un solo RDBMS che sopravvive alla perdita di una region senza intervento manuale”, la risposta e’ Spanner multi-region, non Cloud SQL.

HA contro DR: failover e read replica non sono la stessa cosa

Distinzione centrale e ricorrente nelle domande. La failover replica di Cloud SQL serve l’high-availability: in caso di guasto zonale, il servizio promuove automaticamente lo standby e l’endpoint resta lo stesso (RTO nell’ordine di poche decine di secondi, RPO prossimo a zero grazie alla replica sincrona).

Le read replica servono invece a scalare le letture: offloadano query di sola lettura dall’istanza primaria e possono essere cross-region. Non sono un meccanismo di failover automatico dello scrittore: promuovere una read replica a primaria e’ un’operazione manuale (o scriptata) che usi in scenari di disaster recovery regionale, tipicamente con una perdita di dati pari al lag di replica asincrona. Confondere “aggiungo una read replica” con “ottengo HA” e’ l’errore classico.

Il disaster recovery copre la perdita di una region e si costruisce con backup, PITR (point-in-time recovery via binary log per MySQL / WAL per PostgreSQL) e, dove serve, read replica cross-region da promuovere. Ragiona sempre in termini di RTO (quanto downtime tolleri) e RPO (quanti dati puoi perdere) per scegliere fra HA sincrona intra-region e DR asincrona cross-region.

Testare il failover e automatizzare con IaC

Un’architettura HA vale solo se il failover e’ stato testato. Cloud SQL consente un failover test controllato per verificare che l’applicazione riconnetta correttamente, che i connection pool gestiscano il drop e che l’RTO reale rientri nei target: mai scoprire in produzione che il client non ritenta la connessione. Su Spanner il fallimento di zona/region e’ gestito trasparentemente dal servizio, ma le esercitazioni DR restano buona pratica.

Il provisioning va reso ripetibile con Terraform (Infrastructure as Code): definisci istanze, flag HA, read replica, backup e finestre di manutenzione come codice versionato, ottenendo ambienti identici e disaster recovery ricostruibile. Completa il quadro con il monitoring: su Cloud SQL tieni sotto controllo il replication lag (misura diretta dell’RPO in caso di promozione), CPU/memoria/connessioni e lo stato della failover replica; su Spanner la CPU utilization delle istanze, che guida lo scaling dei nodi/processing units.

Trappole tipiche d’esame

  • “Serve un RDBMS che sopravviva alla perdita di un’intera region con scrittura globale” → Spanner multi-region: Cloud SQL e’ regionale, la sua failover replica copre solo la zona; Spanner e’ l’unico relazionale globalmente distribuito con SLA 99.999%.
  • “Le letture di reporting saturano il primario” → read replica (o read pool AlloyDB): aggiungere read replica scala le letture; abilitare la configurazione HA con failover replica non riduce il carico di lettura, serve alla disponibilita’.
  • “Vogliamo failover automatico dello scrittore su Cloud SQL” → HA con failover replica, non read replica: la read replica va promossa manualmente; solo la failover replica dell’HA promuove in automatico mantenendo lo stesso endpoint.
  • “Recuperare lo stato a un istante preciso dopo un errore applicativo” → PITR/backup (DR), non HA: l’high-availability protegge dai guasti infrastrutturali, non dagli errori logici; per tornare indietro nel tempo servono backup e point-in-time recovery.
  • “Ambienti identici e ricostruibili” → Terraform (IaC): il provisioning manuale non e’ riproducibile ne’ auditabile; l’IaC versiona flag HA, replica e backup.
  • “Come so se il failover funziona davvero” → failover test controllato + monitoring del replication lag: l’HA non testata e il lag non monitorato nascondono RTO/RPO reali fuori target fino al disastro.