Yugabyte-db: Question about distributed transactions

[derkan]

Hi,
I've just found YugaByte project which seems interesting. My question is what happens in following scenario:

• Balance for account 123 is 10
• Node A is closed
• Node B is open, run this SQL:

UPDATE balances
       SET balance = balance + 10
 WHERE account_id = 123

• Close Node B
• Open Node A and run

UPDATE balances
       SET balance = balance + 30
 WHERE account_id = 123

• Open B
• Run

SELECT balance
    FROM balances
WHERE account_id = 123

What is the result ?

And second question, is 2 node cluster(active-active) is supported?

Thanks.

[rkarthik007]

Hi @derkan,

I am assuming that your scenario has three nodes A, B and C (at the minimum). Also, by the following:

Node A is closed

I am assuming Node A is either dead, or partitioned from the other nodes such that it cannot talk to any one else over the network.

In the scenario you mentioned above, you should expect the answer 50.

And second question, is 2 node cluster(active-active) is supported?

This is in our roadmap (we're calling this multi-master deployments), and is something we're starting to work on. We should put out a design with some timelines soon.

[kmuthukk]

@derkan

to add to @rkarthik007 's response for the first part of the question:

YB is a distributed SQL database. It is software that can be deployed on a set of nodes that together presents itself as a single database. Additional nodes can be later added to this cluster seamlessly without maintenance down time to expand capacity/throughput of the database.

The deployment options can range from a single-AZ to multi-AZ or multi-region.

Internally, YugaByte DB uses consensus/quorum based (Raft) strongly consistent replication - and hence typical recommended replication factor is 3. Hence, the 3-node minimum recommendation if you desire auto-failover/active-active deployments if you do not want data-loss. [On the other hand, with more traditional master-slave deployment i.e. an async replication model, you can lose data in the kind of example you described (if A & B have a master/slave relation and there is a node failure).]

With YugaByte DB, provided that the number of concurrent node failures is within the deployment's abilities, committed transactions are visible through any node . For example, with a Replication Factor 3, YugaByte DB can tolerate 1 node failure at a given time.

Operations done from any node are still updating the single logical "distributed" database. In your example, the above statements are updating the same row in an ACID manner - and the final result will be 50.

[kmuthukk]

hi @derkan

Hope the above reply helps. Closing the issue for now.

Do not hesitate to re-open if you have additional questions on this topic.

regards,
Kannan

[derkan]

Thanks for explanations. Actually my concern was about data change distribution style. For example for BDR, last applied value will override data to 20(at background uses UPDATE balances SET balance = 20 instead of increment UPDATE balances SET balance = balance + 10) instead of applying an increase to data to make both replica same.( Of course BDR is a replica managent not a full cluster)

2 node active-active cluster is important for basic master-master as it is hard to convince some customers to have 3 machines for a single cluster :-) as storage need is also multiplied by 3.

Sorry for these questions to be not on first list:

• Do remaining 2 nodes serves normally after loosing 1 node?
• If 2 nodes are completely lost, is it possible to open DB from last available node by adding instances?

[rkarthik007]

Hi @derkan,

Do remaining 2 nodes serves normally after loosing 1 node?

Yes, the two remaining node serve normally. If the cluster has replication factor 3, it can transparently survive one fault (node failure in this case). Once a third node is added back the system automatically redistributes data/queries and can once again survive failures.

If 2 nodes are completely lost, is it possible to open DB from last available node by adding instances?

If 2 nodes are lost, we can convert the third node to serve stale reads. But writes would not be possible. It is theoretically possible to fix up and "reconfigure" the last node to become a cluster of replication factor 1.

Note that if your cluster has more node (say 4 or more) and the two node failures do not happen at exactly the same time, the cluster can survive both these failures by re-replicating data onto other nodes.

[derkan]

Thanks for answers and good job on YugoByte. Please close this issue.