我有一个应用程序，每隔几分钟就会从大约 1000 个不同的来源接收数据。这些数据需要保存到 OSS 数据库中（最有可能是 MySQL - 但根据答案，我会考虑在适当的情况下切换）。
发送信息的 1000 台外部服务器通常每 2 分钟向应用程序请求一次数据。
应用程序对数据至关重要，因此它不能出现任何故障。我已经对应用程序部分进行了 HA（高可用性）排序，但我需要有关数据库 HA 的建议。Oracle 不是一个选项。
一位朋友建议在应用服务器之间使用 SQLlite rsynced，但我觉得这很危险。我研究了 MASTER-MASTER MySQL db 设置，但它看起来有问题，而且根据用户评论，它可能不稳定。
有什么建议么？
必须在 Linux 上运行，必须是开源的。
答案1
我们在关键数据库的生产中使用 master<->master MySQL 复制已有 2 年多，没有出现任何问题。在我们的设置中，数据库通过不稳定的非专用链路进行复制。配置简单，灾难恢复毫无麻烦。我推荐它。
以前，我们一直使用带有心跳的专用链路上的 MySQL 主->从复制来进行故障转移，这是一个可行的选择 - 但两台机器都必须位于同一个路由器后面。
答案2
MySQL 集群或许？
无论如何，是的，忘记 SQLite。它不是解决您问题的错误方法。
答案3
Mysql Cluster 似乎是一个不错的解决方案，但它依赖于数据库大小，因为目前使用 Mysql Cluster 时所有数据都必须装入内存
答案4
如果两个实例之间存在任何数据差异，主<->主复制可能会很麻烦。在我们的案例中，我们一直在使用主-主模式运行许多使用孤立服务器的 Web 应用程序（两组服务器，每组有 MySQL、Apache 和 Squid），并且在我们的案例中，我们有一个会话表，该表的写入流量很大，这可能导致写入冲突（两组数据以相同的 ID 插入到同一个表中）。
在这种情况下，您需要在应用程序层中使用一些重型逻辑来确保正确划分写入，这样就不会发生写入冲突。这并不可怕，但如果没有系统管理员的干预，复制错误就无法轻易恢复。在这种情况下，Master<->Master 实际上会导致可用性降低。
这并不意味着你会灰心，因为一旦你解决了问题它肯定会运行良好，但也存在一些令人讨厌的陷阱。