Mysql复制 - 值得吗？

Question

复制

我有一个应用程序，它正在从大量数据源中轮询数据。它每天处理数千条记录，这个数字不断增加。数据存储在Mysql中。

然后我有一个利用这些数据的网站。

我正在努力建立我的环境，考虑到未来。

我想到了mysql复制，以便网站可以在不同的服务器上使用它自己的数据库，并且被主数据库上发生的数千个写命令所困扰。

我很难得到这个设置，尽管mysql报告它一切正常。

然后我开始思考 - 有没有更好的方法？ 根据我的理解，mysql将write命令作为master发送到slave数据库。

这是不是意味着我想要避免的事情正好发生了？ 这是否意味着从数据库将遭受数千次写入

我是一个单人乐队，用自己的钱做这个冒险，所以我需要以最便宜的方式做到这一点。我有点失落了！

我有一个专用的服务器， 一个vps 在灯堆中使用Php5，mysql 5。

我无法开始告诉你我多么感激一些指导！

Answer 1

如果从设备是主设备的1：1克隆，则必须将所有写入主设备的设备向下传播到从设备。否则复制将毫无用处。

每天数千条记录实际上非常小。假设每个处理时间相同，并且执行5000条记录，则每条记录的86400/5000 = 17.28秒。这是非常小的写入开销。

如果你每天要做数百万条记录，那么你就会遇到写作瓶颈。

Answer 2

我会把它分成三层。

1. 数据Feed层。从Feed中读取的数据被预处理并发布到队列中。该层有一个临时队列，也用作临时存储，一个缓冲区，允许所有数据馈送发布其数据。我使用消息队列系统。它快速可靠。

2. 数据存储层。该层从队列中读取，可能会处理读取的数据，并将数据存储在数据库中。

3. 数据分析图层。这是您的“奴隶”数据库。这是一个数据仓库。它会定期从数据存储层向此辅助数据库执行ETL（提取，转换和加载）数据。

这种layeread方法允许您隔离关注点（速度，可靠性，安全性）和实现细节;并允许未来的可扩展性。

Answer 3

复制实际上是单词建议 - 在另一台机器上复制查询。 MySQL创建一个日志，其中填充了用于在原始计算机（master）上创建数据集的查询，并将其发送到读取日志并重新执行这些查询的从服务器。

基本上，你想要的是提高写字率。这可以通过使用不同的引擎来实现，例如TokuDB就是其中之一（但它不是免费的，但您可以免费存储50gb的用户数据并使用它）。

您想要的（暂时）快速HDD子系统不仅仅是一个单一的可写扩展存储系统。 InnoDB能够在具有足够硬件的正确配置的机器上实现每秒大量查询。我不确定定价，但SSD和4-8演出的内存不应该 昂贵。作为马克。 B说 - 直到你每天达到数百万条记录，你不必担心通过复制扩展读写。

Answer 4

您说您有一个应用程序从数据源“轮询”您的数据。这是否意味着您正在进行全文搜索？我在这里做一个假设，你是批处理日期源，然后查询。如果是这种情况，我会将所有全文查询卸载到像Solr这样的东西。实际上设置起来并不太费时，根据您的数据库的大小，您可以在相当小的VPS或专用上运行它，最好但差异是搜索速度令人难以置信。我有完整的文本mysql查询，需要20分钟才能在一秒钟内在solr中完成。

请确保在solr实例出现故障时使用try语句。