我们即将将我们的数据库服务器复制到不同物理位置的多个从属服务器中.

正在为我们做复制的公司已经要求在我们的一个表上给他们一个sql select语句来检查滞后和延迟

SELECT id FROM table1 ORDER BY id DESC LIMIT 1

检查几个实例之间的滞后是否常见？

先感谢您.

解决方法:

目前还不清楚他们想要衡量什么.要查看网络延迟,他们只需要在操作系统中ping.这应该远远不到一秒,甚至到世界的另一边. (除非他们有一个草率的网络.)

Seconds_behind_master是有问题的.它对于DBA来说是一个方便的工具,但由于许多原因它可能是“错误的”.

>运行长查询时,它会显示查询在Master上启动的时间.因此,只要该查询在Slave上运行,Seconds_behind_master就会上升.
>如果你通过大量连接的大量写入来淹没Master,那么Slave就会“落后”.由于单线程Slave,这是拥塞,而不是因为网络滞后.

它可以说明一件事(我认为) – 如果时区不一致,或者它们没有良好的时钟同步(NTP).

SELECT不会通过复制传播,只会写入.所以,我认为你建议的SELECT没用.

如果您至少运行5.6.4：创建数据库和仅限于该数据库的登录(GRANT ALL ON db.* …).给他们用户名密码.让他们插入主人,看看奴隶中弹出了什么.我认为这是需要的(但我没有尝试过)：

-- Create on Master and propagate to Slave:
CREATE TABLE Timer (
    id INT NOT NULL,
    raw_time TIMESTAMP(6) NOT NULL,
    sys_time TIMESTAMP(6) NOT NULL,
    PRIMARY KEY(id)
) ENGINE=InnoDB;
-- Run on Master:
REPLACE INTO Timer (id, raw_time, sys_time) VALUES (1, NOW(6), SYSDATE(6));
-- Run on Slave:
SELECT * FROM Timer;

这两列的差异将说明延迟到底有多少 – 包括

> Master上的NOW和SYSDATE之间的微小延迟
>网络延迟
> Slave backlog(如果在复制REPLACE时Slave上运行了某些东西;可以通过使用多线程复制来最小化这个)

注意：(6)到处都可以获得微秒精度.这足以衡量复制越野的毫秒数.

注意：如果使用–sysdate-is-now运行,该技术将不起作用.

指出公司的答案;挑战他们顶尖.