Redis Sentinel daemon
Create an automatic setup and configuration for the sentinel daemon (gitlab-org/gitlab-ce#3355). EE feature.
Omnibus changes: https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1000
Documentation:
- CE: gitlab-org/gitlab-ce!6471
- EE: gitlab-org/gitlab-ee!786
Remaining TODO:
-
If you specify non-default bind for sentinel, during the failover it will change it to 127.0.0.1 - When using the correct authentication data, this never happened. So I'm assuming that is related to the "NOAUTH" protected mode (when it goes to undesired or unsafe state, it doesn't allow connection from the outside world as a way to prevent major issues).
-
When bind was changed for sentinel.conf, we didn't see the sentinel service restart in one case -
Even the slave nodes have to have their redis password set redis['password'] - Yes, we will have to set both everytime (or at least define
masterauth
andrequirespass
everytime).
- Yes, we will have to set both everytime (or at least define
-
Do we even need redis['master_password']? - This is open for discussion, it's used in 3 different scenarios: It's where we store the slave password (in a node running redis as slave), it's where we store the password for the sentinel node (in a node running sentinel) and it's where we define the password to connect to a sentinel node (in a node running gitlab-rails).
-
After master node comes back up from a failover it is unable to talk with the new master node and start the replication. - This is fixed by changing the cookbook to always define the password for the "SLAVEOF"
-
Documentation update (gitlab-org/gitlab-ee!786) -
Boot-up machines following just the knowledge in the documentation. It should bring us to a working environment.