> "The reads will also be sent to, and processed by the current > leader." > > So, at any given time, only one brick in the replica group is > handling read requests? For a read-only workload-phase, > all except one will be idle in any given term? By default and in theory, yes. The question is: does it matter in practice? If you only have one replica set, and if you haven't turned on the option to allow reads from non-leaders (which is not the default because it does imply a small reduction in consistency across failure scenarios), and if the client(s) bandwidth isn't already saturated, then yeah, it might be slower than AFR. Then again, even that might be outweighed by gains in cache efficiency and avoidance of any need for locking. In the absolute worst case, we can split bricks and create multiple replica sets across the same bricks, each with their own leader. That would parallelize reads as much as AFR, while still gaining all of the other NSR advantages. In other words, yes, in theory it could be a problem. In practice? No. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
