A solução 1 está perto de sharding , mas toda a arquitetura precisa ser considerada e projetada para realizar isso da melhor maneira. O sharding geralmente apresenta instalações em grande escala, empurrando os limites das plataformas de tecnologia.
A solução 2 ou replicação master dupla seria aplicável, mas como seus links são fisicamente separados, seria arriscado fazer com que o aplicativo apontasse dinamicamente para o banco de dados. Você desejaria escolher um banco de dados e, se o banco de dados falhasse, redirecionar manualmente o aplicativo para o novo banco de dados. O failover automático do aplicativo introduz o risco de divisão do cérebro. Você pode tirar instantâneos noturnos dos bancos de dados secundários para backups.
Conforme descrito na solução 3, a replicação é frequentemente usada para distribuir a carga somente leitura para diferentes servidores de banco de dados. Também permite usar diferentes mecanismos e configurações para as consultas de leitura. Por exemplo, o MyISAM pode ser mais rápido para consultas de somente leitura.
A replicação geralmente está sujeita apenas às limitações de hardware físico, sejam recursos da rede ou do sistema. A menos que você esteja armazenando dados binários no banco de dados em grande escala, eu não me preocuparia com atrasos de replicação sob carga normal.
Sendo que o seu principal requisito é a velocidade, eu primeiro me concentro na configuração e nos recursos do sistema local. As chances são otimizações substanciais podem ser feitas lá.
As soluções automáticas de alta disponibilidade são normalmente melhor localizadas em um único ambiente físico e, em caso de extrema falha, soluções manuais podem ser aplicadas para ativar o site fisicamente separado.
Estou generalizando com base em uma pilha LAMP e me concentrando em aplicativos da Web. Diferentes aplicações, protocolos e tecnologias mudam um pouco as coisas, mas no que diz respeito aos servidores e bancos de dados da Web, o que eu descrevo é mais aplicável em geral.