Short read protection is a feature added in 3.0 to work around a possible situation in 2.1 where we could fail to return all rows in a result
The basic premise is that when you read, we ask for the same number of rows from all of the replicas involved in the query. It’s possible, with the right chance / luck / conditions, that each replica will return 5000 rows but the results won’t be the same 5000, and when you merge them together you can end up with less than 5000 live rows (basically if a couple instances each miss some tombstones). Cassandra 3 and newer try to detect and fix this by doing extra reads when they detect the result is shorter than the actual requested page - they protect against short results by reading again. In 3.0-3.11 this was silent and invisible In 4.0 it logs There’s nothing you can or should do about this, but it’s letting you know it’s doing an extra read to ensure correctness. > On Sep 17, 2021, at 12:15 PM, James Brown <jbr...@easypost.com> wrote: > > > I upgraded a test cluster from 3.11.11 to 4.0.1 today and the following > message started appearing the logs fairly regularly: > > INFO [Native-Transport-Requests-1] ShortReadPartitionsProtection.java:153 - > Requesting 4951 extra rows from > Full(/10.132.39.33:25469,(8972614703113750908,-9163822348452166994]) for > short read protection > > This message never appeared under 3.x and the string "short read protection" > doesn't seem to occur in any documentation. There aren't any interesting > comments or docstrings in that java file. > > Is this just an artifact of the very small amount of data in this testing > cluster, or is something broken? > -- > James Brown > Engineer
