当前位置: 首页 > solr, 搜索 > 正文

Solr复制:Unable to move index file from tempfile to indexfile

1 星2 星3 星4 星5 星 (2 次投票, 评分: 5.00, 总分: 5)
Loading ... Loading ...
baidu_share

SnapPuller是Solr复制用到的一个类,我对它做了一些修改,所以把它挪到我的代码里了。报错的代码片断如下:

private boolean copyAFile(final File tmpIdxDir, final File indexDir, final String fname, final List<String> copiedfiles) {
    final File indexFileInTmpDir = new File(tmpIdxDir, fname);
    final File indexFileInIndex = new File(indexDir, fname);
    final boolean success = indexFileInTmpDir.renameTo(indexFileInIndex);
    if (!success) {
      LOG.error("Unable to move index file from: " + indexFileInTmpDir
          + " to: " + indexFileInIndex);
      for (final String f : copiedfiles) {
        final File indexFile = new File(indexDir, f);
        if (indexFile.exists()) {
          indexFile.delete();
        }
      }
      delTree(tmpIdxDir);
      return false;
    }
    return true;
  }

错误现象表明,indexFileInTmpDir.renameTo(indexFileInIndex)失败了。在这个复制过程中,这种失败最大的可能性就是indexFileInIndex所在的indexDir不存在。查看索引数据目录,确实没有找到index.20101122031000文件夹。不过,从库的index.properties文件却记录“index=index.20101122031000”,也就是说,当前提供查询服务的索引目录就是index.20101122031000。查看进程打开的句柄,进程确实保持着index.20101122031000目录下的索引文件句柄,但它们也确实被删除了。

这里补充一下背景,搜索系统使用的是最新solr1.4.1版本,从库每5分钟同步一次主库。所以,当上面的错误出现以后,后续每5分钟就又会出现类似的错误,使得复制总是失败。Solr复制的部分原理是:从库默认的索引目录是index,在正常复制时,从库只是对该目录里的索引文件做修改(添加新的,删除旧的),但当从库索引提交点(IndexCommit)的generation大于主库时,会发生索引文件的全copy,也就是抛弃当前使用的索引目录,而是使用新生成的临时索引目录作为新的索引目录,并修改index.properties,临时目录的命名格式就是取当前的一时间戳(也就是bug所在,但到这里我还没发现这个bug)。

Solr wiki也有提到,从库的IndexCommit.generation大于的bad case就是外界对从库做了不适当的提交。而在我的系统里,这种现象是由于重建索引造成的,系统重建索引没有使用DIH,而是在不影响更新时单独线程重建,建完后覆盖旧的索引,这造成重建后的索引的generation会比从库小,所以每次重建从库都会使用新的索引目录。

回到这个问题上来,临时的解决办法就是重启从库,因为重启后从库读index.properties发现index.20101122031000并不存在,默认就会使用index目录的索引,而index目录的generation会和主库不一致,就产生全复制,短时间内恢复成最新的索引,但这样可能后续还会触发到bug。但问题并没有解决,我继续查看主从库的日志,再没有发现其他错误信息。而这个问题之前是没有出现的,所以可能是最近的什么操作引起的。而最近的操作就是老高22号凌晨重建了索引,我对照了重建完成时间,是凌晨3点多,而从库的index.20101122031000应该就是之后复制生成的。

google之错误信息,找到https://issues.apache.org/jira/browse/SOLR-1822,报bug的人出现和我一样的错误!!不过他也不清楚索引目录怎么没了,他是建议发现目录没了就新建一个,这也是可以曲线解决问题的(我想了一下,这种方法应该不会产生句柄泄漏)。可问题是,好端端的一个索引目录怎么就没了。我继续查看从库复制相关的log,发现在下午3点10分之前都是有正常的复制log的。初想一下,复制过程中发生删除的地方也就是和过期的IndexCommit相关联的索引文件被删除,但也不会删除目录阿!!!莫不是被系统外界下的黑手?

回家的地铁上就在琢磨,复制过程有删除目录的操作吗?有!!!复制的最后会删除临时目录!!!那会不会是临时目录和目标索引目录重名了,结果复制后把索引目录给删除了?回家再回看错误日志,这临时索引目录名称是:index.20101122031500,而出错当时是下午的15:15,而不是凌晨的03:15,查找创建临时索引目录的代码:

private File createTempindexDir(final SolrCore core) {
    final String tmpIdxDirName = "index." + new SimpleDateFormat(SnapShooter.DATE_FMT).format(new Date());
    final File tmpIdxDir = new File(core.getDataDir(), tmpIdxDirName);
    tmpIdxDir.mkdirs();
    return tmpIdxDir;
  }

SnapShooter.DATE_FMT的定义是:

1
public static final String DATE_FMT = "yyyyMMddhhmmss";

注意时间串格式中的小时是“hh”(范围是01-12)而不是“HH”(范围是00-23),这就造成从库如果在当天上午某个时间点全复制,而不幸的,在下午的相应时刻复制又来了,就使得临时索引目录和当前索引目录名称相同,而在复制的最后误删掉当前索引目录。从Bug效果来说,这绝对有破坏性,并且其真的是够低级的。
我后来check了solr的trunk,发现这个bug已经被修复了,log显示是:

r964312 | koji | 2010-07-15 14:32:22 +0800 (四, 2010-07-15) | 1 行
SOLR-1995: Use proper format for SimpleDateFormat

找到https://issues.apache.org/jira/browse/SOLR-1995,发现修复的初衷和我所出现的问题还不一样,它的破坏性也要小的多。话说又说回来,这个bug其实是很隐蔽的,触发的条件是:
1)从库要在当天的上午某点进行全复制,如果使用DIH复制,这种情况是不会出现的,而我的系统的全复制通常是在下午,所以之前没出现该问题。

2)下午的相应时刻也要发生复制,这要求复制间隔能被12小时整除(我的5分钟间隔中招了),并且当时主库的索引有更新变化(我的系统10多个库当时就有部分库就因为那个时间段没有更新而没有中招)。

本文固定链接: http://www.chepoo.com/solr-unable-to-move-index-file-from-tempfile-to-indexfile.html | IT技术精华网

【上一篇】
【下一篇】

Solr复制:Unable to move index file from tempfile to indexfile:等您坐沙发呢!

发表评论