MySQL主从复制无需Heartbeat账号；pt-heartbeat需独立监控账号，主库授SELECT/INSERT/UPDATE权限、从库仅需SELECT，均限于指定心跳表所在数据库，严禁跨库或ALL PRIVILEGES。
MySQL 主从复制本身不需要 Heartbeat 账号 —— 这是个常见误解。Heartbeat（指 Percona Toolkit 的 pt-heartbeat）是独立于 MySQL 复制机制的监控工具，它不依赖复制账号权限，而是需要一个能读写指定数据库、执行 SELECT/INSERT/UPDATE 的普通账号。
为什么不能复用 repl 复制账号
repl 账号只被授予 REPLICATION SLAVE 权限，该权限仅允许读取二进制日志，不包含任何表级 DML 权限。而 pt-heartbeat 必须在主库上定期 INSERT/UPDATE 心跳表，在从库上 SELECT 该表并比对时间戳。若强行用 repl 账号运行，会直接报错：
ERROR 1142 (42000): INSERT command denied to user 'repl'@'%' for table 'heartbeat'
所以必须单独创建监控账号，且权限粒度要精确控制：
- 主库：需
INSERT,UPDATE,SELECT权限（仅限心跳表所在数据库） - 从库：只需
SELECT权限（同样限定数据库） - 禁止授予
ALL PRIVILEGES或跨库权限，避免安全暴露
pt-heartbeat 监控账号的最小权限配置
假设使用数据库 bcp 存放心跳表（推荐专用库，不与业务混用），执行以下语句：
主库上创建账号并授权：
CREATE USER 'hb_monitor'@'%' IDENTIFIED BY 'strong_password_2026';<br>GRANT SELECT, INSERT, UPDATE ON bcp.heartbeat TO 'hb_monitor'@'%';<br>FLUSH PRIVILEGES;
从库上只需读权限（注意：不是 repl 账号，是另一个账号或同一账号但权限更小）：
GRANT SELECT ON bcp.heartbeat TO 'hb_monitor'@'%';<br>FLUSH PRIVILEGES;
关键点：
- 不要用
ON *.*—— 会暴露所有库，违反最小权限原则 - 表名必须明确为
heartbeat（pt-heartbeat默认建表名），不能用通配符 - 若生产环境限制 IP，把
'%'换成具体主库/从库 IP，例如'hb_monitor'@'192.168.1.11'
启动 pt-heartbeat 时如何验证账号权限是否生效
先在主库手动测试账号能否操作心跳表：
mysql -u hb_monitor -p -e "USE bcp; INSERT INTO heartbeat (ts) VALUES (NOW());"
再在从库查值是否同步过来：
mysql -u hb_monitor -p -e "SELECT ts, UNIX_TIMESTAMP() - UNIX_TIMESTAMP(ts) AS delay_sec FROM bcp.heartbeat ORDER BY ts DESC LIMIT 1;"
如果返回数值且 delay_sec 合理（比如 Access denied，立刻检查 SHOW GRANTS FOR 'hb_monitor'@'%' 输出是否匹配上述权限项。
容易忽略的兼容性细节
pt-heartbeat 在 MySQL 8.0+ 中默认要求账号启用 caching_sha2_password 插件，但部分旧版客户端可能不兼容。若连接失败，错误信息类似：
Authentication plugin 'caching_sha2_password' cannot be loaded
此时有两种选择：
- 主库创建账号时显式指定插件：
CREATE USER 'hb_monitor'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; - 或升级客户端到支持 caching_sha2_password 的版本（如 MySQL 8.0.4+ 客户端）
另外，pt-heartbeat 的 --daemonize 进程一旦启动，不会自动重连失效连接 —— 如果账号密码后期变更，必须手动 pt-heartbeat --stop 再重启，否则监控静默失效，这点常被遗漏。
