I just discoverd these strange "update_mapping" loglines come from a 
completely unrelated thing, so please take this post as invalid and accept 
my apologies.

On Thursday, June 19, 2014 1:21:32 PM UTC-4, JoeZ99 wrote:
>
> This is a somehow bizarre question. I really hope somebody jumps in, 
> because I'm losing my mind.
>
> We've set a system by which our one-machine cluster gets updated indexes 
> that have been made in other clusters by restoring snapshots.
>
> Long story short:
>
> for a few hours, the cluster is restoring snapshots, each one of them 
> containing information about two indexes. of course , the "global_state" 
> flag is set to false, because we don't want to recover the cluster, just 
> those two indexes. 
>
> Say during those few hours , the cluster have restored about 500 
> snapshots, one after another (there is never two restore processes at the 
> same time). By looking at the logs, it goes flawlessly :
>
>
>
> [2014-06-19 00:00:01,318][INFO ][snapshots                ] [Svarog] 
> restore [backups-1:5e51361312cb68f41e1cb1fa5597672a_ts20140618235915350570
> ] is done
> [2014-06-19 00:00:02,363][INFO ][repositories             ] [Svarog] 
> update repository [backups-1]
> [2014-06-19 00:00:08,653][INFO ][cluster.metadata         ] [Svarog] [
> 5e51361312cb68f41e1cb1fa5597672a_ts20140617220817522348] deleting index
> [2014-06-19 00:00:09,286][INFO ][cluster.metadata         ] [Svarog] [
> 5e51361312cb68f41e1cb1fa5597672a_phonetic_ts20140617220817904810] 
> deleting index
> [2014-06-19 00:00:09,815][INFO ][repositories             ] [Svarog] 
> update repository [backups-1]
> [2014-06-19 00:00:15,570][INFO ][repositories             ] [Svarog] 
> update repository [backups-1]
> [2014-06-19 00:00:15,938][INFO ][repositories             ] [Svarog] 
> update repository [backups-1]
> [2014-06-19 00:00:16,208][INFO ][repositories             ] [Svarog] 
> update repository [backups-1]
> [2014-06-19 00:00:20,669][INFO ][snapshots                ] [Svarog] 
> restore [backups-1:70e3583358803e70dc60a83953aaca9e_ts20140618235930121779
> ] is done
> [2014-06-19 00:00:21,585][INFO ][repositories             ] [Svarog] 
> update repository [backups-1]
> [2014-06-19 00:00:26,992][INFO ][cluster.metadata         ] [Svarog] [
> 70e3583358803e70dc60a83953aaca9e_ts20140617220848057264] deleting index
> [2014-06-19 00:00:27,601][INFO ][cluster.metadata         ] [Svarog] [
> 70e3583358803e70dc60a83953aaca9e_phonetic_ts20140617220848563815] 
> deleting index
>
> after restoring the snapshot, outdated version of the indices are removed 
> (because the indices recovered from the snapshot are newer).
>
> this goes quite well, and there is no significant load on the machine 
> while doing this.
>
> but, at some poing, the cluster starts to issue "udpate_mapping" commands 
> with no apparent reason (I'm almost sure there's been no interaction from 
> outside)...
> [2014-06-19 04:38:36,293][INFO ][snapshots                ] [Svarog] 
> restore [backups-1:99cbf66451446e6fe770878e84b4349b_ts20140619043819745139
> ] is done
> [2014-06-19 04:38:37,238][INFO ][repositories             ] [Svarog] 
> update repository [backups-1]
> [2014-06-19 04:38:44,016][INFO ][cluster.metadata         ] [Svarog] [
> 99cbf66451446e6fe770878e84b4349b_ts20140604042653951289] deleting index
> [2014-06-19 04:38:44,517][INFO ][cluster.metadata         ] [Svarog] [
> 99cbf66451446e6fe770878e84b4349b_phonetic_ts20140604042655159506] 
> deleting index
> [2014-06-19 05:57:24,721][INFO ][repositories             ] [Svarog] 
> update repository [backups-1]
> [2014-06-19 05:57:34,869][INFO ][repositories             ] [Svarog] 
> update repository [backups-1]
> [2014-06-19 05:57:35,234<span style="color: #660;" class="styled
> ...

-- 
You received this message because you are subscribed to the Google Groups 
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/949304b9-eba4-4328-badf-00f8288c36a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to