davidby-influx

Replication error logging was improved significantly in 2.7.5 ad later versions. See here for more information on how to debug replication problems: https://github.com/influxdata/influxdb/issues/24434#issuecomment-2219005265

There weren't any changes between 2.7.6 and 2.7.7 that obviously affect start-up time (of course, with things like a Go version upgrade, all sorts of components may be different in...

The difference I am seeing here is the `bucket find by name` messages. If you don't have debug-level logging turned on for 2.7.6, the omission of that message may be...

Please include the stack trace that follows after `runtime.panic` as that may contain more clues.

@jeffreyssmith2nd - should this be closed? Is it backported everywhere it should be?

On write to a database that has replication set up, two things happen: - The local write is performed - The data is put into a durable replication queue If...

@dmitryk-nca - When you say there is nothing suspicious in the logs, you mean remote writes always succeed? You never see back-offs in remote writes? Edge data replication does not...

The configuration is not changeable for write timing. You can see the code for this in places like: https://github.com/influxdata/influxdb/blob/df178f74d306efc23978445dead8437c0856a889/replications/remotewrite/writer.go#L137C2-L142C3 https://github.com/influxdata/influxdb/blob/df178f74d306efc23978445dead8437c0856a889/replications/internal/queue_management.go#L143C1-L159C1 https://github.com/influxdata/influxdb/blob/df178f74d306efc23978445dead8437c0856a889/replications/remotewrite/writer.go#L261C2-L268C2

Edge data replication sends remote writes that are the same as the original writes, without any batching (unless the original writes are very large, in which case they are broken...

This may be caused by compactions, which will continue until the data is maximally compressed. Check your log files to see if compaction is happening after you stop writes.