Generally, 22 hours to 244 hours ( about 1 day through about 10 days) is effective, but it must be monitored and adjusted if needed. A 365 day time to live is exceedingly long and should not be used if you will be primarily recovering space by time to live. By default, the VTEs will be set to recover space when directories are 85% full and the recovery will attempt a 5% recovery ( recoveramt ) The default for time to live is 365 days if enabled. That is to say, each VTE applies independent recovery settings, and applies the configured values to ALL NFS MOUNT POINTS. The reason for this is to prevent the DLMSCR job from running at exactly the same time as the time to live erase process.ĭLm space recovery settings are "global" per VTE. In other words, if 2 days is the minimum value, express this in hours and either 2-4 hours before or 2-4 hours after 48. DLm VTEs should be configured to erase tapes at least 1-2% apart and for Time to Live (TTL), if you are using a days value, it should be expressed in hours, and offset by 2-4 hours depending on how long the scratch job runs. The DLm best practice for recovering space is to have only 1 VTE be the primary agent for erasing scratch tapes. However, when the corresponding data expires (in all SSTables), all relevant SSTables are will be deleted during the next compaction.How to check and set space recovery on the DLm If you use updates in conjunction with TWCS, it may prevent the “window compacted” SSTables from being deleted when they should have been. SSTable A will be added as a candidate for fully expired SSTable and will be purged.Ĭompaction sees that SSTable B overlaps with SSTable A in token range.Ĭompaction also sees that SSTable A overlaps with B in timestamp range, and it thinks that SSTable A could have a tombstone that shadows data in SSTable B.Ĭompaction decides not to purge SSTable A even though it’s fully expired. SSTable B is NOT fully expired because its max deletion time (7) is greater than now (6). SSTable A is fully expired because its max deletion time (3) is lower than now (6). Sstable B: token range:, timestamp range:, ttl: 2, max deletion time: 7 (5+2) Sstable A: token range:, timestamp range:, ttl: 2, max deletion time: 3 (1+2) In this example there is an expired cell that becomes a tombstone, note how the tombstone’s local_deletion_time is the expired cell’s timestamp. This means that the tombstone is going to be deleted after (at least) gc_grace_seconds from the time when the corresponding data element has been written. If not, a tombstone is created and its timestamp is the same as its corresponding data. If the data time stamp + gc_grace_seconds is less than or equal to the current time (now), the data is thrown away and a tombstone is not created. When compaction is running on an SSTable and it scans a piece of data that has expired the following happens: It corrects some assumptions you may have that are not exactly true. This article clarifies what may not be apparent. It is not always clear under which circumstances data is deleted when using Time to Live (TTL) and gc_grace_seconds arguments in table definitions. Learn: How data is removed when using TTL Topic: TTL, gc_grace_seconds, and Compaction Time to Live (TTL) and Compaction Time to Live (TTL) and Compaction ¶
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |