Thanks! This will help our search for where the CPU cycles are going.
- Phil
On Mon, Jun 5, 2017 at 6:05 PM, Adam Kocoloski wrote:
> The answer to your clarifying question is absolutely yes. The
> “pending_changes” metric refers to the number of committed changes on the
> shard replica emitting
The answer to your clarifying question is absolutely yes. The “pending_changes”
metric refers to the number of committed changes on the shard replica emitting
the log event that need to be cross-checked on another replica. It’s not a
measure of writes that need to be executed.
Cheers, Adam
> O
Hi Adam,
Thanks for the info!
When we run at high write rates, we will start to fall behind, but when we
reduce the rate, we eventually catch up.
I have a clarification question – can the warning messages we are seeing
still occur in a healthy cluster due to the "redundant cross-check" taking
lo
Hi Phil,
Here’s the thing to keep in mind about those warning messages: in a healthy
cluster, the internal replication traffic that generates them is really just a
redundant cross-check. It exists to “heal” a cluster member that was down
during some write operations. When you write data into a
I'm writing to check whether modifying replication batch_count and
batch_size parameters for cluster replication is good idea.
Some background – our data platform dev team noticed that under heavy write
load, cluster replication was falling behind. The following warning
messages started appearing
