Hi Shubhana,
There are differences between Cloud SQL for Postgres and Cloud SQL for MySQL with respect to high availability. I'll try to addressing your questions while pointing out those differences along the way.
1) Cloud SQL for MySQL has a failover replica that can be used for read queries (similar to a read replica). Uptime of the primary (read/write) instance is prioritized and it is the primary instance, in a high availability configuration, that is backed by Cloud SQL's
SLA. Cloud SQL uses failover to isolate the primary instance from failures and it uses automation to repair failover replicas and read replicas. However, uptime of failover replicas and read replicas is not backed by the SLA.
Unlike Cloud SQL for MySQL, Cloud SQL for Postgres does not have a failover replica that can also be used for read queries. Its high availability configuration is described in a
recent blog post. As with Cloud SQL for MySQL, the primary Cloud SQL for Postgres instance, in a high availability configuration, is backed by Cloud SQL's SLA. Cloud SQL for Postgres read replicas are not backed by the SLA.
2) Both primary and standby instances of Cloud SQL send a heartbeat signal, which is evaluated to define an availability state for the master (primary) instance. If there is a problem with the failover replica, then failover of a primary instance will not occur.
3) When a failover is triggered, the master instance will go offline while the read replica remains online. After the master instance is back online, the read replica will go offline for a short period of time while it is reconnected to the master instance.
4) I've noted differences between Cloud SQL for MySQL and Cloud SQL for Postgres as part of each answer.
5) Each Cloud instance is assigned its own public IP address, even when the Cloud SQL proxy is used. It is recommended that the Cloud SQL proxy be installed on each client machine.
Thanks,
Brett