-of-document-leaves-old-fields-behind-tp4206710p4207164.html
Sent from the Solr - User mailing list archive at Nabble.com.
://lucene.472066.n3.nabble.com/Reindex-of-document-leaves-old-fields-behind-tp4206710p4206908.html
Sent from the Solr - User mailing list archive at Nabble.com.
.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Reindex-of-document-leaves-old-fields-behind-tp4206710p4206886.html
Sent from the Solr - User mailing list archive at Nabble.com.
this message in context:
http://lucene.472066.n3.nabble.com/Reindex-of-document-leaves-old-fields-behind-tp4206710p4206946.html
Sent from the Solr - User mailing list archive at Nabble.com.
a reindex of 1234 be assigned to the same shard?
If not you'd have dups all over the cluster.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Reindex-of-document-leaves-old-fields-behind-tp4206710p4206849.html
Sent from the Solr - User mailing list archive at Nabble.com.
.nabble.com/Reindex-of-document-leaves-old-fields-behind-tp4206710p4206841.html
Sent from the Solr - User mailing list archive at Nabble.com.
]
--
View this message in context:
http://lucene.472066.n3.nabble.com/Reindex-of-document-leaves-old-fields-behind-tp4206710p4206963.html
Sent from the Solr - User mailing list archive at Nabble.com.
this message in context:
http://lucene.472066.n3.nabble.com/Reindex-of-document-leaves-old-fields-behind-tp4206710p4206869.html
Sent from the Solr - User mailing list archive at Nabble.com.
On 5/21/2015 9:02 AM, tuxedomoon wrote:
l If it is implicit then
you may have indexed the new document to a different shard, which means
that it is now in your index more than once, and which one gets returned
may not be predictable.
If a document with uniqueKey 1234 is assigned to a shard
On 5/21/2015 9:54 AM, tuxedomoon wrote:
I'm doing all my index to leader 1 and have not specified any router
configuration. But there is an equal distribution of 240M docs across 5
shards. I think I've been stating I have 3 shards in these posts, I have 5,
sorry.
How do I know what kind
is somehow involved in performing an atomic
update rather than replacement. I will try the above test via SolrJ.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Reindex-of-document-leaves-old-fields-behind-tp4206710p4206886.html
Sent from the Solr - User mailing list archive
:
http://lucene.472066.n3.nabble.com/Reindex-of-document-leaves-old-fields-behind-tp4206710p4206732.html
Sent from the Solr - User mailing list archive at Nabble.com.
is with my SolrJ client, Solr config or
something else.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Reindex-of-document-leaves-old-fields-behind-tp4206710.html
Sent from the Solr - User mailing list archive at Nabble.com.
request for the same document with cache busting produce the same
unwanted fields, so I doubt the correct one is hiding somewhere. I can
also see the timestamp going up with each reindex.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Reindex-of-document-leaves-old-fields
On 5/20/2015 4:43 PM, tuxedomoon wrote:
I'm reindexing Mongo docs into SolrCloud. The new docs have had a few fields
removed so upon reindexing those fields should be gone in Solr. They are
not. So the result is a new doc merged with an old doc rather than a
replacement which is what I
15 matches
Mail list logo