It seems Hashicorp Raft only works in IP addresses, and joining with a
hostname caused the remove logic to cause all nodes to leave when one
node was instructed to leave.
* Use resolved Raft address as API peer key
* Allow Raft advertise address to be set
* Better log message for mux
* CHANGELOG updates
* Unit test mux layer address advertise
Integrate TCP mux with cluster and store
This change allows any node, including followers, to use the Raft log to make changes to a cluster-wide state.
It might still need to be richer, so end-users could specify an
in-memory SQLite database. Specifying a DSN would require the user
to supply the full path to the SQLite database. This is OK. However,
the code then needs to be able to parse out the path to the database
so it can remove it before start up.
This shows that passing the database into the Raft module is probably
not going to work, since the database could be opened in two ways -
directly at startup, and be completely restored from the log, or with
a combination of restoring from a snapshot, followed by the remaining
log entries. In both cases the database must be opened using the
requested DSN settings.
A detailed config object for controlling SQLite behaviour, is probably
best, and it should be passed to the Raft store on start up.
Finally, file-level copying of the SQLite file can only take place if
no transaction is in effect. This might be handled by the use of a
RWLock. The write-lock is taken during Execute() and Snapshot, but
the Read lock is taken during Query(). Unfortunately this may reduce
the concurrency of inserts and updates. Perhaps the Backup call on
the Go SQLite library might be better, but it might be slow.