public void archiveMetaLog(final ServerName serverName) {
    try {
      Path logDir =
        new Path(this.rootDir, AbstractFSWALProvider.getWALDirectoryName(serverName.toString()));
      Path splitDir = logDir.suffix(AbstractFSWALProvider.SPLITTING_EXT);
      if (fs.exists(splitDir)) {
        FileStatus[] logfiles = CommonFSUtils.listStatus(fs, splitDir, META_FILTER);
        if (logfiles != null) {
          for (FileStatus status : logfiles) {
            if (!status.isDir()) {
              Path newPath = AbstractFSWAL.getWALArchivePath(this.oldLogDir, status.getPath());
              if (!CommonFSUtils.renameAndSetModifyTime(fs, status.getPath(), newPath)) {
                LOG.warn("Unable to move  " + status.getPath() + " to " + newPath);
              } else {
                LOG.debug("Archived meta log " + status.getPath() + " to " + newPath);
              }
            }
          }
        }
        if (!fs.delete(splitDir, false)) {
          LOG.warn("Unable to delete log dir. Ignoring. " + splitDir);
        }
      }
    } catch (IOException ie) {
      LOG.warn("Failed archiving meta log for server " + serverName, ie);
    }
  }
The hbase:meta region may OPEN and CLOSE without issue on a server and then move elsewhere. On
CLOSE, the WAL for the hbase:meta table may not be archived yet (The WAL is only needed if
hbase:meta did not close cleanaly). Since meta region is no long on this server, the
ServerCrashProcedure won't split these leftover hbase:meta WALs, just leaving them in the WAL
splitting dir. If we try to delete the WAL splitting for the server, it fail since the dir is
not totally empty. We can safely archive these hbase:meta log; then the WAL dir can be deleted.
@param serverName the server to archive meta log
hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterWalManager.java