All the calls are executed with RPC inside the script, but will be explained as local calls for simplicity's sake. Example outputs have also been shortened, to keep this page concise.
We use ets:all() to retrieve a list of all the tables available at the node we're connecting to, example output should yield something like this:
Alternatively, ets:i() can be used to obtain more details about tables. Additional informations compared to ets:all() call include id, type, size, mem, owner.
>ets:i(). > id name type size mem owner----------------------------------------------------------------------------2031729 committed_tx set 1314<0.1580.0> 'snapshot_cache-502391187832497878132516661246222288006726811648' 'snapshot_cache-502391187832497878132516661246222288006726811648' set 1504<0.1966.0>...
Table information
The info function - ets:info(Tab) - displays detailed information about table Tab.
Assuming an Antidote instance is running at localhost 127.0.0.1, registered under name antidote, and your target dump directory is ./dump_dir/ (which will be created if it doesn't exist)
Important: The trailing / in the dump directory's name is necessary. ./dump_dir won't work, as it references a file according to unix conventions.
$cache_dump.erl'antidote@127.0.0.1',"./dump_dir/"
Logs
Logs in storage
Structure
Logs in storage only consist of log_operation :: log_operation() part, that is, tx_id, op_type, log_payload
Log files naming
Log file names come from key hashes, meaning that 123-456.LOG contains data relative to keys, where the first hashes to 123 and the last to 456, they're stored in $_build/default/rel/antidote/data/*.LOG
Key space partitions
Partitions are vnodes handling key spaces, routing keys are calculated with
This function returns an integer between 0 and 2^160 - 1. The obtained integer refers to a particular position in Riak Core as 160-bit circular key-space.
>dc_utilities:get_all_partitions()
Returns a list of all partition indices in the cluster.
sync_log parameter
sync_log, definable in src/antidote.app.src
true : local transactions will be stored on log synchronously, i.e. when the reply is sent the updates are guaranteed to be stored to disk (this is very slow in the current logging setup)
false : all updates are sent to the operating system to be stored to disk (eventually), but are not guaranteed to be stored durably on disk when the reply is sent
The trailing slash in dump_directory is required per unix conventions
How the script works
Connect with a redundant connection verification
Create, if needed, the dump directory specified in 2nd argument
Retrieve log files handles available at the node. Note that both local and distributed log handles are fetched, however the tool only processes the local logs
Prepare the dump filename, which respects following syntax for facilitated differentiation: log_dump-YEAR_MONTH_DAY-HOUR_MINUTE_SECOND.txt
The time values are fetched with Erlang's BIF: calendar:now_to_local_time(erlang:timestamp()).
The log files are treated sequentially in the alphanumerical order (i.e. as provided by disk_log:accessible_logs() call) and delivered following many-to-one scenario (all the logs are stored in a single dump file), in the directory specified as 2nd call argument.
Erlang terms formatting is maintained, in order to ensure compatibility with BIF functions used to reload records into memory. Notably the file:consult/1 and erlang:is_record/2,3. The former allows to parse a file and store its contents into Erlang records - assuming they're properly formatted - the latter verifies the record integrity
Turns out because of specific formatting used within Antidote, those BIFs do not work in this particular scenario.
Example log contents of a prepare and commit statements
