aratno commented on code in PR #4192:
URL: https://github.com/apache/cassandra/pull/4192#discussion_r2167425005
##########
src/java/org/apache/cassandra/replication/MutationTrackingService.java:
##########
@@ -180,12 +180,41 @@ int nextHostLogId()
}
private final AtomicInteger nextHostLogId = new AtomicInteger();
- private static class KeyspaceShards
+ public boolean isDurablyReconciled(String keyspace,
CoordinatorLogOffsets<Offsets.Immutable> logOffsets)
+ {
+ // Could pass through SSTable bounds to exclude shards for
non-overlapping ranges, but this will mostly be
+ // called on flush for L0 SSTables with wide bounds.
+
+ KeyspaceShards keyspaceShards = shards.get(keyspace);
+ if (keyspaceShards == null)
+ {
+ logger.debug("Could not find shards for keyspace {}", keyspace);
+ return false;
+ }
+
+ for (Long logId : logOffsets)
+ {
+ CoordinatorLogId coordinatorLogId = new CoordinatorLogId(logId);
+ CoordinatorLog log = keyspaceShards.logs.get(coordinatorLogId);
+ if (log == null)
+ {
+ logger.debug("Could not find log {}", coordinatorLogId);
Review Comment:
There are two main situations I can think of where a logId in an SSTable
might not be known by KeyspaceShards:
1. logId has been garbage collected due to local log rotation
2. logId came from another replica, then was streamed as part of a topology
change, before cleanup
We should retain lifecycle metadata for all logIds that are present in live
SSTables, but that's more in scope for the durability work that Aleksey is
doing and upcoming work to support topology changes. I'll upgrade this to a
warn for now.
For backup and restore, we'll need to accept import of old SSTables with
stale logIds, and allow instances to reconcile the imported SSTables. At import
time, we could map logIds in imported SSTables to new logIds, to basically
assign coordinators to the existing mutations so they can be reconciled.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
