简体   繁体   中英

Cassandra backup and restore consistency

The scenario is as follows: I have 1 Cassandra node in which I have one keyspace, in which I have 2 tables. Let's call these tables A and B. Now I have a script that inserts data very quickly into these two tables in a batch statement. Table A has columns "k" and "value". Table B has columns "k" and "value". The batch query is as follows:

BEGIN BATCH
INSERT INTO A(k, value) VALUES ("a", 1);
INSERT INTO B(k, value) VALUES ("b", 1);
APPLY BATCH

The value 1 keeps getting incremented every successive batch query. So if table A has (a, 1000), then table B must have (b, 1000). Because (logged) batch queries are atomic.

Now my question is, how does nodetool snapshot work in this case? I have seen the source code of snapshotting and it seems that it does it per keyspace, per table, one by one. So for example, at time 0, it takes a snapshot of table A which has say ("a", 100), then at time 1 a new batch query is inserted (with value 101), and then at time 2, it takes a snapshot of b, which means b's snapshot would have value of 101, but a's wouldn't.

If the above explanation is correct, wouldn't that cause a problem while restoring? How would table A get ("a", 101) after restoring? Or would table B not have ("b", 101) after restoring?

Firstly, there is a fine line between atomicity and isolation. Batches guarantee that both inserts will be applied (atomicity), but they do not guarantee that they will be applied at the exact same time. (isolation)

A client is still able to read one and not the other in a select. The only exception to this rule is if the batches targets one single row.

You are quite right in that you would run into the problem you described. It is very possible to get into a scenario where the numbers are not the same in both tables.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM