We are evaluating the AlloyDB service and don't really understand how updates/patches are rolled out.
Basically there are two scenarios: Primary instance update: What happens when the primary instance is updated? Will there be a restart or downtime?
Read-Pool update: What happens when an update is rolled out in a read pool. Is there a downtime of the whole read pool or is one read node after the other restarted?
Thank you very much!
When changing the machine type of the primary instance, I unfortunately noticed that there is a downtime of about 15 minutes.
Alloydb is an enterprise grade database with 99.99% uptime SLA, including update/patches.
To commit that high availability, there is a condition: there is at least a primary and a fail over instance in the same time.
That's why, when there is a maintenance, the failover instance is patched, then it is promoted as primary, (and the primary as failover) and the new failover is patched.
There is only a very short downtime for the upgrade (about 10s, thank Gabe), maybe some writes/transactions lost during the switch (failover promoted, master instance down). And more if there is an outage during the maintenance windows (no luck! but it could happen!) -> because there is no longer failover available during the maintenance.
To better understand, look at this schema extracted from this video
There is no attachement of the storage to the engine. That's why it's very fast to switch from one instance to the other one on the persistent data. Only the "in progress" transaction are impacted.