redis集群实现 容灾与宕机恢复

实现集群，一个重要的保证就是高可用性，要在各种软件和硬件的故障情况下仍然能够提供服务。一般来说有两种解决思路，一种是每一个节点互相之间都会进行数据交互以及监控，出现故障的时候，各个节点都可以做协调任务。另一种就是增加一个协调组件来对集群进行实时监控以及故障处理。现在使用比较广泛的是第二种方案，各个模块之间低耦合，工程师先也比较简单(相对第一种而言)。上一节已经介绍过了raft协议，有了raft协议的基础，相信大家理解sentinel也会比较轻松了。redis内的sentinel会实时扫描节点，如果发现了宕机的节点就会执行故障转移，选主等操作，我们来看一下具体的过程。
首先我们启动一个具有三个节点的sentinel集群，首先需要修改sentinel的配置文件，sentinel里有以下几个配置项需要修改的：
port：我们需要修改，因为要启动三个节点，端口必须是不一样的。
dir：sentinel的运行时目录。
sentinel monitor <master-name> <ip> <redis-port> <quorum>:监视一个名叫 <master-name>的master，我们不需要监视slave，监视了master的话，slave会自动加入到sentinel里边。后边的quorum表示达成一致的最小数目，至少quorum台机器达成一致，才能保证一致性。
sentinel down-after-milliseconds <master-name> <milliseconds>表示监视的节点在<milliseconds>后没有回复就会被认为主观下线，当quorum个节点都认为此节点下线了以后就会被认为客观下线。
sentinel parallel-syncs <master-name> <numslaves>表示在故障转移的时候最多有numslaves在同步更新新的master。
我们修改过的三个sentinel.conf是sentinel1.conf，sentinel2.conf，sentinel3.conf，具体内容如下：
sentinel1.conf:

[cpp] view plain copy
  1. # Example sentinel.conf  
  2.   
  3. # port <sentinel-port>  
  4. # The port that this sentinel instance will run on  
  5. port 27000  
  6.   
  7. # dir <working-directory>  
  8. # Every long running process should have a well-defined working directory.  
  9. # For Redis Sentinel to chdir to /tmp at startup is the simplest thing  
  10. # for the process to don't interfere with administrative tasks such as  
  11. # unmounting filesystems.  
  12. dir /tmp  
  13.   
  14. # sentinel monitor <master-name> <ip> <redis-port> <quorum>  
  15. #  
  16. # Tells Sentinel to monitor this master, and to consider it in O_DOWN  
  17. # (Objectively Down) state only if at least <quorum> sentinels agree.  
  18. #  
  19. # Note that whatever is the ODOWN quorum, a Sentinel will require to  
  20. # be elected by the majority of the known Sentinels in order to  
  21. # start a failover, so no failover can be performed in minority.  
  22. #  
  23. # Slaves are auto-discovered, so you don't need to specify slaves in  
  24. # any way. Sentinel itself will rewrite this configuration file adding  
  25. # the slaves using additional configuration options.  
  26. # Also note that the configuration file is rewritten when a  
  27. # slave is promoted to master.  
  28. #  
  29. # Note: master name should not include special characters or spaces.  
  30. # The valid charset is A-z 0-9 and the three characters ".-_".  
  31. sentinel monitor master1 127.0.0.1 7000 2  
  32. sentinel monitor master2 127.0.0.1 7004 2  
  33. sentinel monitor master3 127.0.0.1 7005 2  
  34.   
  35. # sentinel down-after-milliseconds <master-name> <milliseconds>  
  36. #  
  37. # Number of milliseconds the master (or any attached slave or sentinel) should  
  38. # be unreachable (as in, not acceptable reply to PING, continuously, for the  
  39. # specified period) in order to consider it in S_DOWN state (Subjectively  
  40. # Down).  
  41. #  
  42. # Default is 30 seconds.  
  43. sentinel down-after-milliseconds master1 30000  
  44. sentinel down-after-milliseconds master2 30000  
  45. sentinel down-after-milliseconds master3 30000  
  46.   
  47. # sentinel parallel-syncs <master-name> <numslaves>  
  48. #  
  49. # How many slaves we can reconfigure to point to the new slave simultaneously  
  50. # during the failover. Use a low number if you use the slaves to serve query  
  51. # to avoid that all the slaves will be unreachable at about the same  
  52. # time while performing the synchronization with the master.  
  53. sentinel parallel-syncs master1 1  
  54. sentinel parallel-syncs master2 1  
  55. sentinel parallel-syncs master3 1  
  56.   
  57. # sentinel failover-timeout <master-name> <milliseconds>  
  58. #  
  59. # Specifies the failover timeout in milliseconds. It is used in many ways:  
  60. #  
  61. # - The time needed to re-start a failover after a previous failover was  
  62. #   already tried against the same master by a given Sentinel, is two  
  63. #   times the failover timeout.  
  64. #  
  65. # - The time needed for a slave replicating to a wrong master according  
  66. #   to a Sentinel current configuration, to be forced to replicate  
  67. #   with the right master, is exactly the failover timeout (counting since  
  68. #   the moment a Sentinel detected the misconfiguration).  
  69. #  
  70. # - The time needed to cancel a failover that is already in progress but  
  71. #   did not produced any configuration change (SLAVEOF NO ONE yet not  
  72. #   acknowledged by the promoted slave).  
  73. #  
  74. # - The maximum time a failover in progress waits for all the slaves to be  
  75. #   reconfigured as slaves of the new master. However even after this time  
  76. #   the slaves will be reconfigured by the Sentinels anyway, but not with  
  77. #   the exact parallel-syncs progression as specified.  
  78. #  
  79. # Default is 3 minutes.  
  80. sentinel failover-timeout master1 180000  
  81. sentinel failover-timeout master2 180000  
  82. sentinel failover-timeout master3 180000  

sentinel2.conf

[cpp] view plain copy
  1. # Example sentinel.conf  
  2.   
  3. # port <sentinel-port>  
  4. # The port that this sentinel instance will run on  
  5. port 27001  
  6.   
  7. # dir <working-directory>  
  8. # Every long running process should have a well-defined working directory.  
  9. # For Redis Sentinel to chdir to /tmp at startup is the simplest thing  
  10. # for the process to don't interfere with administrative tasks such as  
  11. # unmounting filesystems.  
  12. dir /tmp  
  13.   
  14. # sentinel monitor <master-name> <ip> <redis-port> <quorum>  
  15. #  
  16. # Tells Sentinel to monitor this master, and to consider it in O_DOWN  
  17. # (Objectively Down) state only if at least <quorum> sentinels agree.  
  18. #  
  19. # Note that whatever is the ODOWN quorum, a Sentinel will require to  
  20. # be elected by the majority of the known Sentinels in order to  
  21. # start a failover, so no failover can be performed in minority.  
  22. #  
  23. # Slaves are auto-discovered, so you don't need to specify slaves in  
  24. # any way. Sentinel itself will rewrite this configuration file adding  
  25. # the slaves using additional configuration options.  
  26. # Also note that the configuration file is rewritten when a  
  27. # slave is promoted to master.  
  28. #  
  29. # Note: master name should not include special characters or spaces.  
  30. # The valid charset is A-z 0-9 and the three characters ".-_".  
  31. sentinel monitor master1 127.0.0.1 7000 2  
  32. sentinel monitor master2 127.0.0.1 7004 2  
  33. sentinel monitor master3 127.0.0.1 7005 2  
  34.   
  35. # sentinel down-after-milliseconds <master-name> <milliseconds>  
  36. #  
  37. # Number of milliseconds the master (or any attached slave or sentinel) should  
  38. # be unreachable (as in, not acceptable reply to PING, continuously, for the  
  39. # specified period) in order to consider it in S_DOWN state (Subjectively  
  40. # Down).  
  41. #  
  42. # Default is 30 seconds.  
  43. sentinel down-after-milliseconds master1 30000  
  44. sentinel down-after-milliseconds master2 30000  
  45. sentinel down-after-milliseconds master3 30000  
  46.   
  47. # sentinel parallel-syncs <master-name> <numslaves>  
  48. #  
  49. # How many slaves we can reconfigure to point to the new slave simultaneously  
  50. # during the failover. Use a low number if you use the slaves to serve query  
  51. # to avoid that all the slaves will be unreachable at about the same  
  52. # time while performing the synchronization with the master.  
  53. sentinel parallel-syncs master1 1  
  54. sentinel parallel-syncs master2 1  
  55. sentinel parallel-syncs master3 1  
  56.   
  57. # sentinel failover-timeout <master-name> <milliseconds>  
  58. #  
  59. # Specifies the failover timeout in milliseconds. It is used in many ways:  
  60. #  
  61. # - The time needed to re-start a failover after a previous failover was  
  62. #   already tried against the same master by a given Sentinel, is two  
  63. #   times the failover timeout.  
  64. #  
  65. # - The time needed for a slave replicating to a wrong master according  
  66. #   to a Sentinel current configuration, to be forced to replicate  
  67. #   with the right master, is exactly the failover timeout (counting since  
  68. #   the moment a Sentinel detected the misconfiguration).  
  69. #  
  70. # - The time needed to cancel a failover that is already in progress but  
  71. #   did not produced any configuration change (SLAVEOF NO ONE yet not  
  72. #   acknowledged by the promoted slave).  
  73. #  
  74. # - The maximum time a failover in progress waits for all the slaves to be  
  75. #   reconfigured as slaves of the new master. However even after this time  
  76. #   the slaves will be reconfigured by the Sentinels anyway, but not with  
  77. #   the exact parallel-syncs progression as specified.  
  78. #  
  79. # Default is 3 minutes.  
  80. sentinel failover-timeout master1 180000  
  81. sentinel failover-timeout master2 180000  
  82. sentinel failover-timeout master3 180000  

sentinel3.conf

[cpp] view plain copy
  1. # Example sentinel.conf  
  2.   
  3. # port <sentinel-port>  
  4. # The port that this sentinel instance will run on  
  5. port 27002  
  6.   
  7. # dir <working-directory>  
  8. # Every long running process should have a well-defined working directory.  
  9. # For Redis Sentinel to chdir to /tmp at startup is the simplest thing  
  10. # for the process to don't interfere with administrative tasks such as  
  11. # unmounting filesystems.  
  12. dir /tmp  
  13.   
  14. # sentinel monitor <master-name> <ip> <redis-port> <quorum>  
  15. #  
  16. # Tells Sentinel to monitor this master, and to consider it in O_DOWN  
  17. # (Objectively Down) state only if at least <quorum> sentinels agree.  
  18. #  
  19. # Note that whatever is the ODOWN quorum, a Sentinel will require to  
  20. # be elected by the majority of the known Sentinels in order to  
  21. # start a failover, so no failover can be performed in minority.  
  22. #  
  23. # Slaves are auto-discovered, so you don't need to specify slaves in  
  24. # any way. Sentinel itself will rewrite this configuration file adding  
  25. # the slaves using additional configuration options.  
  26. # Also note that the configuration file is rewritten when a  
  27. # slave is promoted to master.  
  28. #  
  29. # Note: master name should not include special characters or spaces.  
  30. # The valid charset is A-z 0-9 and the three characters ".-_".  
  31. sentinel monitor master1 127.0.0.1 7000 2  
  32. sentinel monitor master2 127.0.0.1 7004 2  
  33. sentinel monitor master3 127.0.0.1 7005 2  
  34.   
  35. # sentinel down-after-milliseconds <master-name> <milliseconds>  
  36. #  
  37. # Number of milliseconds the master (or any attached slave or sentinel) should  
  38. # be unreachable (as in, not acceptable reply to PING, continuously, for the  
  39. # specified period) in order to consider it in S_DOWN state (Subjectively  
  40. # Down).  
  41. #  
  42. # Default is 30 seconds.  
  43. sentinel down-after-milliseconds master1 30000  
  44. sentinel down-after-milliseconds master2 30000  
  45. sentinel down-after-milliseconds master3 30000  
  46.   
  47. # sentinel parallel-syncs <master-name> <numslaves>  
  48. #  
  49. # How many slaves we can reconfigure to point to the new slave simultaneously  
  50. # during the failover. Use a low number if you use the slaves to serve query  
  51. # to avoid that all the slaves will be unreachable at about the same  
  52. # time while performing the synchronization with the master.  
  53. sentinel parallel-syncs master1 1  
  54. sentinel parallel-syncs master2 1  
  55. sentinel parallel-syncs master3 1  
  56.   
  57. # sentinel failover-timeout <master-name> <milliseconds>  
  58. #  
  59. # Specifies the failover timeout in milliseconds. It is used in many ways:  
  60. #  
  61. # - The time needed to re-start a failover after a previous failover was  
  62. #   already tried against the same master by a given Sentinel, is two  
  63. #   times the failover timeout.  
  64. #  
  65. # - The time needed for a slave replicating to a wrong master according  
  66. #   to a Sentinel current configuration, to be forced to replicate  
  67. #   with the right master, is exactly the failover timeout (counting since  
  68. #   the moment a Sentinel detected the misconfiguration).  
  69. #  
  70. # - The time needed to cancel a failover that is already in progress but  
  71. #   did not produced any configuration change (SLAVEOF NO ONE yet not  
  72. #   acknowledged by the promoted slave).  
  73. #  
  74. # - The maximum time a failover in progress waits for all the slaves to be  
  75. #   reconfigured as slaves of the new master. However even after this time  
  76. #   the slaves will be reconfigured by the Sentinels anyway, but not with  
  77. #   the exact parallel-syncs progression as specified.  
  78. #  
  79. # Default is 3 minutes.  
  80. sentinel failover-timeout master1 180000  
  81. sentinel failover-timeout master2 180000  
  82. sentinel failover-timeout master3 180000  

然后我们输入

 

[cpp] view plain copy
  1. redis-sentinel sentinel1.conf  
  2. redis-sentinel sentinel2.conf  
  3. redis-sentinel sentinel3.conf  

 

就可以建立好三个sentinel伪集群，我们会看到如下打印，说明三个master和sentinel都被识别了。

[cpp] view plain copy
  1. 56161:X 04 Dec 09:23:09.855 # Sentinel runid is 4dd7b82766f7faac95c251235682e42079e0a701  
  2. 56161:X 04 Dec 09:23:09.855 # +monitor master master0 192.168.39.153 7000 quorum 2  
  3. 56161:X 04 Dec 09:23:09.855 # +monitor master master2 192.168.39.153 7005 quorum 2  
  4. 56161:X 04 Dec 09:23:09.856 # +monitor master master1 192.168.39.153 7004 quorum 2  
  5. 56161:X 04 Dec 09:23:10.842 * +slave slave 192.168.39.153:7003 192.168.39.153 7003 @ master0 192.168.39.153 7000  
  6. 56161:X 04 Dec 09:23:10.842 * +slave slave 192.168.39.153:7002 192.168.39.153 7002 @ master2 192.168.39.153 7005  
  7. 56161:X 04 Dec 09:23:10.843 * +slave slave 192.168.39.153:7001 192.168.39.153 7001 @ master1 192.168.39.153 7004  
  8. 56161:X 04 Dec 09:23:19.505 * +sentinel sentinel 192.168.39.153:27001 192.168.39.153 27001 @ master0 192.168.39.153 7000  
  9. 56161:X 04 Dec 09:23:19.506 * +sentinel sentinel 192.168.39.153:27001 192.168.39.153 27001 @ master2 192.168.39.153 7005  
  10. 56161:X 04 Dec 09:23:19.508 * +sentinel sentinel 192.168.39.153:27001 192.168.39.153 27001 @ master1 192.168.39.153 7004  
  11. 56161:X 04 Dec 09:23:25.240 * +sentinel sentinel 192.168.39.153:27002 192.168.39.153 27002 @ master1 192.168.39.153 7004  
  12. 56161:X 04 Dec 09:23:25.241 * +sentinel sentinel 192.168.39.153:27002 192.168.39.153 27002 @ master2 192.168.39.153 7005  
  13. 56161:X 04 Dec 09:23:25.242 * +sentinel sentinel 192.168.39.153:27002 192.168.39.153 27002 @ master0 192.168.39.153 7000  

一般来说，我们把一个master下线了以后，集群就会变成不可用状态，但是现在有了sentinel了，一旦master下线就会立刻执行故障转移，就能够在很短的时间内恢复可用。
开始的时候有六个节点，三个master，三个slave，状态如下：

[cpp] view plain copy
  1. 127.0.0.1:7000> cluster info  
  2. cluster_state:ok  
  3. cluster_slots_assigned:16384  
  4. cluster_slots_ok:16384  
  5. cluster_slots_pfail:0  
  6. cluster_slots_fail:0  
  7. cluster_known_nodes:6  
  8. cluster_size:3  
  9. cluster_current_epoch:12  
  10. cluster_my_epoch:10  
  11. cluster_stats_messages_sent:2424257  
  12. cluster_stats_messages_received:2423717  
  13. 127.0.0.1:7000> cluster nodes  
  14. 930daea84150b5fabd32a95592781b27ceab1b71 192.168.39.153:7001 slave 81c884ebfc919ad293f02d797aff1033025ac27e 0 1480817793875 9 connected  
  15. 8a6707d5b9269b6260315b47f300c1ab599733b7 192.168.39.153:7005 master - 0 1480817794879 11 connected 10923-16383  
  16. bdb62bb6ffce71588961f513c74b0d5a1a7145ea 192.168.39.153:7002 slave 8a6707d5b9269b6260315b47f300c1ab599733b7 0 1480817793372 11 connected  
  17. 81c884ebfc919ad293f02d797aff1033025ac27e 192.168.39.153:7004 master - 0 1480817794378 9 connected 5461-10922  
  18. 099cfc6fbb785449a8bf5369a53d21a9e127fa42 192.168.39.153:7000 myself,master - 0 0 10 connected 0-5460  
  19. a8081e97862d9cf76c72d364f9a173187376f215 192.168.39.153:7003 slave 099cfc6fbb785449a8bf5369a53d21a9e127fa42 0 1480817792868 10 connected  

我们手动发送int信号终止这个进程，发现redis-server:7004进程已经被我们杀死了。

[cpp] view plain copy
  1. ubuntu@ubuntu-virtual-machine:~/redis-3.0.0/src$ ps aux | grep redis  
  2. ubuntu     6067  0.0  0.4  33148  4080 ?        Ss   11月27   0:00 SCREEN -S redis  
  3. ubuntu     7192  0.0  0.8  42300  8392 ?        Ssl  11月27   7:22 redis-server *:7000 [cluster]            
  4. ubuntu     7196  0.0  1.0  42300 10632 ?        Ssl  11月27   7:19 redis-server *:7001 [cluster]            
  5. ubuntu     7200  0.0  1.0  42300 10504 ?        Ssl  11月27   7:21 redis-server *:7002 [cluster]            
  6. ubuntu     7205  0.0  1.0  42300 10524 ?        Ssl  11月27   7:21 redis-server *:7003 [cluster]            
  7. ubuntu     7218  0.0  0.8  42300  8556 ?        Ssl  11月27   7:21 redis-server *:7005 [cluster]            
  8. ubuntu    56036  0.0  0.3  31128  3232 pts/6    S+   09:15   0:00 screen -r redis  
  9. ubuntu    56161  0.2  0.7  42304  7532 pts/25   Sl+  09:23   0:10 redis-sentinel *:27000 [sentinel]  
  10. ubuntu    56176  0.2  0.7  42304  7444 pts/26   Sl+  09:23   0:10 redis-sentinel *:27001 [sentinel]  
  11. ubuntu    56192  0.2  0.9  42304  9424 pts/27   Sl+  09:23   0:10 redis-sentinel *:27002 [sentinel]  
  12. ubuntu    56536  0.0  0.2  15944  2396 pts/12   R+   10:29   0:00 grep --color=auto redis  
  13. ubuntu@ubuntu-virtual-machine:~/redis-3.0.0/src$ redis-cli -p 7000   
  14. 127.0.0.1:7000> cluster info  
  15. cluster_state:ok  
  16. cluster_slots_assigned:16384  
  17. cluster_slots_ok:16384  
  18. cluster_slots_pfail:0  
  19. cluster_slots_fail:0  
  20. cluster_known_nodes:6  
  21. cluster_size:3  
  22. cluster_current_epoch:13  
  23. cluster_my_epoch:10  
  24. cluster_stats_messages_sent:2433366  
  25. cluster_stats_messages_received:2433005  
  26. 127.0.0.1:7000> cluster nodes  
  27. 930daea84150b5fabd32a95592781b27ceab1b71 192.168.39.153:7001 master - 0 1480818606296 13 connected 5461-10922  
  28. 8a6707d5b9269b6260315b47f300c1ab599733b7 192.168.39.153:7005 master - 0 1480818606797 11 connected 10923-16383  
  29. bdb62bb6ffce71588961f513c74b0d5a1a7145ea 192.168.39.153:7002 slave 8a6707d5b9269b6260315b47f300c1ab599733b7 0 1480818608306 11 connected  
  30. 81c884ebfc919ad293f02d797aff1033025ac27e 192.168.39.153:7004 master,fail - 1480818583889 1480818583084 9 disconnected  
  31. 099cfc6fbb785449a8bf5369a53d21a9e127fa42 192.168.39.153:7000 myself,master - 0 0 10 connected 0-5460  
  32. a8081e97862d9cf76c72d364f9a173187376f215 192.168.39.153:7003 slave 099cfc6fbb785449a8bf5369a53d21a9e127fa42 0 1480818607301 10 connected  

我们发现，在停止了一个master节点以后，集群在很短的时间内处理了故障转移，然后集群立刻恢复可用，原来的slave变成了master。可以看出来，sentinel成功发挥了故障处理的作用，在分布式的集群中，保证高可用性是很重要的一点，下节我们从源代码层次看看sentinel如何实现的故障转移。

posted @ 2018-04-01 23:56  SessionBest  阅读(6766)  评论(0)  编辑  收藏  举报