greg/machi
1
0
Fork 0
Code Issues 11 Pull requests 1 Projects Releases Packages Wiki Activity Actions

Merge pull request #2 from cmeiklejohn/fix-quotations

Browse source 
Fix incorrect Latex quotations.
This commit is contained in:
Scott Lystig Fritchie 2015-08-21 11:09:09 +09:00
commit 4857774f41
1 changed files with 13 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
doc/src.high-level/high-level-chain-mgr.tex
View file

@ -150,12 +150,12 @@ main focus of this document.
Humming consensus's goal is to manage Chain Replication metadata
safely. If participants have differing notions of time, e.g., running
on extremely fast or extremely slow hardware, then humming consensus
may "churn" rapidly in different metadata states in such a way that
may ``churn'' rapidly in different metadata states in such a way that
the chain's data is effectively unavailable.
In practice, however, any series of network partition changes that
case humming consensus to churn will cause other management techniques
(such as an external "oracle") similar problems.
(such as an external ``oracle'') similar problems.
{\bf [Proof by handwaving assertion.]}
(See also: Section~\ref{sub:time-model})
@ -167,14 +167,14 @@ practice of chain replication metadata management options.
\subsection{``Leveraging Sharding in the Design of Scalable Replication Protocols'' by Abu-Libdeh, van Renesse, and Vigfusson}
\label{ssec:elastic-replication}
Multiple chains are arranged in a ring (called a "band" in the paper).
Multiple chains are arranged in a ring (called a ``band'' in the paper).
The responsibility for managing the chain at position N is delegated
to chain N-1. As long as at least one chain is running, that is
sufficient to start/bootstrap the next chain, and so on until all
chains are running. This technique is called ``Elastic Replication''.
The paper then estimates mean-time-to-failure
(MTTF) and suggests a "band of bands" topology to handle very large
(MTTF) and suggests a ``band of bands'' topology to handle very large
clusters while maintaining an MTTF that is as good or better than
other management techniques.
@ -212,7 +212,7 @@ Paxos, Raft, et al.), why bother with a slightly different set of
assumptions and a slightly different protocol?
The answer lies in one of our explicit goals: to have an option of
running in an "eventually consistent" manner. We wish to be able to
running in an ``eventually consistent'' manner. We wish to be able to
make progress, i.e., remain available in the CAP sense, even if we are
partitioned down to a single isolated node. VR, Paxos, and Raft
alone are not sufficient to coordinate service availability at such
@ -250,9 +250,9 @@ timestamps, physical or logical. Any mention of time inside of data
structures are for human/historic/diagnostic purposes only.
Having said that, some notion of physical time is suggested for
purposes of efficiency. It's recommended that there be some "sleep
time" between iterations of the algorithm: there is no need to "busy
wait" by executing the algorithm as quickly as possible. See also
purposes of efficiency. It's recommended that there be some ``sleep
time'' between iterations of the algorithm: there is no need to ``busy
wait'' by executing the algorithm as quickly as possible. See also
Section~\ref{ssub:when-to-calc}.
\subsection{Failure detector model}
@ -278,7 +278,7 @@ will always be explictly noted.
\subsection{Use of the ``wedge state''}
A participant in Chain Replication will enter "wedge state", as
A participant in Chain Replication will enter ``wedge state'', as
described by the Machi high level design \cite{machi-design} and by CORFU,
when it receives information that
a newer projection (i.e., run-time chain state reconfiguration) is
@ -295,13 +295,13 @@ operation mode.
\subsection{Use of ``humming consensus''}
CS literature uses the word "consensus" in the context of the problem
CS literature uses the word ``consensus'' in the context of the problem
description at \cite{wikipedia-consensus}
.
This traditional definition differs from what is described here as
``humming consensus''.
"Humming consensus" describes
``Humming consensus'' describes
consensus that is derived only from data that is visible/known at the current
time.
The algorithm will calculate
@ -478,7 +478,7 @@ Figure~\ref{fig:projection}. To summarize the major components:
According to the CORFU research papers, if a server node $S$ or client
node $C$ believes that epoch $E$ is the latest epoch, then any information
that $S$ or $C$ receives from any source that an epoch $E+\delta$ (where
$\delta > 0$) exists will push $S$ into the "wedge" state and $C$ into a mode
$\delta > 0$) exists will push $S$ into the ``wedge'' state and $C$ into a mode
of searching for the projection definition for the newest epoch.
In the humming consensus description in
@ -775,7 +775,7 @@ is used by the flowchart and throughout this section.
\item[E] The epoch number of a projection.
\item[UPI] "Update Propagation Invariant". The UPI part of the projection
\item[UPI] ``Update Propagation Invariant''. The UPI part of the projection
is the ordered list of chain members where the
Update Propagation Invariant of the original Chain Replication paper
\cite{chain-replication} is preserved.