3

In the event of applying security patches, system upgrades, etc., how do I ensure the validators that depend on mine will not be affected when I have to turn off my validator?

  • I think this question should be closed as the answer is in the docs github.com/stellar/stellar-core/blob/master/docs/software/… . From what I understand basic research has to be done before posting questions. – MonsieurNicolas Jan 19 '18 at 17:01
  • Research was, in fact, done and answer found at stellar.org, posted in conjunction with the question, as suggested by StackEx. From the help center: These are the categories of questions that may be closed by the community: • duplicate - This is not a duplicate question. • off topic - This is on topic. • unclear what you're asking - It is clear. • too broad - It is specific. • primarily opinion-based - The answer was found directly from the stellar.org website. – Lilynut Jan 19 '18 at 18:13
  • per the invite, this would fall under "trivial question". I am pasting here the guidelines for building a strong site: Q: What else? A: Remember, you get the site you build! Ask difficult, specific questions — the kind of questions pros and experts ask each other, not the kind of questions novices ask pros, because a site full of pros and experts will attract everybody, but a site full of novices rapidly becomes boring. No easy questions, no survey questions, no polls, no intro-level/basic questions, no unanswerable hypothetical questions. – MonsieurNicolas Jan 19 '18 at 18:24
1

As an administrator of a validator, you must ensure that the maintenance you are about to take on is safe for the overall network and for your validator. Safe means that the other validators that depend on yours will not be affected too much when you turn off your validator for maintenance and that your validator will continue to operate as part of the network when it comes back up.

If you are changing some settings that may impact network wide settings, such as upgrading to a new version of stellar-core that supports a new version of the protocol or if you’re updating other network wide settings, performi the following steps in order (once per machine if you run multiple nodes).

  1. Advertise your intention to others that may depend on you. Some coordination is required to avoid situations where too many nodes go down at the same time.
  2. Dependencies should assess the health of their quorum.
  3. If there is no objection, take your instance down.
  4. When done, start your instance that should rejoin the network.
  5. The instance will be completely caught up when it’s both Synced and there is no backlog in uploading history.

Notes: It can take up to 5 or 6 minutes to sync to the network when you start up. Most of this syncing time is simply stellar-core waiting for the next history checkpoint to be made in a history archive it is reading from.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.