Boot Order
BetaBy default, all guests of a mission start at once. When a guest needs another one first, for example an application that needs its database, you set a boot order on the map.
Connect two guests
Click Boot order: Edit in map. The map shows each guest as a box. Drag from the right side of the guest that must start first to the left side of the guest that waits. A drag from db-01 to web-01 makes web-01 wait for db-01.
Choose what the guest waits for
Select the arrow between the two guests and choose a wait:
The guest starts as soon as the other guest is running. Use it when only the order matters and the first guest needs no extra time.
The guest starts a number of seconds after the other guest is running. Use it for a service that needs a moment to start, when it has no port that you can check.
The guest starts when a TCP port on the other guest accepts connections, for example 5432 for PostgreSQL. Set a timeout as well: when the port does not open in time, the wait fails.
This is the most reliable wait, because it checks that the service is really up and not only that the guest runs.
Boot waves
The dependencies sort the guests into boot waves. Wave 1 holds every guest that waits for nothing, and each other guest goes one wave after the last guest it waits for. The restores start in the same order, so the first wave is up first. Click Waves as columns to see each wave in its own column.
Example: three boot waves
A guest cannot wait for itself, directly or through other guests. The map marks such a loop in red, and the mission stays a draft until you remove it.
When a wait fails
In a restore test, a guest whose wait fails does not start, and neither do the guests that wait for it. All other guests continue, and the report shows which wait failed. In a failover, every guest starts even when a wait failed, so that you can fix the problem in the running guests.
To go back to the simple list of guests, click List view on the map.