[KUDU-430] Consistent Operations

• Type: New Feature
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: M4
• Component/s: client, tablet, tserver
• Labels: roadmap-candidate
• Target Version/s: 1.8.0
• Assignee: David Alves
• Reporter: Todd Lipcon
• Created: 31/Jul/14 13:19
• Updated: 18/Jun/19 13:01

Description

This ticket tracks consistency/isolation work for 1.2.

Scope Doc: https://docs.google.com/document/d/1EaKlJyQdMBz6G-Xn5uktY-d_x0uRmjMCrDGP5rZ7AoI/edit#

The sub-tasks that don't target 1.2 will likely be moved somewhere else, or promoted to tasks once this ticket is done, but for now it's handy to have a single view of all the remaining work

Issue Links

• contains: KUDU-796 New leaders should not allow "up to date" reads until they've committed everything from previous terms
• is blocked by: KUDU-568 Exactly-once semantics on writes
• is blocked by: KUDU-420 c++ client: implement HT timestamp propagation via scan tokens
• is blocked by: KUDU-371 major delta compaction should generate UNDOs
• is blocked by: KUDU-132 Integrate UNDOS in delta compaction
• is blocked by: KUDU-236 GC tablet history
• is blocked by: KUDU-235 Major delta compaction needs to spit out UNDO files
• is blocked by: KUDU-1187 Full parity between clients regarding read/write modes
• is related to: KUDU-146 Deal with leap seconds
• is related to: KUDU-1497 Full support for read-your-writes consistency
• is related to: KUDU-1663 Clean-up in-code documentation for KuduScanner::ReadMode and KuduClient::GetLatestObservedTimestamp
• relates to: KUDU-1656 Scanner timeouts aren't retried when waiting on a transaction
• relates to: KUDU-1697 Operations that have to wait for a certain time/condition to pass shouldn't block threads

Sub-Tasks

• Make replica/replayed transactions take the same timestamp as the original ones: Resolved
• Timestamps are being ignored in bootstrap: Resolved
• Add a mock clock to HybridClock: Resolved
• Snapshot scans should only refuse scans with timestamps whose value is > now+error: Resolved
• Setting snapshot timestamp to last propagated timestamp should include prior writes: Resolved
• Proper safe time advancement by leaders and replicas: Resolved
• Support for encoding REINSERT: Resolved
• On reads at a snapshot that touch multiple tablets, without the user setting a timestamp, use the timestamp from the first server for following scans: Resolved
• Propagate timestamps for scans: Resolved
• Avoid holding RPC handler threads on replicas that are part of a degraded tablet: Resolved
• Add a way to set ReplicaSelection to the java client: Resolved
• c++ client: implement HT timestamp propagation via scan tokens: Resolved
• C++ client: propagate timestamp for write operations: Resolved
• Handle snapshot reads that might block indefinitely: Closed
• Create an integration test that performs writes with multiple consistency modes: Resolved
• For snapshot read correctness, enforce simple form of leader leases: Open
• Specification for expected semantics and client modes: Resolved
• Add a new read mode to perform bounded staleness snapshot reads: Resolved
• Document Consistency Semantics: Resolved
• Document/Implement read-your-writes for Impala/Spark etc.: Resolved
• Consistency for alter table operations: Open
• Cryptographically sign the operation timestamps returned on server responses.: Open