Triggers are used in autoscaling to watch for cluster events such as nodes joining or leaving.
In the future other cluster, node, and replica events that are important from the point of view of cluster performance will also have available triggers.
Trigger implementations verify the state of resources that they monitor. When they detect a
change that merits attention they generate events, which are then queued and processed by configured
TriggerAction
implementations. This usually involves computing and executing a plan to manage the new cluster
resources (e.g., move replicas). Solr provides predefined implementations of triggers for specific event types.
Triggers execute on the node that runs Overseer
. They are scheduled to run periodically,
currently at fixed interval of 1 second between each execution (not every execution produces events).
Event Types
Currently the following event types (and corresponding trigger implementations) are defined:
-
nodeAdded
- generated when a new node joins the cluster -
nodeLost
- generated when a node leaves the cluster
Events are not necessarily generated immediately after the corresponding state change occurred - the
maximum rate of events is controlled by the waitFor
configuration parameter (see below).
The following properties are common to all event types:
-
id
- (string) A unique time-based event id. -
eventType
- (string) The type of event. -
source
- (string) The name of the trigger that produced this event. -
eventTime
- (long) Unix time when the condition that caused this event occurred. For example, for anodeAdded
event this will be the time when the node was added and not when the event was actually generated, which may significantly differ due to the rate limits set bywaitFor
. -
properties
- (map, optional) Any additional properties. Currently includesnodeName
property that indicates the node that was lost or added.
Auto Add Replicas Trigger
When a collection has the parameter autoAddReplicas
set to true then a trigger configuration named .auto_add_replicas
is automatically created to watch for nodes going away. This trigger produces nodeLost
events,
which are then processed by configured actions (usually resulting in computing and executing a plan
to add replicas on the live nodes to maintain the expected replication factor).
You can see the section Autoscaling Automatically Adding Replicas to learn more about how the .autoAddReplicas
trigger works.
Trigger Configuration
Trigger configurations are managed using the Autoscaling Write API and the commands set-trigger
, remove-trigger
,
suspend-trigger
, and resume-trigger
.
Trigger configuration consists of the following properties:
-
name
- (string, required) A unique trigger configuration name. -
event
- (string, required) One of the predefined event types (nodeAdded
ornodeLost
). -
actions
- (list of action configs, optional) An ordered list of actions to execute when event is fired. -
waitFor
- (string, optional) The time to wait between generating new events, as an integer number immediately followed by unit symbol, one ofs
(seconds),m
(minutes), orh
(hours). Default is0s
. -
enabled
- (boolean, optional) Whentrue
the trigger is enabled. Default istrue
. -
Additional implementation-specific properties may be provided.
Action configuration consists of the following properties:
-
name
- (string, required) A unique name of the action configuration. -
class
- (string, required) The action implementation class. -
A dditional implementation-specific properties may be provided
If the Action configuration is omitted, then by default, the ComputePlanAction
and the ExecutePlanAction
are automatically added to the trigger configuration.
nodeAdded
events{
"set-trigger": {
"name" : "node_added_trigger",
"event" : "nodeAdded",
"waitFor" : "1s",
"enabled" : true,
"actions" : [
{
"name" : "compute_plan",
"class": "solr.ComputePlanAction"
},
{
"name" : "custom_action",
"class": "com.example.CustomAction"
},
{
"name" : "execute_plan",
"class": "solr.ExecutePlanAction"
}
]
}
}
This trigger configuration will compute and execute a plan to allocate the resources available on the new node. A custom action is also used to possibly modify the plan.
We welcome feedback on Solr documentation. However, we cannot provide application support via comments. If you need help, please send a message to the Solr User mailing list.