Configure riak based to use multi backends
- eleveldb will be used as regular storage - bitcask with expiry set to 120, will be used for riak based locks
This commit is contained in:
Dmitry Shulyak
parent
86f4e0032d
commit
2117b09078
|
|
@ -82,134 +82,31 @@
|
|||
|
||||
%% Riak KV config
|
||||
{riak_kv, [
|
||||
%% Storage_backend specifies the Erlang module defining the storage
|
||||
%% mechanism that will be used on this node.
|
||||
{storage_backend, riak_kv_eleveldb_backend},
|
||||
|
||||
%% raw_name is the first part of all URLS used by the Riak raw HTTP
|
||||
%% interface. See riak_web.erl and raw_http_resource.erl for
|
||||
%% details.
|
||||
%{raw_name, "riak"},
|
||||
|
||||
%% Enable active anti-entropy subsystem + optional debug messages:
|
||||
%% {anti_entropy, {on|off, []}},
|
||||
%% {anti_entropy, {on|off, [debug]}},
|
||||
{anti_entropy, {on, []}},
|
||||
|
||||
%% Restrict how fast AAE can build hash trees. Building the tree
|
||||
%% for a given partition requires a full scan over that partition's
|
||||
%% data. Once built, trees stay built until they are expired.
|
||||
%% Config is of the form:
|
||||
%% {num-builds, per-timespan-in-milliseconds}
|
||||
%% Default is 1 build per hour.
|
||||
{anti_entropy_build_limit, {1, 3600000}},
|
||||
|
||||
%% Determine how often hash trees are expired after being built.
|
||||
%% Periodically expiring a hash tree ensures the on-disk hash tree
|
||||
%% data stays consistent with the actual k/v backend data. It also
|
||||
%% helps Riak identify silent disk failures and bit rot. However,
|
||||
%% expiration is not needed for normal AAE operation and should be
|
||||
%% infrequent for performance reasons. The time is specified in
|
||||
%% milliseconds. The default is 1 week.
|
||||
{anti_entropy_expire, 604800000},
|
||||
|
||||
%% Limit how many AAE exchanges/builds can happen concurrently.
|
||||
{anti_entropy_concurrency, 2},
|
||||
|
||||
%% The tick determines how often the AAE manager looks for work
|
||||
%% to do (building/expiring trees, triggering exchanges, etc).
|
||||
%% The default is every 15 seconds. Lowering this value will
|
||||
%% speedup the rate that all replicas are synced across the cluster.
|
||||
%% Increasing the value is not recommended.
|
||||
{anti_entropy_tick, 15000},
|
||||
|
||||
%% The directory where AAE hash trees are stored.
|
||||
{anti_entropy_data_dir, "/var/lib/riak/anti_entropy"},
|
||||
|
||||
%% The LevelDB options used by AAE to generate the LevelDB-backed
|
||||
%% on-disk hashtrees.
|
||||
{anti_entropy_leveldb_opts, [{write_buffer_size, 4194304},
|
||||
{storage_backend, riak_kv_multi_backend},
|
||||
{multi_backend_default, <<"eleveldb_mult">>},
|
||||
{multi_backend, [
|
||||
{<<"eleveldb_mult">>, riak_kv_eleveldb_backend, [
|
||||
{data_root, "/var/lib/riak/leveldb"},
|
||||
{anti_entropy, {on, []}},
|
||||
{anti_entropy_build_limit, {1, 3600000}},
|
||||
{anti_entropy_expire, 604800000},
|
||||
{anti_entropy_concurrency, 2},
|
||||
{anti_entropy_tick, 15000},
|
||||
{anti_entropy_data_dir, "/var/lib/riak/anti_entropy"},
|
||||
{anti_entropy_leveldb_opts, [
|
||||
{write_buffer_size, 4194304},
|
||||
{max_open_files, 20}]},
|
||||
|
||||
%% mapred_name is URL used to submit map/reduce requests to Riak.
|
||||
{mapred_name, "mapred"},
|
||||
|
||||
%% mapred_2i_pipe indicates whether secondary-index
|
||||
%% MapReduce inputs are queued in parallel via their own
|
||||
%% pipe ('true'), or serially via a helper process
|
||||
%% ('false' or undefined). Set to 'false' or leave
|
||||
%% undefined during a rolling upgrade from 1.0.
|
||||
{mapred_2i_pipe, true},
|
||||
|
||||
%% Each of the following entries control how many Javascript
|
||||
%% virtual machines are available for executing map, reduce,
|
||||
%% pre- and post-commit hook functions.
|
||||
{map_js_vm_count, 8 },
|
||||
{reduce_js_vm_count, 6 },
|
||||
{hook_js_vm_count, 2 },
|
||||
|
||||
%% js_max_vm_mem is the maximum amount of memory, in megabytes,
|
||||
%% allocated to the Javascript VMs. If unset, the default is
|
||||
%% 8MB.
|
||||
{js_max_vm_mem, 8},
|
||||
|
||||
%% js_thread_stack is the maximum amount of thread stack, in megabyes,
|
||||
%% allocate to the Javascript VMs. If unset, the default is 16MB.
|
||||
%% NOTE: This is not the same as the C thread stack.
|
||||
{js_thread_stack, 16},
|
||||
|
||||
%% js_source_dir should point to a directory containing Javascript
|
||||
%% source files which will be loaded by Riak when it initializes
|
||||
%% Javascript VMs.
|
||||
{js_source_dir, "/tmp/js_source"},
|
||||
|
||||
%% http_url_encoding determines how Riak treats URL encoded
|
||||
%% buckets, keys, and links over the REST API. When set to 'on'
|
||||
%% Riak always decodes encoded values sent as URLs and Headers.
|
||||
%% Otherwise, Riak defaults to compatibility mode where links
|
||||
%% are decoded, but buckets and keys are not. The compatibility
|
||||
%% mode will be removed in a future release.
|
||||
{http_url_encoding, on},
|
||||
|
||||
%% Switch to vnode-based vclocks rather than client ids. This
|
||||
%% significantly reduces the number of vclock entries.
|
||||
%% Only set true if *all* nodes in the cluster are upgraded to 1.0
|
||||
{vnode_vclocks, true},
|
||||
|
||||
%% This option toggles compatibility of keylisting with 1.0
|
||||
%% and earlier versions. Once a rolling upgrade to a version
|
||||
%% > 1.0 is completed for a cluster, this should be set to
|
||||
%% true for better control of memory usage during key listing
|
||||
%% operations
|
||||
{listkeys_backpressure, true},
|
||||
|
||||
%% This option specifies how many of each type of fsm may exist
|
||||
%% concurrently. This is for overload protection and is a new
|
||||
%% mechanism that obsoletes 1.3's health checks. Note that this number
|
||||
%% represents two potential processes, so +P in vm.args should be at
|
||||
%% least 3X the fsm_limit.
|
||||
{fsm_limit, 50000},
|
||||
|
||||
%% Uncomment to make non-paginated results be sorted the
|
||||
%% same way paginated results are: by term, then key.
|
||||
%% In Riak 1.4.* before 1.4.4, all results were sorted this way
|
||||
%% by default, which can adversely affect performance in some cases.
|
||||
%% Setting this to true emulates that behavior.
|
||||
%% {secondary_index_sort_default, true},
|
||||
|
||||
%% object_format controls which binary representation of a riak_object
|
||||
%% is stored on disk.
|
||||
%% Current options are: v0, v1.
|
||||
%% v0: Original erlang:term_to_binary format. Higher space overhead.
|
||||
%% v1: New format for more compact storage of small values.
|
||||
{object_format, v1}
|
||||
]},
|
||||
|
||||
%% Riak Search Config
|
||||
{riak_search, [
|
||||
%% To enable Search functionality set this 'true'.
|
||||
{enabled, true}
|
||||
]},
|
||||
{vnode_vclocks, true},
|
||||
{http_url_encoding, on},
|
||||
{fsm_limit, 50000},
|
||||
{object_format, v1}
|
||||
]},
|
||||
{<<"lock_bitcask_mult">>, riak_kv_bitcask_backend, [
|
||||
{data_root, "/var/lib/riak/bitcask"},
|
||||
{expiry_secs, 120}
|
||||
]}
|
||||
]}
|
||||
]},
|
||||
|
||||
%% Merge Index Config
|
||||
{merge_index, [
|
||||
|
|
|
|||
Loading…
Reference in New Issue