我正在运行一个Web应用程序托pipe服务（基本上免费托pipe论坛），我有两个远程服务器在我的处置。 应用程序的代码存储在两台服务器上，这不是一个问题，但我想知道如何处理数据库。
当有人进入一个站点* .example-host.com时，他们被发送到两台服务器之一，两者都必须能够从数据库加载论坛。 数据库还必须具有写入权限，以便新成员注册或发布主题等。
主要的要求是速度，但正常运行时间也很重要（如果服务器熄灭，该站点仍应该工作）。
我有几个select，但我没有经验，不知道该怎么办：
1）[PHP]在两台服务器之间拆分论坛logging50:50。 如果服务器没有请求的论坛的logging，它可以通过远程MySQL从另一个请求它并加载它。 这个想法听起来不错，直到我意识到50％的时间，用户将等待更长的时间来加载页面。 我也意识到，如果其中一台服务器出现故障，一半的论坛将无法访问，注册将被禁用。
2）[MySQL]双主复制。 这将试图镜像两个数据库，听起来很完美，但我听说它可能是非常有问题的。 我不知道这是多快。
3）[MySQL]使用标准复制，在两个节点上分发只读查询，并向主节点读/写查询。 这听起来像是一个不错的select，但是我不能确定速度。 如果主服务器出现故障，我也不知道会发生什么情况。
如果您有任何其他build议，请发表:)
解决scheme1接近分片，但整个架构需要考虑和devise，以最好的方式完成。 分片通常会带来大规模的安装，推动技术平台的极限。
解决scheme2或双主复制将适用，但由于您的链接在物理上是分开的，因此将应用程序dynamic指向任一数据库将是有风险的。 您将希望select一个数据库，如果数据库失败，请手动将应用程序重新指定到新的数据库。 应用程序的自动故障转移引入了分裂大脑的风险。 您可以每晚获取备份数据库的快照。
如解决scheme3中所述，复制通常用于将只读加载分配给不同的数据库服务器。 它也可以让你使用不同的引擎和configuration读取查询。 例如，MyISAM可以更快地进行只读查询。
复制通常仅受networking或系统资源的物理硬件限制。 除非您在二进制数据库中大规模地存储二进制数据，否则我不会担心正常负载下的复制延迟。
作为您的主要要求是速度，我会首先关注本地系统configuration和资源。 有机会可以在那里做实质性的优化。
自动高可用性解决scheme通常是最好的本地化到一个单一的物理环境，并在极端故障的情况下，可以应用手动解决scheme，使物理上分离的网站。
我正在基于LAMP堆栈进行推广，并专注于Web应用程序。 不同的应用程序，协议和技术稍微改变了一点，但是关于Web服务器和数据库，我所描述的更普遍适用。