MySQL 复制与其他技术

Question

我很难在项目中走正确的道路。

我是一个预算紧张的单人乐队。 2台专用服务器 MySQL 5 / php5

我正在使用服务器 1 来消耗来自各种提要的大量数据。服务器/软件 24/7 全天候运行，生成一个巨大的数据库。

服务器 2 - 保存一份副本 带有网络前端的数据库

我没有任何 MySQL 复制经验。我一直在研究，据我所知，奴隶会在主人之后立即更新。

我想要一个非常快速的网站，所以这就是为什么在服务器 1 上进行处理，而服务器 2 只是选择数据。

如果 MySQL 复制正在模仿服务器 1，那么这肯定会降低服务器 2 的速度并产生与预期相反的效果。

我认为最适合这种情况的方法是编写一个脚本来自动化该过程。

服务器 2 有 2 个数据库。一份供现场处理。

脚本确定哪个数据库处于活动状态，然后使用另一个数据库。

它会删除其中的所有表格。 该脚本从服务器 1 转储数据库。 将其安装在服务器 2 新清空的数据库上。 该脚本更改网站配置文件以利用新数据库。

这个过程可以一遍又一遍地重复。

虽然数据库安装会很大，但它可能会在晚上完全安装，应该意味着没有停机时间。

这比做 MySQL 复制好吗？ 我会欢迎建议。

Answer 1

您确实没有提供足够的信息来说明您的目标，但这是我的最佳理解：server1 正在获取数据（使用带宽）并以某种方式处理它（使用处理能力和 I/O） ; server2 正在为基于后处理数据的用户提供实时信息。 server2 的可用性比 server1 更重要，server1 上的问题不应影响 server2 的操作。

如果 server1 正在获取的原始数据与在 server2 上使用的“完成”数据之间存在显着差异，可能会在此过程中产生一些临时数据，只需让 server1 完成它的工作，并使用某种类型用于定期将后处理数据从 server1 带到 server2 的脚本。也许后处理的数据比 server1 正在处理的原始数据要小？

如果 server1 并没有真正做太多的处理，只是获取数据并插入到数据库中，那么复制可能是将数据从 #1 移动到 #2 的合理方法。

中间的方法是只复制某些后处理的表，这样server1可以在mysql中的其他表中完成它的工作，当最终产品被插入到复制的表中时，它会自动出现在server2上.

玩得开心。

Answer 2

很难相信数据库转储/加载周期会比复制更快。尤其是基于行的（非查询）复制。如果您不想在高峰时间复制复制（通过在从属服务器上运行 SLAVE STOP SQL_THREAD）（当然您必须有足够的非高峰时间才能赶上），复制可能会滞后。 （请记住，MySQL 具有三种复制模式：语句、行和混合。基于语句的从属服务器上执行完全相同的更新负载，基于行的只是发送更改的行，并且在 CPU 方面应该相当便宜）

所有您的从属服务器都足够快以应用更改，并且仍然有足够的 I/O 带宽和 CPU 时间来处理 SELECT，否则没有多少从属服务器会有所帮助。它可能的其他一些方法（例如，直接复制数据文件）可能更快，但更脆弱，实际上你说的是一些相对较小的收益。如果您无法处理更新负载，您对 MySQL 的选择是分片（拆分以便每个服务器只负责部分数据）或购买更快的硬件。

但归根结底，这一切都是在黑暗中拍摄。您可以相当轻松地从复制更改为 rsync，再更改为一些涉及 drbd 的疯狂方案，再更改为真正只影响您的数据库层的任何东西，可能只影响数据库本身。您需要实际的基准——实际数据——来做出这样的决定。我会告诉你，作为一般规则，设计合理的大型 OLTP 数据库首先会耗尽 I/O 带宽。

我建议从简单的开始。那将是单个数据库服务器或内置复制。请记住，有时可能需要分片。

实际上，您可能很早就想回答一个问题：您真的想使用 MySQL 吗？考虑 PostgreSQL。

Answer 3

您说“如果 MySQL 复制正在模仿服务器 1，那么这肯定会降低服务器 2 的速度，并产生与预期相反的效果。”

我认为这不会降低服务器的速度。您是否尝试过并测量了任何性能差异？我真的认为这是最适合您的方法，除非您清楚地衡量复制对性能的影响。

Answer 4

大量插入肯定会影响前端性能，但具体情况的答案取决于您的处理引擎如何影响资源。某些设置组合可以在不断插入数据的同时实现高性能的选择。这取决于您具体的占空比、存储引擎、索引方案等。

您首先要彻底了解表锁定http://dev.mysql.com/doc/refman/5.0/en/table-locking.html这是必须的！

然后您可以探索诸如 INSERT DELAYED http://dev.mysql.com/doc/refman/5.0/en/insert-delayed.html 之类的功能

并优化您的索引（尽可能少）以减少每次插入的影响http://dev.mysql.com/doc/refman/5.0/en/insert-speed.html

由于听起来您的需求是由大量数据增长（插入）驱动的，如果您无法从单个实例中获得所需的性能，复制可能无济于事。在这种情况下，您应该选择夜间加载场景。

我们有一个类似的用例，我们每晚进行批量加载，复制仅用于备份/故障转移目的。