GitLab Next

The HA docs https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/administration/high_availability/alpha_database.md#restore-procedure include the following in the failover procedure docs:

# gitlab-ctl repmgr standby unregister --node=X # X should be the value of node in repmgr.conf on the old server

But it appears our implementation of the command in gitlab-ctl don't support --node args.

gitlab-ctl repmgr standby unregister --node=892679731
/opt/gitlab/embedded/service/omnibus-ctl-ee/repmgr.rb:93:in `repmgr_parse_options': invalid option: --node=892679731 (OptionParser::InvalidOption)
	from /opt/gitlab/embedded/service/omnibus-ctl-ee/repmgr.rb:15:in `block in load_file'
	from /opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/omnibus-ctl-0.5.0/lib/omnibus-ctl.rb:202:in `block in add_command_under_category'
	from /opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/omnibus-ctl-0.5.0/lib/omnibus-ctl.rb:730:in `run'
	from /opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/omnibus-ctl-0.5.0/bin/omnibus-ctl:31:in `<top (required)>'
	from /opt/gitlab/embedded/bin/omnibus-ctl:23:in `load'
	from /opt/gitlab/embedded/bin/omnibus-ctl:23:in `<main>'

That area of the docs should also be updated to call out the fact that the old master, if brought back up, can be turned into a standby by issuing the 'standby follow' command. From the docs I thought I had to unregister it first... which I couldn't do for a master node. And then I thought I had to run, standby setup on it, which I also couldn't do because it was already a known node. (We have have to support the --force flag for standby setup in this case, as well, for when the master has taken some split-brain data)