Often it's a better idea to index into a fresh collection when making changes that imply a full re-index. If you use an alias, the swap out of the old collection is atomic when you update the alias, requiring no front end changes at all (and swap back is easy if things aren't what you expected). Of course if you're not running cloud the same applies to creating a new index, but aliases won't be available, so then hopefully you've built some proxy layer or application API that has a simple configuration to update where it queries...
If you're going to spend the effort to reprocess all the docs, why not end up in a state with no deleted docs? (i.e. don't do delete-all, create a new collection) On Wed, May 24, 2023 at 11:08 AM Jan Høydahl <jan....@cominvent.com> wrote: > I thought deletes were "broadcast" but probably for the composite-id > router it is not since we know for sure where it resides. > You say "shards were added" - how did you do that? > Sounds like you shold simply re-create your collection and re-index? > > Jan > > > 24. mai 2023 kl. 16:39 skrev Walter Underwood <wun...@wunderwood.org>: > > > > We have a messed-up index with documents on shards where they shouldn’t > be. Content was indexed, shards were added, then everything was reindexed. > So the new document with the same ID was put on a new shard, leaving the > previous version on the old shard (where it doesn’t match the hash range). > > > > I’m trying to delete the old document by sending an update with > delete-by-id and a shards parameter. It returns success, but the document > isn’t deleted. > > > > Is the hash range being checked and overriding the shards param somehow? > Any ideas on how to make this work? > > > > And yes, we won’t do that again. > > > > wunder > > Walter Underwood > > wun...@wunderwood.org > > http://observer.wunderwood.org/ (my blog) > > > > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
