{"push_id":783509684,"size":2,"distinct_size":2,"ref":"refs/heads/3.0","head":"c20218eb5770b2cafb12bc7092313b8358fedc0a","before":"0513de624c8d663fc5522e47b2a8a5ddfd741843","commits":[{"sha":"34d87be5198409f295401b2722dea13829c2eee8","author":{"email":"81516c0bc992c9cd30eeaa39d4784e98138d1c17@gmail.com","name":"antirez"},"message":"Sentinel: clarify effect of resetting failover_start_time.","distinct":true,"url":"https://api.github.com/repos/antirez/redis/commits/34d87be5198409f295401b2722dea13829c2eee8"},{"sha":"c20218eb5770b2cafb12bc7092313b8358fedc0a","author":{"email":"81516c0bc992c9cd30eeaa39d4784e98138d1c17@gmail.com","name":"antirez"},"message":"Sentinel: fix bug in config rewriting during failover\n\nWe have a check to rewrite the config properly when a failover is in\nprogress, in order to add the current (already failed over) master as\nslave, and don't include in the slave list the promoted slave itself.\n\nHowever there was an issue, the variable with the right address was\ncomputed but never used when the code was modified, and no tests are\navailable for this feature for two reasons:\n\n1. The Sentinel unit test currently does not test Sentinel ability to\npersist its state at all.\n2. It is a very hard to trigger state since it lasts for little time in\nthe context of the testing framework.\n\nHowever this feature should be covered in the test in some way.\n\nThe bug was found by @badboy using the clang static analyzer.\n\nEffects of the bug on safety of Sentinel\n===\n\nThis bug results in severe issues in the following case:\n\n1. A Sentinel is elected leader.\n2. During the failover, it persists a wrong config with a known-slave\nentry listing the master address.\n3. The Sentinel crashes and restarts, reading invalid configuration from\ndisk.\n4. It sees that the slave now does not obey the logical configuration\n(should replicate from the current master), so it sends a SLAVEOF\ncommand to the master (since the slave master is the same) creating a\nreplication loop (attempt to replicate from itself) which Redis is\ncurrently unable to detect.\n5. This means that the master is no longer available because of the bug.\n\nHowever the lack of availability should be only transient (at least\nin my tests, but other states could be possible where the problem\nis not recovered automatically) because:\n\n6. Sentinels treat masters reporting to be slaves as failing.\n7. A new failover is triggered, and a slave is promoted to master.\n\nBug lifetime\n===\n\nThe bug is there forever. Commit 16237d78 actually tried to fix the bug\nbut in the wrong way (the computed variable was never used! My fault).\nSo this bug is there basically since the start of Sentinel.\n\nSince the bug is hard to trigger, I remember little reports matching\nthis condition, but I remember at least a few. Also in automated tests\nwhere instances were stopped and restarted multiple times automatically\nI remember hitting this issue, however I was not able to reproduce nor\nto determine with the information I had at the time what was causing the\nissue.","distinct":true,"url":"https://api.github.com/repos/antirez/redis/commits/c20218eb5770b2cafb12bc7092313b8358fedc0a"}]}