Q1: XtraBackup不会复制二进制日志文件（mysql-bin.xxxxx），是否需要手动进行复制？[已解决] #

咱们先明确核心点：XtraBackup（包括它的封装工具innobackupex）默认不会自动复制二进制日志文件，要不要手动备份完全取决于你的备份恢复需求：

• 如果你的备份策略需要做时间点恢复（PITR）——比如要恢复到某一个具体的时间点，而不是全量备份的那个时刻，那你必须手动处理二进制日志：要么直接复制需要的二进制日志文件到备份目录，要么在备份完成后记录下当前的二进制日志位置（可以从备份目录里的xtrabackup_binlog_info文件获取，或者看innobackupex的输出日志），后续恢复时用这些日志来补全备份之后发生的事务。
• 如果只是做全量备份用于整体恢复数据库到备份时刻的状态，不需要精准到某个时间点，那完全不用手动复制二进制日志。

额外提个小技巧：如果要手动复制二进制日志，建议先执行FLUSH LOGS;命令让MySQL切换到新的二进制日志文件，这样复制之前的日志文件时就不会有写入操作干扰，保证日志文件的完整性。

Q2: 按教程操作后XtraBackup备份未达预期，已启用二进制日志，执行innobackupex+apply-log仍失败 #

因为你没说具体的报错信息，我给你列几个最常见的排查方向，你可以一步步检查：

1. 先看备份和apply-log的错误日志
   执行innobackupex的时候，一定要仔细看终端输出的内容，或者去备份目录里找xtrabackup_logfile文件，里面详细记录了备份和日志应用过程中的所有错误——比如权限不够、磁盘空间满了、InnoDB表有损坏，这些都会导致失败。

2. 确认二进制日志配置真的生效了
   登录MariaDB执行SHOW VARIABLES LIKE 'log_bin';，确认返回值是ON，同时去/var/log/mysql目录看看mariadb-bin系列文件是不是存在，并且有大小变化（说明正在写入）。另外，正常备份完成后，备份目录里应该会生成xtrabackup_binlog_info文件，里面记录了备份时的二进制日志文件名和位置，如果这个文件为空或者压根没生成，说明备份过程中没正确识别到你的二进制日志配置。

3. 检查apply-log的命令是否正确
   你执行innobackupex --apply-log的时候，有没有指定正确的备份目录？比如你的备份存在/backup/20240520_143000，那完整命令应该是：

   innobackupex --apply-log /backup/20240520_143000
   

   如果是增量备份的话，还要注意顺序：先对全量备份执行--apply-log --redo-only，再依次对增量备份执行同样的命令，最后再执行一次不带--redo-only的--apply-log，顺序错了肯定会失败。

4. 排查权限问题
   执行XtraBackup的用户（通常是mysql用户）有没有足够的权限？比如：

   • 能不能读取MySQL的数据目录（比如/var/lib/mysql）
   • 能不能读取二进制日志所在的/var/log/mysql目录
   • 能不能写入你的备份目录
     可以试试用sudo -u mysql innobackupex ...来执行备份，避免因为权限不足导致的各种问题。

5. 检查版本兼容性
   确认你的Percona XtraBackup版本和MariaDB版本匹配吗？比如MariaDB 10.6及以上版本需要用XtraBackup 8.0+的版本，版本不兼容的话，备份或者apply-log过程很容易出问题。

内容的提问来源于stack exchange，提问作者ibrasec