MySQL复制速度

发布于 2024-08-02 05:32:24 字数 512 浏览 4 评论 0原文

假设我们在局域网上有 3 台服务器:

APP - php 应用服务器

MASTER - 主 Mysql 数据库服务器

SLAVE - 从属 Mysql 数据库服务器(复制 MASTER)

在一个代码块(php)中 APP 插入到 MASTER 中,检索 last_insert_id,然后使用它来选择刚刚从 SLAVE 插入的数据

所以问题是,复制是否能够及时发生以使SLAVE能够从MASTER获得数据?这是否受到 MASTERSLAVE 上的负载影响?

最后,如果可用数据存在问题,是否有办法确保从 SLAVE 接收最新数据?

Lets say we have 3 servers on a local area network:

APP - php app server

MASTER - master Mysql db server

SLAVE - slave Mysql db server (replicating MASTER)

In the one code block (php) APP inserts into MASTER, retrieving the last_insert_id which it then uses to select the data it just inserted from SLAVE.

So the question is, will the replication have happened in time for SLAVE to have the data from MASTER? Is this influenced by load put on either MASTER or SLAVE?

And lastly, if there is a issue with the data being available, is there a way to ensure the latest data is received from SLAVE?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

甚是思念 2024-08-09 05:32:24

由于 MySQL 复制时间是一个无法控制的变量(即使在正确的实现中,也可能会出现导致复制停止或阻塞的问题),因此最好不要依赖数据复制。您可以将问题分解为两种情况:

1)我是执行 CUD 操作的用户,我希望 R 操作后记能够反映我刚刚所做的更改。在这种情况下,您绝对需要从主服务器中提取数据,因为用户希望他的更改产生效果。

2) 我是外部用户,我不知道发生了 CUD 命令,而且我通常不关心,因此返回过时的数据是可以接受的(在 99% 的实现中,否则您可能不会使用 PHP* )。

#1 的替代方法是通知用户他的更改正在传播,并且在某些情况下是可以接受的,例如许多网站会告诉您 x 可能需要 y 分钟才能出现,这就是实际情况。

  • 如果您需要即时更新,您可以尝试写入与(可能不可靠的)数据库数据一起轮询的缓存层。像 memcached 这样的东西将是一个主要的候选者。

Because MySQL Replication time is an uncontrollable variable (even in proper implementations, problems can arise that stall replication, or block it up), it's best to not rely on the data replicating. You can break down the problem into two situations:

1) I'm the user doing a CUD operation, I expect the R operation afterwords to mirror the change I just made. In this case you absolutely need to pull the data off the master, because the user expects that his change had an effect.

2) I'm an outside user, I don't know that a CUD command happened and I generally don't care, so returning stale data is acceptable (in 99% of implementations, otherwise you probably wouldn't be using PHP*).

An alternative to #1 would be to inform the user that his change is propagating, and is acceptable in some situations, e.g. many websites will tell you that x may take up to y minutes to appear, this is this situation in action.

  • If you need instant updates, you could try writing to a cache layer that is polled along with the (potentially unreliable) DB data. Something like memcached would be a prime candidate.
木有鱼丸 2024-08-09 05:32:24

这取决于从属服务器从主服务器复制数据的速度。

如果它直接与 INSERT、UPDATE 和 DELETE 命令相关,这意味着当您插入某些内容时,您实际上是在两个命令上都插入它,很可能它在任何一个命令上都可用。

如果 SLAVE 服务器通过一个经常运行的任务来复制 MASTER,以从 MASTER 获取数据,这比每 1 个查询进行 2 个查询的成本要低,这意味着数据在任务执行之前不可用。跑了。

That depends on how fast your SLAVE server replicates data from your MASTER server.

If it is directly tied with the INSERT, UPDATE, and DELETE commands, meaning when you insert something, you are actually inserting it on both, most likely it will be available on either.

If the SLAVE server replicates MASTER by a task that is run every so often to grab the data from MASTER, which would be less costly than making 2 Queries for every 1 query, it would mean that the data isn't available until the task was ran.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文