MariaDB热备从库初始化：备份/恢复阶段能否不锁定主库？

嘿，这个问题绝对是搭建MariaDB热备时的高频痛点——谁也不想因为初始化从库就把主库锁成只读，影响业务写入对吧？

首先得说，文档里要求加FLUSH TABLES WITH READ LOCK是有原因的：这么做是为了保证你拷贝的主库数据，和记录的二进制日志位点完全一致。如果不加锁，备份过程中主库还在写数据，那你拿到的备份数据和日志位点就会“脱节”，从库恢复后从这个位点开始同步，肯定会丢数据，导致主从不一致。

但！完全不用全局读锁也能搞定，现在有更友好的方案：

• 用Mariabackup做在线热备份：这是MariaDB官方推出的工具，专门支持InnoDB引擎的在线热备，备份全程不需要加全局读锁，主库该怎么写就怎么写。操作流程大概是这样：

  1. 在主库执行备份命令：mariabackup --backup --target-dir=/your/backup/path
  2. 备份完成后，对备份文件做预处理，保证恢复后可用：mariabackup --prepare --target-dir=/your/backup/path
  3. 把预处理后的备份目录拷贝到从库对应的数据库路径
  4. 启动从库，然后用备份里自动记录的二进制日志位点（或者GTID）配置主从同步就行

• GTID配合备份工具（推荐）：如果你的MariaDB版本支持GTID（全局事务ID），那结合Mariabackup使用会更省心。备份工具会自动记录备份对应的GTID集合，从库恢复后直接设置主库地址和GTID同步起点，不用手动找日志文件和位置，全程也不需要锁主库，主从同步的一致性还更可靠。

• 如果是MyISAM引擎（不推荐）：要是主库还有MyISAM表，那在线备份工具可能没法完全避免锁表，因为MyISAM本身不支持事务级别的一致性备份。这种情况要么考虑把MyISAM转成InnoDB，要么只能在业务低峰期用文档里的读锁方案，尽量缩短锁表时间。

最后再提个醒：不管用哪种方案，从库恢复完之后，一定要做一次数据一致性校验，比如对比主从核心表的行数、用CHECK TABLE检查表结构完整性，确保没问题再正式开启同步。

备注：内容来源于stack exchange，提问作者LeGEC