我有一个应用程序每隔几分钟从大约1000个不同的来源接收数据。 这些数据需要保存到一个OSS数据库（很可能是MySQL），但根据不同的答案，我会考虑在适当的情况下进行切换。
发送信息的1000台外部服务器通常每2分钟从应用程序请求数据。
这个应用程序是关键数据，因为它永远不能停下来。 我有应用程序部分sortingHA（高可用性），但我对数据库HA的build议。 Oracle不是一个选项。
一位朋友build议在应用程序服务器之间进行SQLlite rsynced，但这对我来说听起来很危险。 我看着MASTER MASTER MySQL数据库设置，但它看起来有问题，并从用户意见可能不稳定。
有什么build议么？
必须在linux上运行，必须是开源的。
我们已经在关键数据库的生产环境中使用master < – > master master replication 2年以上，没有任何问题。 在我们的设置中，数据库通过不稳定的非专用链接进行复制。 configuration容易，灾难恢复没有麻烦。 我推荐它。
以前，我们一直在用心跳的专用链路来使用MySQL master-> slave复制来进行故障切换，这是一个可行的select，但是两台机器都必须在同一个路由器之后。
MySQL群集可能？
无论如何，是的，忘记SQLite。 这是你的问题的错误解决scheme。
Mysql集群似乎是一个很好的解决scheme，但是依赖于数据库大小，因为现在所有的数据必须适合内存使用Mysql集群时
MySQL集群似乎是一个明显的select，因为它可以支持5到9个HA，但是它不太适合Web应用程序。
签出find您的MySQL高可用性解决scheme – 问题：
http://planet.mysql.com/entry/?id=21763
鉴于你的（写）要求，我想我会考虑心跳/ SAN，如果我是你。
干杯
如果两个实例之间存在任何数据差异，则Master < – >主复制可能是个婊子。 在我们的例子中，我们一直在使用孤岛服务器（两台服务器，每台都有MySQL，Apache和Squid）来使用master-master，在我们的例子中，我们有一个会话表会导致写入stream量太大，导致写入冲突（将两组数据插入同一个ID中的同一个表中）。
在这种情况下，您需要在应用程序层使用一些重型逻辑，以确保写入被正确划分，从而避免写入冲突。 不可怕，但是如果没有系统pipe理员的干预，复制错误不能轻易恢复。 在这种情况下，Master < – > Master实际上会导致可用性降低。
不要让你灰心，因为一旦你find了解决办法，它肯定会奏效，但是，还有一些烦人的陷阱。