-
Notifications
You must be signed in to change notification settings - Fork 24.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CCR] Refactor ChunksCoordinator to continuously look for changes in leader shard #30898
Conversation
Pinging @elastic/es-distributed |
* A single ChunksCoordinator is now in charge of following a shard and keeps on coordinating until the persistent task has been stopped. Whereas before a ChunksCoordinator's job was to process a finite amount of chunks and then a new ChunksCoordinator instance would process the next chunks. * Instead of consuming the chunks queue and waiting for all workers to complete, another background thread will continuously and chunks to the queue, so that the workers never run out of chunks to process if the leader shard has unprocessed write operations. Relates to elastic#30086
1868897
to
4e84a95
Compare
add7759
to
b378c4a
Compare
I've been running the benchmark (http logs) and with this change the follow index caught almost immediately after indexing has been completed. Whereas before it could take up between 5 and 10 minutes before the follow index had all the changes from the leader index. I'll continue to test with the other new ccr benchmarks. |
I also tested with both pmc and geopoints benchmarks and in both cases after the benchmark data was indexed in the leader index, the follower index had all the documents within seconds. |
Superseded by: #31581 |
Make ChunksCoordinator in full control of following leader shard:
keeps on coordinating until the persistent task has been stopped. Whereas
before a ChunksCoordinator's job was to process a finite amount of chunks
and then a new ChunksCoordinator instance would process the next chunks.
complete, another background thread will continuously and chunks to the
queue, so that the workers never run out of chunks to process if the
leader shard has unprocessed write operations.
Relates to #30086