MySQL报错MY-010602，远程处理复制日志文件不是目录的问题修复思路

MySQL报错MY-010602，其典型描述是“[ERROR] [MY-010602] [Repl] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed. Please use '--relay-log=name' and 'relay-log-index=name' options to avoid this problem.” 或者更直接的错误，指出无法创建或找到中继日志文件，因为它被识别为一个已存在的文件而非目录，这个问题通常发生在从库服务器上，核心症结在于中继日志（relay log）的路径配置不当，导致MySQL服务期望找到一个目录来存放日志文件，但系统却指向了一个普通文件,或者由于其他原因无法正确初始化中继日志目录。

修复思路可以按照以下步骤进行，从最简单、最直接的检查开始，逐步深入：

第一步：立即检查MySQL错误日志文件

这是最首要的行动，错误日志（通常位于MySQL的数据目录下，文件名为host_name.err或通过log-error参数指定）会提供最详细的错误信息，除了MY-010602这个错误代码，日志中通常会包含更具体的描述，例如无法创建哪个具体的文件（比如/var/lib/mysql/relay-log.index），以及系统返回的错误信息（如“Not a directory”），这能为你提供最直接的线索，告诉你问题具体出在哪个路径上，这是所有后续操作的基础,信息来源于MySQL服务器自身的运行时诊断。

第二步：检查并确认中继日志相关配置参数

连接到MySQL从库实例，或者查看MySQL的配置文件（通常是my.cnf或my.ini）,你需要重点关注以下几个参数：

1. relay-log：这个参数定义了中继日志文件的基础名称，如果没有明确设置，MySQL会默认使用服务器的主机名作为基础名称，这是导致问题的一个常见原因，因为如果主机名发生变化,中继日志的路径就会混乱。
2. relay-log-index：这个参数指定了中继日志索引文件的完整路径和文件名，索引文件是一个文本文件,里面按顺序记录了所有存在的中继日志文件的名字。
3. datadir：MySQL的数据目录，如果relay-log和relay-log-index使用的是相对路径，那么这个路径就是相对于datadir的。

你需要检查relay-log-index参数指向的路径，错误信息中提到的“不是目录”很可能就是指这个索引文件所在的父路径不存在，或者索引文件本身被误创建为了一个目录（这种情况较少见，但系统异常时可能发生），如果配置是relay-log-index = /var/lib/mysql/relay-log/relay-bin.index，那么你需要确认/var/lib/mysql/relay-log/这个路径是否存在,并且它是一个目录。

第三步：检查和修复文件系统上的路径与文件

根据第二步中查看到的配置,去服务器的文件系统上进行实地检查。

• 检查目录是否存在：使用命令行（如Linux下的ls -ld /path/to/directory）检查relay-log-index文件所在的父目录是否存在，如果不存在,这就是问题的根源。
• 修复目录不存在的问题：如果目录不存在，你需要以MySQL运行用户的身份（通常是mysql用户）创建这个目录，并确保该用户对该目录拥有读写权限。

  sudo mkdir /var/lib/mysql/relay-log
  sudo chown mysql:mysql /var/lib/mysql/relay-log
  sudo chmod 755 /var/lib/mysql/relay-log

• 检查路径是否为文件：如果错误日志明确提示某个路径“不是目录”，但该路径在文件系统上确实存在，那么它可能意外地被创建成了一个普通文件，本该是目录的/var/lib/mysql/relay-log可能是一个文件，使用ls -l命令查看其属性，如果它是一个文件，你需要先删除这个文件（在删除前，如果里面有重要数据，需要先备份或确认可删除），然后再重新创建为正确的目录,并设置好权限。
• 检查磁盘空间和inode：虽然不直接导致“不是目录”的错误，但磁盘空间耗尽或inode用尽也会导致创建目录或文件失败，使用df -h和df -i命令检查MySQL数据目录所在分区的空间和inode使用情况。

第四步：处理主机名变更带来的历史遗留问题

如果错误是由于服务器主机名变更引起的，并且你没有在配置文件中显式设置relay-log参数，那么问题会更复杂一些，因为MySQL之前可能已经以旧的主机名为基础名称创建了中继日志文件,仅仅创建目录可能不够。

1. 停止Slave复制：在MySQL中执行STOP SLAVE;。
2. 显式设置配置：在MySQL配置文件中明确设置relay-log和relay-log-index为绝对路径，避免未来再受主机名变化影响。

   relay-log=/var/lib/mysql/relay-log/relay-bin
   relay-log-index=/var/lib/mysql/relay-log/relay-bin.index

3. 清理旧文件中继日志：这是一个需要谨慎操作的点，你需要确定之前的旧中继日志是否还有用，如果复制中断不久，或者你打算重建复制，可以安全地删除它们，确认Slave已经停止，在数据目录下，删除所有以旧主机名开头的中继日志文件（如old_hostname-relay-bin.*）和旧的索引文件。更安全的做法是在MySQL内使用RESET SLAVE ALL;命令，它会清除所有复制相关的元数据，包括中继日志信息，但请注意，这个命令会完全重置复制状态，之后你需要用CHANGE MASTER TO重新配置主库信息。
4. 重启MySQL服务：在修改配置文件和清理文件后，重启MySQL服务,让新的配置生效。
5. 重新配置并启动复制：如果执行了RESET SLAVE ALL，你需要使用CHANGE MASTER TO命令重新指定主库的地址、用户、密码、日志文件和位置点，如果只是停止了Slave，那么直接START SLAVE;即可。

第五步：验证修复结果

重启MySQL服务后，再次查看错误日志，确认MY-010602错误是否消失，然后登录MySQL，执行SHOW SLAVE STATUS\G命令，查看复制状态，确保Slave_IO_Running和Slave_SQL_Running都是Yes（或Connecting）,并且没有新的错误提示。

总结一下核心思路：这个错误的修复本质上是解决一个路径配置问题，你需要像一个侦探一样，根据错误日志的线索，找到配置文件中指定的路径，然后去文件系统上核实这个路径是否“名副其实”——它必须是一个真实存在且权限正确的目录，而不是一个文件或不存在的路径，一劳永逸的方法是避免使用默认的主机名作为日志基础名，而是在配置中明确指定它们，整个过程需要细心，对文件的操作尤其要谨慎,最好在操作前进行备份。