MongoDB's net.compression.compressors setting controls wire-protocol compression for every connection of the node, including:

1. Client → mongod connections.
2. Secondary → sync source (Primary or upstream Secondary) connections used by OplogFetcher, InitialSyncer and SyncSourceResolver.

Snappy is enabled by default. While Snappy is cheap for small OLTP payloads, on large-document workloads running on small-instance replica sets the replication path becomes CPU-bound on compression / decompression rather than on disk or network. The Secondary's oplog-fetcher consumer thread saturates a single core well before disk or NIC becomes a bottleneck, and replication lag grows unbounded on the further Secondary.

net.compression.compressors is a node-wide switch and cannot be tuned independently for the sync-source link. Operators are forced into an all-or-nothing choice, even though the client link and the intra-DC replication link have very different bandwidth / CPU trade-offs.