我很难在项目中走上正确的道路。
我是一个预算紧张的单人乐队。 2个专用服务器 MySQL 5/php5
我正在使用服务器 1 从各种提要中获取大量数据。服务器/软件全天候运行，生成一个巨大的数据库。
服务器 2 - 持有一份副本 带有网络前端的数据库
我没有任何 MySQL 复制的经验。我一直在研究，据我所知，奴隶会在主人之后立即更新。
我想要一个非常快速的网站，所以处理是在服务器 1 上完成的，而服务器 2 只是选择数据。
如果 MySQL 复制模仿服务器 1，那么这肯定会减慢服务器 2 的速度并且产生与预期效果相反的效果。
我认为最适合这种情况的方法是编写一个脚本来自动化该过程。
服务器 2 有 2 个数据库。一个用于活体，一个用于加工。
该脚本确定哪个数据库处于事件状态，而是使用另一个数据库。
它会删除其中的所有表格。 该脚本从服务器 1 转储数据库。 将它安装在服务器 2 新清空的数据库上。 该脚本更改网站配置文件以利用新数据库。
这个过程可以一遍又一遍地重复。
虽然数据库安装会很大，但它可能会在晚上全部安装，这应该意味着没有停机时间。
这比做 MySQL 复制好吗？ 我会欢迎建议。
最佳答案
很难相信数据库转储/加载周期会比复制更快。特别是基于行(非查询)的复制。如果您不想在高峰时间复制(但当然您必须有足够的非高峰时间才能 catch )，复制可以滞后(通过在从站上运行 SLAVE STOP SQL_THREAD)。 (请记住，MySQL 具有三种复制模式:语句、行和混合。基于语句的在从属服务器上执行完全相同的更新负载，基于行的仅发送更改的行，并且在 CPU 方面应该相当便宜)
要么 所有 您的从站都足够快以应用更改，并且仍然有足够的 I/O 带宽和 CPU 时间来处理 SELECT，要么没有任何从站有帮助。它可能有一些其他方法(例如，直接复制数据文件)可能更快，但更脆弱，而且你实际上是在谈论一些相对较小的 yield 。如果您无法处理更新负载，您对 MySQL 的选择是分片(拆分以便每个服务器只负责部分数据)或购买更快的硬件。
但归根结底，这都是在黑暗中拍摄的。您可以很容易地从复制更改为 rsync，更改为涉及 drbd 的一些疯狂方案，更改为任何实际上只影响您的数据库层，可能只影响数据库本身的方案。您需要实际基准——实际数据——来做出这样的决定。我会告诉您，作为一般规则，设计合理的大型 OLTP 数据库首先会耗尽 I/O 带宽。
我建议从简单的开始。那将是一个单一的数据库服务器，或内置的复制。请记住，在某些时候可能需要分片。
实际上，您可能很早就想回答一个问题:您真的想使用 MySQL 吗？考虑 PostgreSQL。
关于php - MySQL 复制与其他技术，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7854544/