View the original community article here
Last tested: Jan 21, 2019
First things first: High availability databases use an architecture that is designed to continue to function normally even when there are hardware or network failures within the system. They have emerged as an alternative to traditional relational databases, which are generally built to be deployed on a single server and rely on a master/replica architecture to provide availability.
High availability databases are built to eliminate single points of failure and are optimized to ensure that the end user does not experience an interruption in service or a degradation in user experience when hardware or networks fail. This is often accomplished through a masterless architecture that uses clustering, in which multiple servers are grouped together. Because there is no master, any server within a cluster can respond to read or write requests. Data is then replicated across all servers in the cluster, providing system redundancy and minimizing the possibility of downtime.
Looker's clustering relies on an external database. This database could be HA if it's configured that way. This configuration is completely separate from Looker, outside the scope of the Looker init script, and up to the you to implement.