我正在运行一个 Web 应用程序托管服务（基本上是免费托管论坛），并且我有两个远程服务器可供使用。应用程序的代码存储在两个服务器上，这没什么问题，但我想知道如何处理数据库。
当有人访问网站 *.example-host.com 时，他们会被发送到两个服务器之一，并且两个服务器都必须能够从数据库加载论坛。数据库还必须具有写入权限，以便新成员注册或发布主题等。
主要要求是速度，但正常运行时间也很重要（如果服务器出现故障，网站仍应正常运行）。
我有几个选择，但我缺乏经验，不确定该选择哪一个：
1）[PHP]将论坛记录在两台服务器之间按 50:50 的比例分配。如果一台服务器没有请求的论坛记录，它可以通过远程 MySQL 从另一台服务器请求并加载。这个想法听起来不错，直到我意识到 50% 的时间里，用户将等待更长的时间才能加载页面。我还意识到，如果其中一台服务器出现故障，一半的论坛将无法访问，注册也必须被禁用。
2）[MySQL]双主复制。这将尝试镜像两个数据库，听起来很完美，但我听说这可能会很成问题。我不知道这有多快。
3）[MySQL]使用标准复制，在两个节点上分发只读查询，并将读/写查询分发到主节点。这听起来是个不错的选择，但同样，我不确定速度。我也不知道如果主服务器宕机会发生什么。
如果您有任何其他建议，请发表:)
答案1
解决方案 1 接近分片但需要考虑和设计整个架构，以便以最佳方式实现这一目标。分片通常需要大规模安装，突破技术平台的极限。
解决方案 2 或双主复制是适用的，但由于您的链接在物理上是分开的，因此让应用程序动态指向任一数据库都是有风险的。您需要选择一个数据库，如果数据库发生故障，请手动将应用程序重新指向新数据库。应用程序的自动故障转移会带来裂脑风险。您可以每晚拍摄辅助数据库的快照以进行备份。
如解决方案 3 中所述，复制通常用于将只读负载分配到不同的数据库服务器。它还允许您对读取查询使用不同的引擎和配置。例如，MyISAM 可以更快地执行只读查询。
复制通常仅受物理硬件限制（无论是网络还是系统资源）的影响。除非您在数据库中大规模存储二进制数据，否则我不会担心正常负载下的复制延迟。
由于您的主要要求是速度，因此我首先会关注本地系统配置和资源。很有可能可以在那里进行实质性的优化。
自动高可用性解决方案通常最好局限于单一物理环境，在出现极端故障的情况下，可以应用手动解决方案来启用物理上独立的站点。
我基于 LAMP 堆栈进行概括，并专注于 Web 应用程序。不同的应用程序、协议和技术会略有不同，但就 Web 服务器和数据库而言，我所描述的内容更具有普遍适用性。