Make sure mem3_rep autocreates target shards

The change to our fancier history entries introduced a regression that
internal replication wouldn't automatically create the target shards.
This fixes the issue by adding a get_or_create_db/2 in mem3_rep and
switches the use of couch_db:open_int/2 to that function.

Pass ADMIN_CTX when opening dbs

COUCHDB-3016

Add read_concurrency option to mem3_shards table

This table sees a great deal of activity from various subsystems -
turning on read_concurrency should be a win.

COUCHDB-2984

Use ets:select/2 to retrieve shards by name

The result of mem3_shards:for_db/1 on databases with high q values can
be very large, resulting in suboptimal performance for high-volume
callers.

mem3_sync_event_listener is only interested in a small subset of the
result of mem3_shards:for_db/1; moving this filter in to an ets:select/2
call improves performance significantly.

COUCHDB-2984

Reduce frequency of mem3_sync:push/2 calls

In high-throughput scenarios on databases with large q values the
mem3_sync event listener becomes overloaded with messages due to the
poor performance of the shard selection logic.

It's not strictly necessary to sync on every update, but we do need to
be careful not to lose updates by keeping history too naively. This
patch adds a configurable delay and push frequencyto reduce pressure on
the mem3_sync event listener.

COUCHDB-2984

Refactor mem3_sync events to dedicated module

COUCHDB-2984

Revert "Remove maintenace modes from ushards"

This reverts commit deed2f0eb15d634a643312e71e343c1e19e1b07e.

COUCHDB-2953

Remove maintenace modes from ushards

Maintenance mode nodes were being served for ushards and this lead to
nodedown errors. We now only serve non-maintenance mode nodes.

COUCHDB-2953

Don't start couch_log app if we don't use it

This makes no sense since we mock it, but causes unwanted troubles
with config startup dependency.

Return HTTP 405 for unsupported request method

Merge remote-tracking branch 'cloudant/fix-eunit-couch-log'

Fix EUnit tests.

 Need couch_log. In one case mock it becuase no other apps are started.

 In another use application:ensure_all_started() -- R16B02+ feature.

Pass supervisor's children to couch_epi

Fix code formating

Fix typo in behaviour name

Update to new couch_epi API

Fix crypto deprecations

COUCHDB-2825

Use dynamic http handlers

We use dynamic http handlers for:

  - `_membership`
  - `_shards`

reformat to 80 chars/line

change readme for the couchdb project

add license file

Merge remote-tracking branch 'kxepal/rename-system-databases'

This closes #6

Add underscore prefix for nodes and dbs database names

That's how we name system databases and there should be no exceptions.

COUCHDB-2619

Rename "shard_db" option to "shards_db" and "node_db" one to "nodes_db"

COUCHDB-2628

Merge remote-tracking branch 'iilyak/2561-make-config-API-consistent'

This closes #5

COUCHDB-2561

Don't restart event handler on termination

COUCHDB-2561

Update config_listener behaviuor

COUCHDB-2561

Use ADMIN_CTX macro from couch_db.hrl

Update mem3 for new changes API

Delete mem3_rebalance for now, currently useless

Add and export n/2

fix stats paths

open dbs, nodes as sys dbs

Update to use couch_stats

Replace twig with couch_log

Update mem3_rebalance to work with couch_mrview

Remove mem3_util:owner

Get the shard suffix for a given database

This grabs the shards for the given database name, and then pulls out
the first shard and extracts out the suffix. mem3:shards is ets
backed, so in the general case this should be fast.

BugzId: 29571

Allow mem3_shards:local to take a list or binary

BugzId: 29571

Fast forward internal repl. between file copies

In the case where two files have the same UUID we can analyze epoch
information to determine the safe start sequence.

BugzID: 27753

Avoid decom:true nodes when fixing zoning

This patch prevents mem3_rebalance:fix_zoning from suggesting moves
onto nodes that are flagged with "decom":true.

BugzID: 26362

Refactor mem3_rpc:add_checkpoint/2

This is based on Adam Kocoloski's original add_checkpoint/2 but uses a
body recursive function to avoid the final reverse/filter steps.

BugzId: 21973

Write plan to /tmp/rebalance_plan.txt

Was a request by @mattwhite to help with automation.  I was fairly
sloppy in the implementation here, could leave this off and do a better
job next time.

Allow target_uuid prefixes in find_source_seq

Since sequence values only contain UUID prefixes so we need to account
for that when locating the replication checkpoints.

BugId: 21973

Include replication history on checkpoint docs

This changes how and what we store on internal replication checkpoint
documents. The two major changes are that we are now identifying
checkpoint documents by the database UUIDs (instead of the node that
hosted them) and we're storing a history of checkpoint information to
allow us to be able to replace dead shards.

The history is a list of checkpoint entries stored with exponentially
decreasing granularity. This allows us to store ~30 checkpoints covering
ranges into the billions of update sequences which means we won't need
to worry about truncations or other issues for the time being.

There's also a new mem3_rep:find_source_seq/4 helper function that will
find a local update_seq replacement provided information for a remote
shard copy. This logic is a bit subtle and should be reused rather than
reimplemented.

BugzId: 21973

Inline open_doc_revs into open_docs

This function was trivial and never reused. It was more confusing to
have it as a separate function rather than just inlining into where it's
used.

Add a new mem3_rpc module for replication RPCs

This is intended to make the local/remote code execution contexts a lot
more clear.

Reorder functions into a logical progression

This just moves functions around in the mem3_rep module to give a better
logical progression. Purely stylistic but it should make things easier
to read and find.

Update whitespace and exports formatting

Remove old code_change, set module version to 1

Allow for rebalancing "special" DBs

For example, _replicator or _users.

BugzID: 24612

Suggest moves from all donor nodes in parallel

Previously the generator would suggest all moves from the first node
before moving onto the second one.  In the case where the quantum of
jobs is much smaller than the number of moves per node this results in
the other donors being neglected for long periods.

BugzID: 24612

Allow targets to exceed floor, add another check

Sometimes we want to transfer a shard to a target even though it's
already at the floor.  We add another check to make sure we're not
wasitng effort -- the difference in shard counts between the source and
the target must be 2 or greater.

We also refactor the global shard count code to avoid future atom /
binary problems.

BugzID: 24466

Refactor global candidate selection

The old approach was getting unwieldy, hopefully this makes the tests
more explicit.

BugzID: 24466

Stop donating once the target level is achieved

Also switched to a record accumulator for clarity.

BugzID: 24466

Fix two bugs in the global balancing phase

* Nodes with 0 shards were being ignored because wrong datatype.
* The limit was being ignored because max not min.

BugzID: 24680

Allow skip straight to global phase

When rebalancing a DB-per-user cluster with small Q values its typical
that

a) the local phase takes a loooong time, and
b) the local phase doesn't suggest any moves

While the local phase should still run at least once, we'll expose a
flag to skip straight to the global phase since we'll need to run the
plan generator many many times and we can't afford to wait.

BugzID: 24680

Refuse to place shards on decom:true nodes

BugzID: 24420

Rely on decom:true attribute to filter decom nodes

BugzID: 24420

Ensure that the owner of a doc is also a host

BugzID: 24395

Rewrite rebalancing plan generator

This patch splits the functionality of the module out into three
classes or work:

* Fixing zoning and replica level violations
* Contracting a cluster
* Rebalancing shards across a cluster

The implementations of the first two features are pretty similar - find
the shards that need to be moved, then choose an optimal home for each
of them.  By default the contraction code will remove shards from nodes
in the "decom" zone, and the rebalancing code will ignore that zone
entirrely. An optimal home is a node that

a) is in the correct zone, and
b) has the fewest # of shards for the DB among nodes in the zone, and
c) has the fewest total # of shards among nodes satisfying a) and b)

The implementation of rebalancing is a bit more complicated.  The
rebalancing algorithm looks roughly like this

For DB in all_dbs:
    Ensure all nodes have at least (N*Q) div length(Nodes) shards
    Ensure no node has more than (N*Q) div length(Nodes) + 1 shards
For node in nodes:
    If node has more than TotalShards div length(Nodes) + 1 shards:
        Donate shard to another node

The net result is that each database is balanced across the cluster and
the cluster as a whole is globally balanced.

The current version of the module prints out shard move and copy
operations in a clou-friendly format via io:format.  It also returns a
list of {Op, #shard{}, node()} tuples representing the operations.

The rebalancer will stop after generating 1000 operations by default.
The limit can be customized by using the 1-arity versions of expand,
contract and fix_zoning, but note that the performance of the rebalancer
degrades as the number of pending operations increases.

BugzID: 23690
BugzID: 20770

Fix latent single-shard range hack

We had an off-by-one error when we fake #shard{} records for node local
databases. This fixes the issue. The bug was noticeable when attempting
to pass these shards to `fabric_view:is_progress_possible/1`.

BugzId: 22809

Use a consistent commenting syntax

Address comments from PR

Ensure all shards are moved off non-target nodes

BugzID: 20742

Stabilize mem3_util:owner/2

BugzID: 21413

Move rotate_list to mem3_util

Support balancing across a subset of nodes

mem3_balance implicitly assumed the set of nodes over which the DB is
hosted is expanding.  We need to make a couple of small changes in the
case of cluster contraction.

BugzID: 20742

Fix load_shards_from_disk/2

load_shards_from_disk/2 did not expect #ordered_shards to be returned
from load_shards_from_disk/1. Since it uses a list comprehension the
mistake is silently squashed, resulting in an empty list.

In production this manifests are the occasional failure, where 'n' is
calculated as 0, causing quorum reads to fail. The very next call
succeeds as it reads the cached versions and correctly downcasts.

BugzID: 20629

Preserve key and incorporate range into rotation key

we're not rotating by DbName any more

refactor choose_ushards

Zero out shard caches on upgrade

The mix of #shard and #ordered_shard records breaks ushards.  Different
nodes can start returning different results.

Add function to assist with rebalancing

This function takes either a database name or a list of shards and a
list of target nodes to balance the shards across. Every node with
less than a fair share of shards will steal shards from the node with
the most shards as long as both shards are in the same zone.

BugzID: 18638

Use a private record for event listener state

Fix trivial typo

Balance replication ownership across nodes

The previous algorithm was biased towards low-numbered nodes, and in the
case of a 3 node cluster would declare db1 to be the owner of all
replications.  We can do better just by leveraging the existing
ushards code.

There's a possibility to refactor this as a new ushards/2 function if
that's perceived as useful.

BugzID: 19870

Update to use the new couch_event application

Choose ushards according to persistent record

The order of nodes in the by_range section of "dbs" documents is now
promoted to the principal order for ushards. Ushards still accounts
for Liveness, selecting the first live replica and still supports
Spread by rotating this list using the CRC32 of the database name
(since many databases will have the same layout).

If by_range and by_node are not symmetrical then by_node is used and
order is undefined to match existing behavior.

If two shards differ we need to sync

There's no security if two shards return different answers but it gives
us enough of a signal to know that we need to trigger a full on
synchronization.

BugzId: 18955

Moving shard maps _membership endpoint to _shards db handler

Add doc shard info endpoint

Fix _membership/$DBNAME api endpoint

This switches the JSON key to be a binary, as required by jiffy.

Also, remove extraneous <<"parts">> path from the url.

Show full shard range.

Update to use new multi rexi_server protocol

Handle the #doc_info case in changes_enumerator

This is to handle the special case where the user migrates a CouchDB
database to BigCouch and they have not yet compacted the
database. Once the database has been compacted, this #doc_info clause
should never be encountered.

Don't log when ensuring dbs exist

Add function to determine shard membership locally

mem3:belongs/2 allows you to determine if a given doc id belongs to a
given shard (whether a #shard{} record or just the filename of a
shard) without looking up the shard map or making any remote
calls.

Change API to function per level

Switch to couch_log

Add license headers

Add ejson_body to all mem3 open_doc attempts that need it

Remove references to margaret

Build with rebar

Fix up copyright headers

New build system for mem3

Remove Cloudant build system remnants

Merge pull request #43 from cloudant/guard-against-empty-list

Guard against empty list

Guard against empty list

Rotating an empty list gives badarith so add a guard clause, since the
result of rotating an empty list is well known.

BugzID: 17801

Merge pull request #42 from cloudant/17801-spread-the-pain

BugzID: 17801

Spread ushards load to more nodes

In some cases, notably q=1 databases, the current ushards algorithm
will always choose the same replica (because of the lists:sort and
order-preserving orddict). This causes a severely skewed load profile
if you have lots of these cases.

This patch rotates each group of nodes using the crc32 of the database
name, spreading out the load pretty evenly.

The patch is a little obscure because ushards still has remnants of
previous work (breaking nodes into the local, same zone, different
zone, but then deliberately merging local and same zone back together
because that was a silly idea).

BugzID: 17801