[][src]Struct async_raft::raft::Raft

pub struct Raft<D: AppData, R: AppDataResponse, N: RaftNetwork<D>, S: RaftStorage<D, R>> { /* fields omitted */ }

The Raft API.

This type implements the full Raft spec, and is the interface to a running Raft node. Applications building on top of Raft will use this to spawn a Raft task and interact with the spawned task.

For more information on the Raft protocol, see the specification here (pdf warning).

For details and discussion on this API, see the Raft API section of the guide.

clone

This type implements Clone, and should be cloned liberally. The clone itself is very cheap and helps to facilitate use with async workflows.

shutting down

If any of the interfaces returns a RaftError::ShuttingDown, this indicates that the Raft node is shutting down (potentially for data safety reasons due to a storage error), and the shutdown method should be called on this type to await the shutdown of the node. If the parent application needs to shutdown the Raft node for any reason, calling shutdown will do the trick.

Implementations

impl<D: AppData, R: AppDataResponse, N: RaftNetwork<D>, S: RaftStorage<D, R>> Raft<D, R, N, S>[src]

pub fn new(
    id: NodeId,
    config: Arc<Config>,
    network: Arc<N>,
    storage: Arc<S>
) -> Self
[src]

Create and spawn a new Raft task.

id

The ID which the spawned Raft task will use to identify itself within the cluster. Applications must guarantee that the ID provided to this function is stable, and should be persisted in a well known location, probably alongside the Raft log and the application's state machine. This ensures that restarts of the node will yield the same ID every time.

config

Raft's runtime config. See the docs on the Config object for more details.

network

An implementation of the RaftNetwork trait which will be used by Raft for sending RPCs to peer nodes within the cluster. See the docs on the RaftNetwork trait for more details.

storage

An implementation of the RaftStorage trait which will be used by Raft for data storage. See the docs on the RaftStorage trait for more details.

pub async fn append_entries(
    &self,
    rpc: AppendEntriesRequest<D>
) -> Result<AppendEntriesResponse, RaftError>
[src]

Submit an AppendEntries RPC to this Raft node.

These RPCs are sent by the cluster leader to replicate log entries (§5.3), and are also used as heartbeats (§5.2).

pub async fn vote(&self, rpc: VoteRequest) -> Result<VoteResponse, RaftError>[src]

Submit a VoteRequest (RequestVote in the spec) RPC to this Raft node.

These RPCs are sent by cluster peers which are in candidate state attempting to gather votes (§5.2).

pub async fn install_snapshot(
    &self,
    rpc: InstallSnapshotRequest
) -> Result<InstallSnapshotResponse, RaftError>
[src]

Submit an InstallSnapshot RPC to this Raft node.

These RPCs are sent by the cluster leader in order to bring a new node or a slow node up-to-speed with the leader (§7).

pub async fn current_leader(&self) -> Option<NodeId>[src]

Get the ID of the current leader from this Raft node.

This method is based on the Raft metrics system which does a good job at staying up-to-date; however, the client_read method must still be used to guard against stale reads. This method is perfect for making decisions on where to route client requests.

pub async fn client_read(&self) -> Result<(), ClientReadError>[src]

Check to ensure this node is still the cluster leader, in order to guard against stale reads (§8).

The actual read operation itself is up to the application, this method just ensures that the read will not be stale.

pub async fn client_write(
    &self,
    rpc: ClientWriteRequest<D>
) -> Result<ClientWriteResponse<R>, ClientWriteError<D>>
[src]

Submit a mutating client request to Raft to update the state of the system (§5.1).

It will be appended to the log, committed to the cluster, and then applied to the application state machine. The result of applying the request to the state machine will be returned as the response from this method.

Our goal for Raft is to implement linearizable semantics. If the leader crashes after committing a log entry but before responding to the client, the client may retry the command with a new leader, causing it to be executed a second time. As such, clients should assign unique serial numbers to every command. Then, the state machine should track the latest serial number processed for each client, along with the associated response. If it receives a command whose serial number has already been executed, it responds immediately without reexecuting the request (§8). The RaftStorage::apply_entry_to_state_machine method is the perfect place to implement this.

These are application specific requirements, and must be implemented by the application which is being built on top of Raft.

pub async fn initialize(
    &self,
    members: HashSet<NodeId>
) -> Result<(), InitializeError>
[src]

Initialize a pristine Raft node with the given config.

This command should be called on pristine nodes — where the log index is 0 and the node is in NonVoter state — as if either of those constraints are false, it indicates that the cluster is already formed and in motion. If InitializeError::NotAllowed is returned from this function, it is safe to ignore, as it simply indicates that the cluster is already up and running, which is ultimately the goal of this function.

This command will work for single-node or multi-node cluster formation. This command should be called with all discovered nodes which need to be part of cluster, and as such it is recommended that applications be configured with an initial cluster formation delay which will allow time for the initial members of the cluster to be discovered (by the parent application) for this call.

If successful, this routine will set the given config as the active config, only in memory, and will start an election.

It is recommended that applications call this function based on an initial call to RaftStorage.get_initial_state. If the initial state indicates that the hard state's current term is 0 and the last_log_index is 0, then this routine should be called in order to initialize the cluster.

Once a node becomes leader and detects that its index is 0, it will commit a new config entry (instead of the normal blank entry created by new leaders).

Every member of the cluster should perform these actions. This routine is race-condition free, and Raft guarantees that the first node to become the cluster leader will propagate only its own config.

pub async fn add_non_voter(&self, id: NodeId) -> Result<(), ChangeConfigError>[src]

Synchronize a new Raft node, bringing it up-to-speed (§6).

Applications built on top of Raft will typically have some peer discovery mechanism for detecting when new nodes come online and need to be added to the cluster. This API facilitates the ability to request that a new node be synchronized with the leader, so that it is up-to-date and ready to be added to the cluster.

Calling this API will add the target node as a non-voter, starting the syncing process. Once the node is up-to-speed, this function will return. It is the responsibility of the application to then call change_membership once all of the new nodes are synced.

If this Raft node is not the cluster leader, then this call will fail.

pub async fn change_membership(
    &self,
    members: HashSet<NodeId>
) -> Result<(), ChangeConfigError>
[src]

Propose a cluster configuration change (§6).

This will cause the leader to begin a cluster membership configuration change. If there are new nodes in the proposed config which are not already registered as non-voters — from an earlier call to add_non_voter — then the new nodes will first be synced as non-voters before moving the cluster into joint consensus. As this process may take some time, it is recommended that add_non_voter be called first for new nodes, and then once all new nodes have been synchronized, call this method to start reconfiguration.

If this Raft node is not the cluster leader, then the proposed configuration change will be rejected.

pub fn metrics(&self) -> Receiver<RaftMetrics>[src]

Get a handle to the metrics channel.

pub async fn shutdown(&self) -> Result<()>[src]

Shutdown this Raft node.

Trait Implementations

impl<D: AppData, R: AppDataResponse, N: RaftNetwork<D>, S: RaftStorage<D, R>> Clone for Raft<D, R, N, S>[src]

Auto Trait Implementations

impl<D, R, N, S> !RefUnwindSafe for Raft<D, R, N, S>[src]

impl<D, R, N, S> Send for Raft<D, R, N, S>[src]

impl<D, R, N, S> Sync for Raft<D, R, N, S>[src]

impl<D, R, N, S> Unpin for Raft<D, R, N, S>[src]

impl<D, R, N, S> !UnwindSafe for Raft<D, R, N, S>[src]

Blanket Implementations

impl<T> Any for T where
    T: 'static + ?Sized
[src]

impl<T> Borrow<T> for T where
    T: ?Sized
[src]

impl<T> BorrowMut<T> for T where
    T: ?Sized
[src]

impl<T> From<T> for T[src]

impl<T> Instrument for T[src]

impl<T> Instrument for T[src]

impl<T, U> Into<U> for T where
    U: From<T>, 
[src]

impl<T> ToOwned for T where
    T: Clone
[src]

type Owned = T

The resulting type after obtaining ownership.

impl<T, U> TryFrom<U> for T where
    U: Into<T>, 
[src]

type Error = Infallible

The type returned in the event of a conversion error.

impl<T, U> TryInto<U> for T where
    U: TryFrom<T>, 
[src]

type Error = <U as TryFrom<T>>::Error

The type returned in the event of a conversion error.

impl<V, T> VZip<V> for T where
    V: MultiLane<T>, 

impl<T> WithSubscriber for T[src]