数据库之间的“专职快递员”：一文说透数据库（mysql，postgresql）流复制用户

一、先说清楚这东西到底是干啥的一句话流复制用户 专门给“数据库之间传数据”用的账号。它不是给人登录用的也不是给程序业务用的它的唯一工作就是——在两个数据库之间跑腿送数据。二、打个比方把 MySQL 集群想成连锁店想象一下你开了一家奶茶连锁店有一家总店主库生意最好所有新品研发、配方调整都在总店完成还有好几家分店从库/集群节点分布在城市的不同角落每天总店卖了什么、改了配方、更新了会员积分这些信息都必须实时同步给所有分店。不然分店还在卖上周的老配方顾客就要骂人了。那问题来了谁来负责这个“同步”的工作店员业务程序不行他们忙着招呼客人呢老板DBA 管理员也不行老板不可能天天来回跑着送数据所以你需要一个专职跑腿的快递员。这个快递员很特别他只干一件事把总店的“流水账”抄给分店他不能进仓库乱拿货不能乱改数据他不能收银不能干业务操作这个快递员用的工牌就叫“流复制用户”。三、在 MySQL 里这个快递员具体怎么干活在数据库的世界里这个账号的工作流程是这样的先连上总店主库把总店的操作记录binlog​ 一条一条地拉出来——就像总店每天记的流水账把这些记录原封不动地送到分店从库分店照着这些记录把自己这边的数据也改一遍说白了就是总店记了一本账 → 快递员每天把账本复印一份 → 分店照着抄一遍这样分店的数据就跟总店一模一样了。四、为啥不能用普通账号来干这活你可能想问我手头已经有一个账号了比如叫appuser密码是123456它本来就能连数据库为啥不能让它顺便干这个同步的活答案是千万别这么干会出大事。我给你列几个真实可能发生的惨案情况后果这个账号密码被改了主从同步立刻断掉分店数据全乱了有人用这个账号误删了数据分店也会跟着一起删全军覆没新来的同事不知道这是个同步账号随手一改配置整个集群崩了所以 DBA 的做法是专门建一个账号只给一个权限——“可以看主库的流水账”。这个账号通常叫repl全称是 replication复制一看名字就知道它是干嘛的。五、这个账号到底长啥样大白话版在 MySQL 里建这样一个账号只需要两行命令-- 第一行创建一个叫 repl 的用户只允许 10 开头的服务器连上来 CREATE USER repl10.% IDENTIFIED BY 强密码; -- 第二行只给一个权限——看主库的流水账 GRANT REPLICATION SLAVE ON *.* TO repl10.%;翻译成人话就是建一个叫repl的员工只允许 IP 地址是10.xxx.xxx.xxx的电脑来找它限制访问范围更安全只给它一个权限可以看主库的操作记录它不能查表、不能改数据、不能删库——啥也不能干只能抄作业六、它跟你之前遇到的 SSH 用户有啥区别很多人会把这两个搞混其实它们完全是两码事对比项SSH 用户流复制用户在哪​在服务器操作系统里在 MySQL 数据库里干啥用​运维人员装软件、改配置、跑脚本数据库之间同步数据走哪个门​走 22 号端口走 3306 号端口能不能删库​能权限很大不能只有看流水账的权限简单说SSH 用户​ 物业的万能钥匙能进大楼的任何房间流复制用户​ 只在大楼里送快递的连办公室的门都不能随便进七、再总结一次超简版流复制用户 数据库之间同步数据用的专用账号只负责“抄作业”不负责“写作业”它就像一个专职快递员只跑腿不干活只看账本不改账本有专门的工牌专用账号不能拿别人的工牌凑合用八、你现在的场景是哪种流复制用户在不同架构里都会用到但具体的配置方式略有不同。你现在是在搭建下面哪种架构主从复制一个主库带几个从库最常见MGR 集群MySQL Group Replication多个节点互相复制高可用InnoDB ClusterMySQL 官方推荐的自动化集群方案读写分离主库写、从库读分担压力你可以告诉我你现在的实际场景我给你出一张傻瓜对照表告诉你每一步该怎么配。九、互动时刻你第一次接触“流复制”是什么时候很多人在学 MySQL 的路上都会被“主从同步”“binlog”“复制账号”这些概念绕晕。你当初是怎么理解这些东西的有没有什么自己的“土办法”比喻欢迎在评论区聊聊你的故事。