But you can only use a timestamp on a specific column, not the whole row.
Here's the help:
Delete all cells in a given row; pass a table name, row, and optionally
a column and timestamp. Examples:
hbase deleteall 't1', 'r1'
hbase deleteall 't1', 'r1', 'c1'
hbase deleteall 't1', 'r1', 'c1',
The timestamp we use is an external version we take from an outside system.
At first we didn't do that, but that caused issues in which 2 separate calls
reached our system out of order and we ignored their version caused the data
to be written in out of order versions.
Now we use the outside
I work with Yaniv and we now have a better understanding of the issue.
It happens when you specifically set a timestamp that is a large long value.
For example 635265926417915010
If you then try to delete the whole line, without specifying the timestamp,
thinking that it will delete the whole
Hello,
We have replication enabled between 2 of our clusters.
I've ran the verifyrep and it showed a lot of lines that are not the same
between clusters.
But, I've then tried getting the failed row in both clusters and it appears
in both.
The strange thing is that it compares rows with
