银河麒麟V10 桌面版上装 MySQL 这件事最近被好多同事问过。业务方指定数据库必须是 MySQL而且要主从复制单独拆开都不复杂但放到国产 Linux 系统上坑一个接一个。这篇文章把我从下载安装包到主从复制跑通的完整过程记录下来命令直接抄配置直接复制只要你环境的 CPU 架构和系统版本跟文中一致基本能一次跑通。文中的方法不依赖你机器能不能访问外网——只要你能把官网的通用二进制包拷进内网离线一样能装。对于银河麒麟V10 这种系统源里没有官方 mysql-server 包的环境这是目前最省心、最可控的一条路。1. 为什么在银河麒麟V10上装MySQL要先解决“源”的问题很多人在国产系统上装软件第一反应就是apt install。但银河麒麟V10 的默认软件源里mysql-server这个包是不存在的有的只是mariadb-server。MariaDB 虽然是 MySQL 的分支但业务方如果明确要求“必须官方 MySQL”你用 MariaDB 顶上后面解释成本很高而且有些运维脚本、备份工具、集群方案对 MySQL 官方版本有依赖混着用很容易出幺蛾子。另一个常用办法是添加 MySQL 官方 APT 源。MySQL 官网确实提供了mysql-apt-config这种仓库配置包但它在麒麟系统上能不能顺利装上完全随缘。我这里遇到过两个典型问题一是仓库签名校验失败二是依赖解析冲突。尤其 arm64 架构飞腾、鲲鹏的机器官方 APT 源经常连二进制都找不到。如果你刚好拿到一台基于 Debian 系的 V10 变体问题会更明显。所以我的建议很直接放弃 apt 这条路用 MySQL 官方针对 Linux 发布的通用二进制包。这个包不依赖系统源glibc 2.17 以上就能跑x86_64 和 aarch64 都有对应版本安装方式就是解压、初始化、配置、启动。它唯一的缺点是初始化、配 systemd 这些事得手动做但这篇文章就是干这个的。在动手之前建议先花二十秒确认两件事cat /etc/os-release uname -m第一个命令看系统基于什么发行版第二个看 CPU 架构。uname -m输出x86_64就用 x86_64 的包输出aarch64就用 aarch64 的包这个千万别搞错否则会直接提示 Illegal instruction 或者无法执行。常见情况是银河麒麟桌面版 V10 基于 Ubuntu 20.04 或 Debian 系列但这不影响我们用通用二进制包的方案。三种安装方式的对比我简单列过一张表安装方式优点缺点适用场景apt install mariadb-server命令短装完就能跑不是官方 MySQL版本和目录结构有差异不挑数据库实现只求能用MySQL 官方 APT 仓库自动处理依赖和升级麒麟源兼容性差arm64 基本没戏基于 Ubuntu 且 x86_64运气好才顺利官方通用二进制包不依赖系统源架构全支持离线需要手动初始化和配置服务几乎所有场景特别是内网离线机我自己现在不管在麒麟、统信 UOS 还是纯 Ubuntu 上装 MySQL都默认用通用二进制包。这套流程练熟了换任何 Linux 发行版都是同一套操作不用每次去研究那个发行版的源里有没有 mysql。2. 二进制包安装MySQL的完整落地步骤2.1 下载、解压与目录规划去 MySQL 官网的 Downloads 页面选择 MySQL Community Server然后选 Linux - Generic。官网会提供 tar.xz 压缩包文件名类似mysql-8.0.40-linux-glibc2.17-x86_64.tar.xz mysql-8.0.40-linux-glibc2.17-aarch64.tar.xz下载之前注意一下 glibc 版本需求。最常见的通用包需要 glibc 2.17银河麒麟V10 基本都满足。如果真的在很老的系统上碰到version GLIBC_2.XX not found那就得换低版本 MySQL 或者用该发行版自带的 MariaDB但我实际遇到这种情况的概率很低。把包放到/opt目录下解压cd /opt tar -xJf mysql-8.0.40-linux-glibc2.17-x86_64.tar.xz mv mysql-8.0.40-linux-glibc2.17-x86_64 /usr/local/mysql我习惯把 MySQL 固定放在/usr/local/mysql然后通过软链或者 PATH 环境变量来调用。这样后续升级时只需要替换目录内容业务路径不用变。如果你机器上/usr/local空间不够放/opt/mysql也完全可以但后面所有命令里的/usr/local/mysql都要对应改。接着创建 mysql 系统用户和数据目录groupadd mysql useradd -r -g mysql -s /bin/false mysql mkdir -p /data/mysql chown -R mysql:mysql /data/mysql数据目录我没有用默认的/var/lib/mysql而是单独放在/data/mysql。原因很简单把数据目录独立出来方便单独挂载数据盘、做快照、扩容。万一系统盘满了或者系统重装数据目录还在恢复成本低很多。2.2 先写一份实用的 /etc/my.cnf很多教程是先初始化、再写配置但我建议反过来。初始化数据目录的时候 mysqld 会读取配置文件里的字符集、排序规则这些参数如果先初始化再改配置你可能需要重建数据目录才能让字符集改动完全生效。创建/etc/my.cnf内容如下[mysqld] basedir/usr/local/mysql datadir/data/mysql port3306 socket/tmp/mysql.sock pid-file/data/mysql/mysql.pid # 复制相关先开好后面不用返工 server-id1 log-binmysql-bin binlog-formatROW binlog-expire-log-seconds604800 # 字符集与时区 character-set-serverutf8mb4 collation-serverutf8mb4_0900_ai_ci default-time-zone08:00 # 连接设置 bind-address0.0.0.0 skip-name-resolve max_connections1000 [client] port3306 socket/tmp/mysql.sock default-character-setutf8mb4这里有几个参数我先解释一下后面基础配置章节还会细说server-id1和log-binmysql-bin是主从复制的命根子主库必须开从库作为主库的备份机可开可不开但为了以后主从切换方便建议都开。binlog-formatROW是我比较推荐的格式数据一致性最好。虽然日志量比 STATEMENT 大但现代磁盘和网络基本不在乎这点开销。bind-address0.0.0.0表示监听所有网卡主从复制场景必须这么配否则从库连不上主库。如果 MySQL 和应用在同一台机器只想本机访问可以改成127.0.0.1但主从复制时这句别这样写。写完后再把目录属主确认一次chown -R mysql:mysql /data/mysql2.3 初始化数据目录拿到 root 临时密码执行初始化命令/usr/local/mysql/bin/mysqld --initialize --usermysql --basedir/usr/local/mysql --datadir/data/mysql--initialize会让 mysqld 帮你建好全新的数据目录包括 mysql 系统库。初始化完成后日志里会打印一行 root 临时密码[Note] A temporary password is generated for rootlocalhost: 8HkLp2!x9F把这串临时密码记下来后面首次登录要用。如果屏幕上没看到就去数据目录下的.err文件里找grep temporary password /data/mysql/mysql.err注意.err文件具体名字和你的主机名相关也可以直接ls -l /data/mysql/*.err查看。很多朋友在这里会踩坑初始化没报错但启动服务的时候报[ERROR] --initialize specified but data directory exists。这是因为你之前手动执行过初始化或者datadir目录里已经生成了空文件。解决方法是把/data/mysql清空确保里面没有重要数据再重新初始化。2.4 注册 systemd 服务并设置开机自启mysqld 自带 mysqld_safe 方式但桌面版系统我更推荐注册成 systemd 服务开机自启、日志管理都方便。创建/etc/systemd/system/mysqld.service[Unit] DescriptionMySQL Server Afternetwork.target [Service] Usermysql Groupmysql Typesimple ExecStart/usr/local/mysql/bin/mysqld --defaults-file/etc/my.cnf LimitNOFILE65535 [Install] WantedBymulti-user.target然后执行systemctl daemon-reload systemctl enable mysqld systemctl start mysqld systemctl status mysqld注意 service 里Usermysql很重要mysqld 不允许用 root 身份直接跑如果你不带--usermysql参数启动它会自己切到 mysql 用户但权限配置不对反而容易出问题。显式指定用户是更稳的做法。启动后再确认一下 3306 端口在监听ss -lntp | grep 3306看到LISTEN 0 128 0.0.0.0:3306就说明服务起来了。2.5 首次登录改密码与安全加固用刚才记下的临时密码登录/usr/local/mysql/bin/mysql -uroot -p登录后第一件事改密码MySQL 8 要求密码不能太弱至少 8 位并包含大小写字母、数字和特殊字符ALTER USER rootlocalhost IDENTIFIED BY Root2024Strong;然后建议把 mysql 命令加入 PATH后面用起来方便echo export PATH/usr/local/mysql/bin:$PATH /etc/profile.d/mysql.sh source /etc/profile.d/mysql.sh之后直接敲mysql -uroot -p就能进客户端。安全加固方面官方提供了一条交互命令mysql_secure_installation。执行后它会依次问你是否设置密码校验强度、是否移除匿名用户、是否禁用 root 远程登录、是否删除 test 库、是否刷新权限。我的建议是匿名用户删掉test 库删掉root 远程登录禁止密码校验强度看场景。如果是内网测试环境密码校验强度可以选低一点否则你后面建业务账号时随便一个强度不够的密码都会被拒。3. 基础配置不只是“能连上就行”这些参数直接影响复制3.1 端口、监听地址与数据目录port3306是 MySQL 默认端口一般不用改。如果 3306 被别的程序占了可以换但改端口意味着所有客户端连接串、防火墙规则、从库的 MASTER_PORT 都要跟着改没必要就别动。bind-address0.0.0.0放开了所有网卡监听。这里有个安全权衡如果 MySQL 只给本机应用用127.0.0.1确实更安全但只要你有主从复制的需求就必须允许主库被从库访问这种情况下稳妥做法不是把 bind-address 改成具体 IP而是先把 MySQL 的账号权限控制好再从防火墙层面放行指定来源 IP 的 3306 端口。顺序不能反——你先把账号建得乱七八糟再把端口全放开那跟裸奔没区别。还有一个容易忽略的参数是skip-networking。这个参数一旦开启MySQL 就只监听 unix socket所有 TCP 连接全部失效。网上很多配置文件模板里会加它做安全优化但主从复制场景下千万别开。我排查过好几次从库连不上主库的问题最后发现是某个调优脚本把这个参数加进去了。3.2 字符集和时区必须落地字符集用utf8mb4不要用utf8。MySQL 的utf8实际上是 utf8mb3最多只能存 3 字节像 emoji 和一些生僻汉字存不进去会报Incorrect string value。而utf8mb4是完整的四字节 UTF-8也是 MySQL 8.0 的默认字符集。排序规则utf8mb4_0900_ai_ci是 MySQL 8.0 新增的支持 Unicode 9.0性能也更好。如果你之后要从 MySQL 5.7 迁移数据或者和 5.7 实例做主从建议排序规则统一用utf8mb4_general_ci兼容性更稳。但如果你都是 8.0 实例直接用utf8mb4_0900_ai_ci没问题。时区必须显式设置。很多机器系统时区是 CSTChina Standard Time但 MySQL 的system_time_zone可能不一定是 08:00。如果你不设置default-time-zonetimestamp 类型的字段存储和展示可能出现 8 小时偏差。在/etc/my.cnf里写死default-time-zone08:00也可以写成default-time-zoneAsia/Shanghai但前提是 MySQL 的时区表已经加载。用08:00这种偏移量写法最不容易出问题不依赖时区表。3.3 先把 binlog 和 server-id 开对后面复制才不用返工主从复制的核心就是 binlog所以从一开始就要把它配置好。log-binmysql-bin开启 binlog 后主库每次数据变更都会写一份二进制日志从库就是靠拉取这份日志来同步的。server-id用于标识每台 MySQL 实例的全局唯一 ID。一个复制环里每个实例的 server-id 必须不同否则从库会分不清日志从哪来。我见过有人图省事主库从库全用默认的server-id1结果 IO 线程一直报错还以为是网络问题。所以从库的 server-id 一定改成别的数字比如 2。binlog-formatROW是复制时的日志格式。ROW 格式记录的是“哪张表的哪一行的字段从什么值变成了什么值”比 STATEMENT 格式只记录 SQL 语句要更精确。缺点是 binlog 体积变大、占用磁盘不过对于现在的机器来说都可以接受。混合模式MIXED是折中但既然 8.0 已经对 ROW 格式做了很多优化我倾向于直接用 ROW省得后面遇到触发器、存储过程复制不一致的诡异问题。binlog 清理策略我习惯用binlog-expire-log-seconds604800代表 7 天。这个值不要太短尤其主从场景如果从库因为网络故障断了一两天再恢复binlog 已经过期被清了那从库就只能重新做全量备份恢复非常麻烦。3.4 连接权限、防火墙和 DNS 解析的关系建业务账号时我强烈建议按最小权限来。比如业务需要读写某个库就只授权那个库CREATE USER app_user192.168.1.% IDENTIFIED BY App2024; GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO app_user192.168.1.%;这里把host字段限制到内网网段192.168.1.%比%安全得多。%是所有主机都可以连接生产环境慎用。skip-name-resolve我默认打开。它让 MySQL 不再对客户端 IP 做反向 DNS 解析能明显减少连接耗时。但副作用是MySQL 里的账号 host 字段只能写 IP 或%不能写主机名。很多人打开了这个参数后发现原来用userlocalhost本地登录没问题但用usermyhostname连不上就是这个原因。我的建议是统一用 IP 规划账号别混用主机名。防火墙是主从复制最容易忽略的一环。麒麟桌面版可能没开防火墙但如果你之前手动开过 firewalld 或者 iptables得先把 3306 放行。firewalld 下firewall-cmd --zonepublic --add-port3306/tcp --permanent firewall-cmd --reload如果用的是 ufwufw allow 3306/tcp检查防火墙规则的命令是firewall-cmd --list-all排查的时候最直接的办法是从库上执行telnet 主库IP 3306如果能通说明网络和防火墙没问题如果超时问题基本就在防火墙或者云平台安全组上。4. 主从复制的完整配置流程4.1 复制链路怎么跑起来的先花一分钟把复制原理讲清楚后面排错会顺很多。主库上所有数据变更会按顺序写入 binlog从库上有两个线程在后台工作IO 线程负责连接主库把主库 binlog 里的内容拉到从库写到从本地的中继日志 relay logSQL 线程负责读取 relay log并重放这些日志操作到从库的数据文件里。打个比方主库每天写工作日报binlog从库雇了一个信使IO 线程去拿日报复印件放到自己桌面上relay log再雇一个抄写员SQL 线程照着日报内容把数据抄进自己的记录里。只要日报不停、信使和抄写员不请假两边数据就是一致的。所以从库的状态看两个线程Slave_IO_Running: Yes和Slave_SQL_Running: Yes两个都是 Yes 才表示复制链路健康。4.2 主库配置与复制账号主库的/etc/my.cnf中以下配置必须存在并正确server-id1 log-binmysql-bin binlog-formatROW binlog-expire-log-seconds604800修改配置后重启systemctl restart mysqld然后登录主库创建专门用于复制的账号。千万别用 root 来复制权限太大一旦账号泄露整个库都完蛋。复制账号只需要两个权限REPLICATION SLAVE和REPLICATION CLIENT。“REPLICATION CLIENT” 是给监控工具用的如果你不需要监控只保留 REPLICATION SLAVE 也够。CREATE USER repl% IDENTIFIED WITH mysql_native_password BY Repl2024; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl%; FLUSH PRIVILEGES;关于认证插件多说一句。MySQL 8.0 默认认证插件是caching_sha2_password如果你的从库也是 8.0直接用默认插件没问题。但如果从库是 5.7或者你后面用某些旧版客户端工具连接就得创建用户时显式指定mysql_native_password否则会报Authentication plugin caching_sha2_password cannot be loaded。我上面命令里已经加上了图个省事。接着查看主库当前的 binlog 位置SHOW MASTER STATUS;输出类似------------------------------------------------------------------------------- | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | ------------------------------------------------------------------------------- | mysql-bin.000001 | 154 | | | | -------------------------------------------------------------------------------记下File和Position这两个值后面从库执行 CHANGE MASTER TO 时要用。4.3 从库配置与初始数据同步从库的/etc/my.cnf中server-id 必须和主库不同其他复制参数保持相似server-id2 log-binmysql-bin binlog-formatROW relay-logmysql-relay-bin read_only1relay-logmysql-relay-bin是设置中继日志前缀默认叫hostname-relay-bin显式指定可以避免主机名变化导致日志文件混乱。read_only1能防止普通应用账号在从库写入数据避免主从数据不一致。注意它不影响 root 和复制线程所以 DBA 自己还是可以执行写操作。修改后重启systemctl restart mysqld接下来是主从配置里最容易出问题的一步初始数据同步。如果主库是全新的空库可以直接跳到下一节执行 CHANGE MASTER TO。但如果主库已经有业务数据必须先做一次全量备份恢复到从库然后再启动复制。顺序错了从库会从空状态开始追 binlog结果就是大量 1062 主键冲突直接中断。全量备份用 mysqldump建议加上--single-transaction这样可以在 InnoDB 引擎下不锁表完成备份/usr/local/mysql/bin/mysqldump -uroot -p \ --single-transaction --routines --triggers --events \ --all-databases --master-data2 /tmp/master_backup.sql--master-data2会把 CHANGE MASTER TO 位置信息作为注释写进备份文件头部方便你恢复后确认 binlog 位置。也可以不依赖它直接用上面 SHOW MASTER STATUS 得到的值。把备份文件传给从库scp /tmp/master_backup.sql 192.168.1.20:/tmp/在从库上执行恢复/usr/local/mysql/bin/mysql -uroot -p /tmp/master_backup.sql恢复完成后如果从库的 read_only 已经生效你只能以 root 身份导入但这里实际是在恢复期间直接用 root 执行的没问题。4.4 建立复制通道binlog 位置法登录从库执行 CHANGE MASTER TO 指定主库信息CHANGE MASTER TO MASTER_HOST192.168.1.10, MASTER_PORT3306, MASTER_USERrepl, MASTER_PASSWORDRepl2024, MASTER_LOG_FILEmysql-bin.000001, MASTER_LOG_POS154;这里的 IP、账号、文件名、位置号全部要和主库实际情况一致。MASTER_LOG_FILE和MASTER_LOG_POS必须对应SHOW MASTER STATUS里的值位置号写错或者文件写错IO 线程会直接报错。然后启动复制START SLAVE;查看状态SHOW SLAVE STATUS\G重点关注这几行Slave_IO_Running: Yes Slave_SQL_Running: Yes Seconds_Behind_Master: 0 Last_IO_Error: Last_SQL_Error:两个Yes 延迟为 0基本就算成功了。验证方法也很简单在主库建一张测试表插入一条数据到从库 SELECT 出来能看到就说明链路正常。4.5 更省心的方案GTID 自动定位复制binlog 位置法比较传统但有个明显的痛点如果从库宕机或者网络中断时间长了需要找到准确的 binlog 和 position 才能重新对齐。GTID全局事务标识符方式可以解决这个麻烦。GTID 会给每个事务分配一个全局唯一的 ID主从复制不再依靠“文件 位置”对齐而是靠事务 ID 自动对接。配置方法很简单主从两台机器的/etc/my.cnf都加上gtid_modeON enforce_gtid_consistencyON重启后主从都启用了 GTID。这时从库的 CHANGE MASTER TO 就不需要指定 binlog 文件和位置了改成CHANGE MASTER TO MASTER_HOST192.168.1.10, MASTER_PORT3306, MASTER_USERrepl, MASTER_PASSWORDRepl2024, MASTER_AUTO_POSITION1; START SLAVE;MASTER_AUTO_POSITION1的意思是从库会自动请求主库从自己缺失的 GTID 事务开始同步不用人工找位置。虽然 binlog 位置法仍然完全可用但新搭建的环境我强烈建议直接用 GTID。后期如果要主从切换、故障恢复GTID 能省掉一大半心思。需要注意一个问题如果你的主库从还没开 GTID 的状态想改成 GTID官方要求所有 MySQL 版本都推荐用在线方式平滑开启但实验环境简单粗暴一点就是主从都停掉、清掉旧的复制关系、改配置重启。第一次搭环境直接在配置阶段就把 GTID 打开是最省事的。5. 配置主从复制最容易翻车的几个点5.1 IO线程一直Connecting从网络到UUID的排查链路搭建完成后最让人焦虑的就是执行SHOW SLAVE STATUS\G看到Slave_IO_Running: Connecting这表示 IO 线程根本连不上主库或者连上但握手失败了。排查顺序我建议从简到繁第一步确认网络通不通。在从库上执行telnet 192.168.1.10 3306如果 telnet 不存在用nc -vz 192.168.1.10 3306这一步能过滤掉绝大多数防火墙、网络不通的问题。如果连不通回到第 3 章检查防火墙和 bind-address。第二步确认账号权限。用复制账号手动连接主库mysql -urepl -pRepl2024 -h192.168.1.10 -P3306能连上但执行SHOW DATABASES;什么都看不到很正常因为 repl 账号没有普通查询权限。只要能登录说明账号和密码没问题。第三步看详细错误。SHOW SLAVE STATUS\G里Last_IO_Error会给出具体原因。常见报错有Master and slave have equal MySQL server UUIDs这是虚拟机克隆最常见的问题——从库是主库克隆来的/data/mysql/auto.cnf里保存的 server-uuid 一模一样。这时在从库删除这个文件重启 mysqld让它重新生成 UUIDsystemctl stop mysqld rm -f /data/mysql/auto.cnf systemctl start mysqldAuthentication plugin caching_sha2_password reported error前面说过创建复制账号时指定mysql_native_password或者升级客户端驱动。Access denied for user repl...复制账号的 host 范围没覆盖从库 IP。CREATE USER repl%的%覆盖所有 host如果你把它写成了具体 IP就检查从库实际出口 IP 是否匹配。5.2 SQL线程报错1062主键冲突、中继日志损坏如果Slave_IO_Running: Yes而Slave_SQL_Running: No说明日志拉回来了但重放失败。最常见的错误码是 1062主键冲突Last_SQL_Error: Could not execute Write_rows event on table mydb.t_user; Duplicate entry 1001 for key t_user.PRIMARY出现 1062 的根本原因是从库上已经有一条相同主键的数据但主库又插入了一次复制线程没法重复插入。这通常是因为从库在复制启动之前被手动写过数据或者初始数据备份时没有锁住主库导致数据不一致。如果确认只是少数几条错误并且业务可以容忍跳过可以执行STOP SLAVE; SET GLOBAL sql_slave_skip_counter 1; START SLAVE;sql_slave_skip_counter 1会让 SQL 线程跳过当前一条事务。注意是一次跳一个事务不是跳过一行记录。如果错误很多一条条跳不现实还是老老实实重建从库更干净。有时候 SQL 线程报的是中继日志损坏比如relay log read failure。这种情况下不要硬修直接清理从库复制状态重建STOP SLAVE; RESET SLAVE ALL;然后回到第 4 章重新做 CHANGE MASTER TO 和 START SLAVE。如果是从库数据已经彻底乱了就得重新导一次全量备份回头重新走初始化流程。这确实是笨办法但在实验环境里往往比重试更快。5.3 从库被误写入导致复制中断的恢复我印象最深的一次事故是开发同学在从库上手动执行了一条 UPDATE把某张表的状态字段改了。结果主库对应记录也更新了复制线程重放时发现从库的值已经变掉了不管怎么重放都对不上。这种“人为写入从库”造成的数据冲突没有完美的自动修复方案。最稳妥的办法是重建从库在主库重新做一次一致性备份传到从库恢复从库清空复制关系再重新指向主库。整个过程在业务低峰期做几分钟就能完成。如果你确认冲突可以忽略或者只是测试环境想快速让复制跑起来再考虑用sql_slave_skip_counter跳过。但生产环境我一定不建议这么干因为跳过之后从库数据和主库会存在隐藏的不一致后面排查问题会更痛苦。预防远比修复重要。read_only1必须开在从库上同时从库的业务账号绝对不能授予 SUPER 权限。普通账号只有 SELECT 权限更好虽然业务需要读但从库完全不需要写入口。5.4 一键巡检主从状态的核心命令我自己不管搭哪套主从都会写一个简单的巡检脚本核心就是这两条命令的检查mysql -uroot -pXXX -e SHOW SLAVE STATUS\G | grep -E Slave_IO_Running|Slave_SQL_Running|Seconds_Behind_Master|Last_IO_Error|Last_SQL_Error输出里两个 Running 是 Yes、延迟值不高就说明复制在正常跑。如果拦截到 Last_IO_Error 或 Last_SQL_Error 非空再用脚本自动发告警。更进阶的巡检可以对比主从两边的事务位置SHOW MASTER STATUS;SHOW SLAVE STATUS;观察Master_Log_File和Read_Master_Log_Pos是否持续增长。如果Read_Master_Log_Pos长时间不增长说明 IO 线程可能已经断了。6. 主从复制跑起来之后的日常维护6.1 从库的read_only、备份与延迟监控从库不只是个冷备机正确用法是承担备份和只读查询。read_only1已经限制了普通账号写入所以可以放心把报表查询、数据导出这些只读业务切到从库减轻主库压力。备份优先在从库上做这样不会影响主库的读写性能。mysqldump 命令和前面主库备份基本一样只是不加--master-data2也行。如果是每天全量备份用 cron 定时执行0 2 * * * /usr/local/mysql/bin/mysqldump -uroot -pXXX --single-transaction --routines --triggers --all-databases | gzip /data/backup/mysql_$(date \%F).sql.gz延迟监控主要看Seconds_Behind_Master。注意这个字段是 SQL 线程执行的时间差估算值不能完全代表数据一致性但作为日常告警足够。如果这个值持续上涨常见原因有从库机器性能比主库差、主库有大事务一次 UPDATE 几十万行、从库磁盘 IO 慢。还有一种隐藏情况主库有大量并行事务从库默认是单线程重放速度跟不上。MySQL 8.0 默认开启了多线程复制replica_parallel_workers默认值是 4一般不用动。如果延迟严重可以调大一点但要结合从库 CPU 核数谨慎调整。6.2 binlog清理策略与磁盘空间binlog 占的磁盘空间比想象中大尤其 ROW 格式下一条 UPDATE 可能产生几 MB 日志。不清理的话/data分区早晚被填满MySQL 会因为无法写 binlog 直接挂掉。自动清理靠配置binlog-expire-log-seconds6048007 天是合理值。如果你的从库经常连续宕机好几天这个值可以再调大比如 14 天代价是磁盘占用翻倍。手动清理可以用PURGE BINARY LOGS TO mysql-bin.000010;意思是清理到这个文件之前的日志。注意不要用RESET MASTER那个会把所有 binlog 清光并重置从库会彻底断掉复制。清理 binlog 的同时要盯着主从延迟。理想情况是从库已经追平所有日志再清理才安全。如果从库延迟还有几个 G 的日志没追完主库这边 binlog 已经被清掉从库就会报错The slave I/O thread stops because master and slave have equal MySQL server UUIDs或者 1236Could not find first log file name in binary log index这时候只能重新全量恢复从库。6.3 故障切换的基本思路主库宕机后把从库提升为主库是标准操作但不要慌着手动点。基本步骤是这样的确认从库复制已经追平Seconds_Behind_Master为 0。如果没追平数据会有丢失。在从库执行STOP SLAVE; RESET SLAVE ALL;断开从库的复制关系。如果从库配置了read_only1改为读写SET GLOBAL read_onlyOFF;确认从库自身开了 binlog 且 server-id 全局唯一这样它才能继续给新的从库提供日志。修改应用连接串把数据库 IP 切到原从库。跑过一次切换之后你会体会到 GTID 的好处。如果最初用的 binlog 位置法新主库提升后原来的主库如果修复回来了重新接入复制时还要再找一次 position而 GTID 模式下只要两边都开了 GTID直接用MASTER_AUTO_POSITION1就能重新对齐基本不用人工干预。关于故障切换我的建议是实验环境必须演练一到两次别等到真出故障了再查资料。重点演练两个环节一是从库追平判定二是应用连接切换。很多团队栽就栽在从库延迟没追平就把流量切过去了数据丢了几千条后面恢复起来非常麻烦。这些步骤我在麒麟桌面V10上完整走过一遍期间踩得最深的就是克隆虚拟机的 server-uuid 重复和防火墙没放行 3306。你如果按这篇的顺序操作基本能绕开我踩过的坑。最后再提醒一句生产环境做主从务必先备份、再变更测试环境出了问题直接把从库重建一次往往比重试和修数据快得多。
