Forum: Building VoltDB Applications

Post: Availability

Availability
tuancao
Jun 3, 2010
Hi,

I understand that voltdb uses k-safety to provide high-availability. But k-safety only involves duplicating database partitions, I wonder how voltdb provides HA when the leader node(coordinator) fails.

Thanks,
Tuan
re: availability
tcallaghan
Jun 3, 2010
Tuan,

When you create a VoltDB catalog you supply the name of the "leader" node. This node is only the leader when the cluster is first started, as all non-leader nodes communicate with the lead node. Once the correct number of nodes are started (another parameter when creating the catalog) the VoltDB instance is online. From that point on there is no longer anything special about the leader.

-Tim
This is a really important
rbetts
Jun 3, 2010
Tuan,

When you create a VoltDB catalog you supply the name of the "leader" node. This node is only the leader when the cluster is first started, as all non-leader nodes communicate with the lead node. Once the correct number of nodes are started (another parameter when creating the catalog) the VoltDB instance is online. From that point on there is no longer anything special about the leader.

-Tim


This is a really important point; I'd like to repeat Tim's answer from a slightly different direction:

VoltDB replication is not a master/slave or primary/backup replication system. Each replica is a first class, fully capable instance of a partition.
Transaction Number
tuancao
Jun 3, 2010
Hi,

Thank you very much for your answers.
Can you help to clear that who assigned the transaction numbers? Take the voter example, do the clients assign the transaction numbers?

Thanks,
Tuan
The server assigns a
rbetts
Jun 3, 2010
Hi,

Thank you very much for your answers.
Can you help to clear that who assigned the transaction numbers? Take the voter example, do the clients assign the transaction numbers?

Thanks,
Tuan


The server assigns a transaction id when the transaction is accepted in to the system. The client does not create the transaction id. The transaction id includes a timestamp, a server id and a sequence number that orders transactions ids within the timestamp granularity. This produces transaction ids that are monotonically increasing at each server, unique across servers and orderable at each partition.

Actually, we were chuckling yesterday when Twitter announced a service that does this for their incoming tweets -- nearly identical solutions! Hopefully a good sign :-)

http://engineering.twitter.com/2010/06/announcing-snowflake.html