Running
Starting Your Node
Once you've set up your environment, configured your node, set up your quorum set, and selected archives to get
history from, you're ready to start Stellar Core.
Use a command equivalent to:
stellar-core run
At this point, you're ready to observe your core node's activity as it joins the network.
You may want to skip ahead and review the Logging page to familiarize yourself with Stellar Core's output.
Interacting With Your Instance
When your node is running, you can interact with Stellar Core via an administrative HTTP endpoint. Commands can be issued using command-line HTTP tools such as curl
, or by running a CLI command such as
stellar-core http-command <http-command>
The HTTP endpoint is not intended to be exposed to the public internet. It's typically accessed by administrators, or by a mid-tier application to submit transactions to the Stellar network.
Details of available HTTP endpoint commands can be found in the stellar-core-GitHub repo. Additionally, the commands page contains an overview of some of the most useful CLI commands (non-HTTP commands) for managing a running core node.
Joining the Network
Your node will go through the following phases as it joins the network, and you can query for the output below by using the info endpoint mentioned here :
Establish Connection to Other Peers.
You should see authenticated_count
increase.
"peers" : {
"authenticated_count" : 3,
"pending_count" : 4
},
Observing Consensus
Until the node sees a quorum, it will say:
"state" : "Joining SCP"
After observing consensus, a new field quorum
will display information about network decisions. At this point the node will switch to a "Catching up" state:
"quorum" : {
"qset" : {
"ledger" : 22267866,
"cost" : 20883268,
"agree" : 5,
"delayed" : 0,
"disagree" : 0,
"fail_at" : 3,
"hash" : "980a24",
"lag_ms" : 430,
"missing" : 0,
"phase" : "EXTERNALIZE"
},
"transitive" : {
"intersection" : true,
"last_check_ledger" : 22267866,
"node_count" : 21
}
},
"state" : "Catching up",
Catching up
This is a phase where the node downloads data from any configured archives. This phase begins with something like:
"state" : "Catching up",
"status" : [ "Catching up: Awaiting checkpoint (ETA: 35 seconds)" ]
And will then move through the various phases of downloading and applying state, such as:
"state" : "Catching up",
"status" : [ "Catching up: downloading ledger files 20094/119803 (16%)" ]
You can specify how far back in time your node goes to catch up in your config file. If you set the CATCHUP_COMPLETE
field to true
, your node will replay the entire history of the network, which can take a long time. Weeks. You can speed up the process by copying existing archives from another full validator, using archivist
tool. Note that you only need to replay the complete network history if you're setting up a Full Validator (or possibly if you need to reingest Horizon state). Otherwise, you can specify a starting point for catchup using the CATCHUP_RECENT
field. To get in sync as fast as possible, simply use configuration defaults for CATCHUP_RECENT
and CATCHUP_COMPLETE
. See the complete example configuration for more details.
The CATCHUP_COMPLETE
and CATCHUP_RECENT
config fields are mutually exclusive. If the CATCHUP_COMPLETE
field is set to true
, the CATCHUP_RECENT
field will be ignored.
Synced
When the node is done catching up, its state will change to:
"state" : "Synced!"