Hi Joakim, This might not be what you expect but it is expected behaviour. When you do clean=true, DIH will first delete all records. That is how it works in both M/S and Cloud. The diff might be that you disabled replication or disabled auto commits in your old setup so it is not visible. You can disable auto commits in Cloud and you will have your old index until the next commit, but that is not recommended way. What is usually done when you want to control what becomes active index is using aliases and do full import into new collection. After you verify that everything is ok, you update alias to new collection and it becomes the active one. You can keep the old one so you can roll back in case you notice some issues or you simply drop it when alias is updated.
HTH, Emir -- Monitoring - Log Management - Alerting - Anomaly Detection Solr & Elasticsearch Consulting Support Training - http://sematext.com/ > On 12 Feb 2019, at 10:46, Joakim Hansson <joakim.hansso...@gmail.com> wrote: > > Hi! > We are currently upgrading from solr 6.2 master slave setup to solr 7.6 > running solrcloud. > I dont know if I've missed something really trivial, but everytime I start > a full import (dataimport?command=full-import&clean=true&optimize=true) the > old index gets overwritten by the new import. > > In 6.2 this wasn't really a problem since I could disable replication in > the API on the master and enable it once the import was completed. > With 7.6 and solrcloud we use NRT-shards and replicas since those are the > only ones that support rule-based replica placement and whenever I start a > new import the old index is overwritten all over the solrcloud cluster. > > I have tried changing to clean=false, but that makes the import finish > without adding any docs. > Doesn't matter if I use soft or hard commits. > > I don't get the logic in this. Why would you ever want to delete an > existing index before there is a new one in place? What is it I'm missing > here? > > Please enlighten me.
