Artur Kronenberg <artur.kronenberg <at> openmarket.com> writes:

> 
> So, looking at the code:
> 
>      public void maybeRestoreArchive()
>      {
>          if (Strings.isNullOrEmpty(restoreDirectories))
>              return;
> 
>          for (String dir : restoreDirectories.split(","))
>          {
>              File[] files = new File(dir).listFiles();
>              if (files == null)
>              {
>                  throw new RuntimeException("Unable to list director " + 
> dir);
>              }
>              for (File fromFile : files)
>              {
>                  File toFile = new 
> File(DatabaseDescriptor.getCommitLogLocation(), new 
> CommitLogDescriptor(CommitLogSegment.getNextId()).fileName());
>                  String command = restoreCommand.replace("%from", 
> fromFile.getPath());
>                  command = command.replace("%to", toFile.getPath());
>                  try
>                  {
>                      exec(command);
>                  }
>                  catch (IOException e)
>                  {
>                      throw new RuntimeException(e);
>                  }
>              }
>          }
>      }
> 
> I would like someone to confirm that, but it might potentially be a bug. 
> It does the right thing for an empty restore directory. However it 
> ignores the fact that the restore command could be empty.
> So for you, jonathan, I reckon you have the restore directory set? You 
> don't need that to be set in order to archive (only if you want to 
> restore it). So set your restore_directory property to empty and you 
> should get rid of those errors. The directory needs to be set when you 
> enable the restore command.
> 
> On a second look, I am almost certain this is a bug, as the maybeArchive 
> command does correctly check for the command to not be empty or null. 
> The maybeRestore command needs to do the same thing for the 
> restoreCommand. If someone confirms, I am happy to raise a bug.
> 
> cheers,
> 
> artur
> 
> On 11/12/13 14:09, Bonnet Jonathan. wrote:
> > Artur Kronenberg <artur.kronenberg <at> openmarket.com> writes:
> >
> >>
> >>      hi Bonnet,
> >>        that doesn't seem to be a problem with your archiving, rather with
> >>        the restoring. What is your restore command?
> >>        -- artur

Hello,

  As i told you i began to explore restore operations, see my config for
archive commit logs:

archive_command=/bin/bash /produits/cassandra/scripts/cassandra-archive.sh
%path %name

restore_command=/bin/bash /produits/cassandra/scripts/cassandra-restore.sh
%from %to

restore_directories=/produits/cassandra/cassandra_data/archived_commit

restore_point_in_time=2013:12:11 17:00:00

My 2 scripts 

cassandra-archive.sh:

bzip2 --best -k $1
mv $1.bz2 /produits/cassandra/cassandra_data/archived_commit/$2.bz2


cassandra-restore.sh:
cp -f $1 $2
bzip2 -d $2


  
For an example, at 2013:12:11 17:30:00 i had truncate a table which belong
to a keyspace with no replication on one node, after that i made a nodetool
flush. So when i restore to 2013:12:11 17:00:00 i expect to have my table
bein fill up again.

The node restart with this config correctly, i see my archive commit log
come back to my commitlogdirectory, seems bizarre to me that these ones
finish by *.out like CommitLog-3-1386927339271.log.out and not just .log.
Everything is normal ?

When i query my table now, this one is still empty. Finaly my restore
doesn't work and i wonder why ?

Do i have to make a restore on all nodes ? my keyspace have no replication
but perhaps restore need same operation on all node.

I miss something, i don't know.

Thanks for your help.





Reply via email to