地理冗余和 MySQL 复制
我有一个相当简单的网站，使用 LAMP 配置每天获得 20 万次点击（每秒 3-5 次点击）。 该主机有点不稳定（读：便宜），因此我们想添加第二台主机以保证正常运行时间（我不会称其为关键任务，而是更多地预防烦恼）。
MySQL 的空闲速度约为 200 qps，有时会达到 450 qps。
我对主-主和 maatkit 设置有一些经验，因此我打算在第二个位置复制站点，使用主-主复制，并使用 maatkit 验证数据并监控从属滞后等。
但是，在阅读所有内容时关于此设置的可怕警告，我正在尝试评估这是否是正确的举动。 什么是替代架构？
附加问题：假设您有 2 台服务器，一台在东海岸，一台在西海岸。 对于这些来说，负载平衡数据库的合理策略是什么？ 你会让西海岸的apache服务器访问东海岸的mysql吗？ 这真的是一个选择吗？ 我认为延迟会影响性能......
有什么想法吗？ TIA 麦克风
I has a fairly simple site getting 200K hits/day (3-5 hits/sec) using a LAMP configuration. The host is somewhat flaky (read: cheap), so we want to add a 2nd host for guaranteed uptime (I wouldn't call this mission critical, but more annoyance-prevention).
MySQL is idling at about 200 qps, spiking for 450 at times.
I have some experience with master-master and maatkit setup, so I was going to duplicate the site in a 2nd location, use master-master replication, and validate the data with maatkit and monitoring slave-lag, etc.
However, in reading all the dire warnings about this setup, I'm trying to assess if this is the right move. What's an alternative architecture?
Additional question: Say you have 2 servers, one on the east coast, and one on the west coast. What's a reasonable strategy for load balancing the database for those? Would you have the west coast apache server access mysql on the east coast? Is that really an option? I thought the latencies would kill the performance...
Any thoughts?
TIA
Mike
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
美国的跨度约为 50 毫秒，因此考虑到每个 http 查询执行 40-90 个 mysql 查询，您可以预期 http 查询的延迟会增加至少 2-4.5 秒。 这忽略了传输任何大型有效负载所需的时间。 你不想为这个应用程序做跨大陆的mysql。
避免跨大陆 mysql 查询的另一个原因是两个主数据库可能不同步，因此如果您在两个数据库之间进行循环查询，用户可能会看到不一致的数据并感到困惑。 但是，如果您的本地数据库发生故障，则回退到远程数据库是合理的。 在这种情况下，您还希望将流量从本地网络服务器转移出去，以避免上述延迟影响。
您需要确保用户坚持使用同一个 apache 服务器，以便他们获得一致的数据视图。 执行此操作的一个简单方法是将用户从 www.yoursite.com 重定向到 server1.yoursite.com 和 server2.yoursite.com，确保所有 URL 都是相对的。 如果一台服务器出现故障，您可以重新指向 DNS，在此之前，用户可能会不断刷新 www.yoursite.com（这将作为 DNS 循环），直到他们找到另一台服务器。 这样做的一个危险是用户会将 server1.yoursite.com 添加为书签。
The US is about 50ms across, so given that you're doing 40-90 mysql queries per http query you can expect a latency increase of at least 2-4.5 seconds for http queries. This is ignoring the time it'll take to transfer any large payloads. You don't want to do cross-continent mysql for this app.
Another reason to avoid cross-continent mysql queries is that the two masters may be out of sync so if you round robin queries acorss the two databases users may see inconsistent data and get confused. However if your local database is hard down, falling back to the remote one is reasonable. You'd also want to divert traffic away from the local webserver in this case to avoid the aforementioned latency hit.
You will want to make sure that a user sticks to the same apache server so that they get a consistent view of the data. A simple way to do this is to redirect users from www.yoursite.com to server1.yoursite.com and server2.yoursite.com, making sure that all your URLs are relative. If one server goes down you can repoint DNS, and until then users will probably keep refreshing www.yoursite.com (which would be served as a DNS roundrobin) until they get the other server. The one danger with this is that users will bookmark server1.yoursite.com.
可以使用同一站点上的虚拟 IP 使用主动备用方法来保证正常运行时间。您甚至可以将不同的站点配置为主动备用。 地理冗余是另一个问题。
Guaranteed uptime can be done using active standby approach using virtual IP at the same site.You can even have different site configured as active standby as well. Geo redundancy is another issue.