二进制日志必须开启（log_bin=on）且授权replication client权限，再通过mysqlbinlog指定文件名和位点远程拉取，拉取后需校验哈希并压缩。
二进制日志是否开启是远程备份的前提
没开 log_bin，mysqlbinlog 就什么都读不到。检查当前状态只需一条命令：SHOW VARIABLES LIKE 'log_bin';。返回 ON 才能继续；若为 OFF，必须修改 MySQL 配置文件（通常是 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf），在 [mysqld] 段落中加入：
log_bin = /var/lib/mysql/mysql-bin server_id = 123
注意：server_id 必须是非 0 整数，且在主从或备份环境中全局唯一；log_bin 路径需确保 MySQL 进程有写权限，且磁盘空间充足。改完必须重启 MySQL（systemctl restart mysql），仅重载配置不生效。
mysqlbinlog 远程读取需要账户有 REPLICATION CLIENT 权限
本地执行 mysqlbinlog --read-from-remote-server 时，连接的账号不能只有普通读写权限。常见报错是：ERROR 1227 (42501): Access denied; you need (at least one of) the SUPER or REPLICATION CLIENT privilege(s) for this operation。解决方法是显式授权：
GRANT REPLICATION CLIENT ON *.* TO 'backup_user'@'%' IDENTIFIED BY 'strong_pass';
如果还打算解析日志内容（比如做审计或恢复点分析），还需加 SELECT 权限——因为部分版本的 mysqlbinlog 在解析某些事件时会隐式查 mysql 系统库。别用 root 远程直连，最小权限原则在这里很关键。
远程备份命令要指定正确的 binlog 文件名和位点
mysqlbinlog 不会自动滚动下载所有 binlog，它只拉取你明确指定的一个文件（或从某一位点开始流式拉取）。典型安全做法是按时间+位点组合备份：
- 先查最新 binlog 名和结束位置：
SHOW MASTER STATUS;，记下File和Position - 再用如下命令拉取（示例中从位置 123 开始）：
mysqlbinlog --read-from-remote-server --host=192.168.1.100 --user=backup_user --password=strong_pass --result-file=/backup/binlog_20240520.sql mysql-bin.000007 --start-position=123 - 如需持续归档，建议配合
--stop-datetime或脚本轮询SHOW BINARY LOGS输出，避免漏掉刚生成但未被SHOW MASTER STATUS反映的新文件
漏掉一个 --start-position 或写错文件名，备份出来的 SQL 就可能不连续，后续基于该备份恢复时会报 Could not execute Update_rows event on table 类错误。
压缩与校验必须在传输后立即完成
binlog 文件体积大、内容敏感，直接存明文风险高。远程拉取后不要跳过校验步骤：
- 用
sha256sum记录原始 binlog 的哈希值（需先在服务端执行：sha256sum /var/lib/mysql/mysql-bin.000007） - 拉取完成后立刻比对：
sha256sum /backup/binlog_20240520.sql—— 注意：这是解析后的 SQL 文本，哈希值跟原始 binlog 不同，但同一份 binlog 多次解析结果应一致 - 生产环境建议用
gzip -c管道压缩传输：mysqlbinlog ... | gzip > /backup/mysql-bin.000007.sql.gz，节省带宽且降低磁盘 I/O 压力
很多人以为“能拉下来就等于备份成功”，其实网络中断、字符集不匹配（如服务端用 utf8mb4，客户端未设 --set-charset=utf8mb4）都会导致 SQL 文件损坏，而这种损坏往往到恢复时才暴露。
