Database Reference
In-Depth Information
To enable Cassandra for auto commit log archiving and restore for recovery (supported
since 1.1.1.), the
commitlog_archiving.properties
file is used. It configures
archive_command
and
restore_command
properties. Commit log archival is
also referred to as write ahead log (WAL) archive and used for point-in-time recovery.
Cassandra's implementation is similar to Postgresql. Postgresql is an object-orien-
ted relational database management system (OORDBMS) that offers
wal_level
set-
tings with minimum as the lowest, followed by archive and
hot_standby
levels to
allow executing queries during recovery. For more details on Postgresql refer to
ht-
archive_command
Enable
archive_command
for implicit commit log archival using a command such
as:
archive_command= /bin/ln %path /home/backup/%name
Here
%path
is a fully qualified path of the last active commit log segment and
%name
is the name of commit log. The above-mentioned shell command will create a
hard link for the commit log segment (
%path
). If row mutation size exceeds
com-
mitlog_segment_size_in_mb
, Cassandra archives this segment using the
archive
command under
/home/backup/
. Here
%path
is the name of latest old
segment and
%name
is commit log file name.
restore_command
Leaving
restore_command
and
restore_directories
blank in
commit-
log_archiving.properties
during bootstrap Cassandra will replay these log
files using the
restore_command
:
restore_command=cp -f %from %to
Here
%from
is a value specified as
restore_directories
and
%to
is next
commit log segment file under
commitlog_directory
.
One advantage of this continuous commit log is high availability of data also
termed warm standby.
