> 105778 0 0
>>> 126934 0 0
>>> 152321 0 0
>>> 182785 0 0
>>> 219342 0 0
>&g
663230 0
>> 58395880 0
>> 7007506 0 0
>> 84090070 0
>> 10090808 0 0
>> 12108970
0
>> 48663230 0
>> 58395880 0
>> 7007506 0 0
>> 84090070 0
>> 10090808 0 0
>> 1210897
0 0
> 802187438 0 0
> 962624926 0 0
> 1155149911 0 0
> 1386179893 0 0
> 1663415872 0 0
The read repair you have disabled is the probabilistic background repair -
foreground repair due to mismatch still happens
Streaming should respect windows. Streaming doesn’t write to the memtable, only
the write path puts data into the memtable.
--
Jeff Jirsa
> On Dec 18, 2018, at 1:49 AM,
read repair is disabled in this table :
CREATE TABLE gil_test.my_test (
id int,
creation_time timestamp,
...
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.0
AND default_time_to_live = 0
AND gc_grace_seconds = 3600
AND max_index_interval = 2048
AND me
The min timestamps vary (likely due to read repairing old values into the
memtable and flushing into these sstables), but the max timestamps for both
are in the same second (same microsecond, even, so probably the same write):
Maximum timestamp: 1544903882074190
Maximum timestamp: 1544903882074190
hey jeff, attaching more information.
so this the situation before - 3 nodes in the cluster (3.11.3 in this case
but i saw same thing in 2.1 and 3.0), there is a script writing one row
every minute and another script doing nodetool flush every 10 minute.
window is defined as two hours, so after a f
Remove node will stream data from all windows to remote nodes , so some
compaction is expected
Would need to see the sstablemetadata to understand what’s happening there.
--
Jeff Jirsa
> On Dec 13, 2018, at 10:26 PM, Roy Burstein wrote:
>
> Hi all ,
> My colleague opened Jira ticket for t
