| = SolrCloud Autoscaling Trigger Actions |
| // Licensed to the Apache Software Foundation (ASF) under one |
| // or more contributor license agreements. See the NOTICE file |
| // distributed with this work for additional information |
| // regarding copyright ownership. The ASF licenses this file |
| // to you under the Apache License, Version 2.0 (the |
| // "License"); you may not use this file except in compliance |
| // with the License. You may obtain a copy of the License at |
| // |
| // http://www.apache.org/licenses/LICENSE-2.0 |
| // |
| // Unless required by applicable law or agreed to in writing, |
| // software distributed under the License is distributed on an |
| // "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY |
| // KIND, either express or implied. See the License for the |
| // specific language governing permissions and limitations |
| // under the License. |
| |
| `TriggerAction` implementations process events generated by triggers in order to ensure the cluster's |
| health and good use of resources. |
| |
| Currently two implementations are provided: `ComputePlanAction` and `ExecutePlanAction`. |
| |
| == Compute Plan Action |
| |
| The `ComputePlanAction` uses the policy and preferences to calculate the optimal set of Collection API |
| commands which can re-balance the cluster in response to trigger events. |
| |
| The following parameters are configurable: |
| |
| `collections`:: |
| A comma-separated list of collection names. If this list is not empty then |
| the computed operations will only calculate collection operations that affect |
| listed collections and ignore any other collection operations for collections |
| not listed here. Note that non-collection operations are not affected by this. |
| |
| Example configuration: |
| |
| [source,json] |
| ---- |
| { |
| "set-trigger" : { |
| "name" : "node_added_trigger", |
| "event" : "nodeAdded", |
| "waitFor" : "1s", |
| "enabled" : true, |
| "actions" : [ |
| { |
| "name" : "compute_plan", |
| "class" : "solr.ComputePlanAction", |
| "collections" : "test1,test2", |
| }, |
| { |
| "name" : "execute_plan", |
| "class" : "solr.ExecutePlanAction", |
| } |
| ] |
| } |
| } |
| ---- |
| |
| In this example only collections `test1` and `test2` will be potentially |
| replicated / moved to an added node, other collections will be ignored even |
| if they cause policy violations. |
| |
| == Execute Plan Action |
| |
| The `ExecutePlanAction` executes the Collection API commands emitted by the `ComputePlanAction` against |
| the cluster using SolrJ. It executes the commands serially, waiting for each of them to succeed before |
| continuing with the next one. |
| |
| Currently, it has no configurable parameters. |
| |
| If any one of the commands fail, then the complete chain of actions are |
| executed again at the next run of the trigger. If the Overseer node fails while `ExecutePlanAction` is running, |
| then the new Overseer node will run the chain of actions for the same event again after waiting for any |
| running Collection API operations belonging to the event to complete. |
| |
| Please see <<solrcloud-autoscaling-fault-tolerance.adoc#solrcloud-autoscaling-fault-tolerance,SolrCloud Autoscaling Fault Tolerance>> for more details on fault tolerance within the autoscaling framework. |