Skip to content

fix wrong comments in redis.conf, change default always-show-logo#5695

Merged
oranagra merged 3 commits intoredis:unstablefrom
trevor211:fixRedisConfComment
Sep 3, 2020
Merged

fix wrong comments in redis.conf, change default always-show-logo#5695
oranagra merged 3 commits intoredis:unstablefrom
trevor211:fixRedisConfComment

Conversation

@trevor211
Copy link
Contributor

@trevor211 trevor211 commented Dec 14, 2018

Fix some wrong comments in redis.conf.

1, comment about always-show-logo is not consistent with code
2, comment about cluster-replica-no-failover is wrong since we can only do manualy failover upon replicas

@trevor211 trevor211 changed the title fix comment about always-show-logo, which is not consistent with code fix some wrong comments in redis.conf Dec 14, 2018
# However it is possible to force the pre-4.0 behavior and always show a
# ASCII art logo in startup logs by setting the following option to yes.
always-show-logo yes
always-show-logo no
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
always-show-logo no
# always-show-logo yes

note that this change is not just fixing a comment, it actually changes the behavior when someone uses the default conf file.

on the other hand, i agree that this needs to change since most of the not commented lines in this file represent the default value.
other times they have a non default value but are put in a comment.

my suggestion leads to the same result, but maybe you agree that it's nicer?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could change the default value instead?


# This option, when set to yes, prevents replicas from trying to failover its
# master during master failures. However the master can still perform a
# master during master failures. However the replica can still perform a
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are you certain this is right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. I did a test manually just now with the following steps.

step1: Create a cluster with all 16384 slots allocated to different shards. Each shard has a 1 master and 1 replica.
step2: Manually set cluster-require-full-coverage to yes of all the nodes.
step3: Choose a shard, and delete a allocated slot from both the master and replica.
step4: Use redis-cli --cluster check <ip:port> to verify that not all 16384 slots are covered by nodes.
step5: Do CLUSTER FAILOVER upon replica, and it succeeded with a response OK. And the checking of using ROLE also showed that it really succeeded.
step6: Use redis-cli --cluster check <ip:port> to check and it showed that not all 16384 slots are covered by nodes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are allowed to do CLUSTER FAILOVER upon replicas only.
And cluster-replica-no-failover can only prevent non-manual failover but not manual failover.
FYI

(server.cluster_slave_no_failover && !manual_failover) ||

@oranagra oranagra changed the title fix some wrong comments in redis.conf fix wrong comments in redis.conf, change default always-show-logo Sep 3, 2020
@oranagra oranagra merged commit 12f798d into redis:unstable Sep 3, 2020
JackieXie168 pushed a commit to JackieXie168/redis that referenced this pull request Nov 4, 2020
…dis#5695)

1. default value of always-show-logo was not consistent with the default in the code
2. comment about cluster-replica-no-failover is wrong since we can only do manually failover upon replicas
3. improve description about always-show-logo
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants