Advertisement
Guest User

puppet-redis sentinel default conf

a guest
Mar 27th, 2014
354
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 5.78 KB | None | 0 0
  1. # Example sentinel.conf
  2.  
  3. # port <sentinel-port>
  4. # The port that this sentinel instance will run on
  5. port 26389
  6.  
  7. # sentinel monitor <master-name> <ip> <redis-port> <quorum>
  8. #
  9. # Tells Sentinel to monitor this master, and to consider it in O_DOWN
  10. # (Objectively Down) state only if at least <quorum> sentinels agree.
  11. #
  12. # Note that whatever is the ODOWN quorum, a Sentinel will require to
  13. # be elected by the majority of the known Sentinels in order to
  14. # start a failover, so no failover can be performed in minority.
  15. #
  16. # Note: master name should not include special characters or spaces.
  17. # The valid charset is A-z 0-9 and the three characters ".-_".
  18. sentinel monitor mymaster 127.0.0.1 6379 2
  19.  
  20. # sentinel auth-pass <master-name> <password>
  21. #
  22. # Set the password to use to authenticate with the master and slaves.
  23. # Useful if there is a password set in the Redis instances to monitor.
  24. #
  25. # Note that the master password is also used for slaves, so it is not
  26. # possible to set a different password in masters and slaves instances
  27. # if you want to be able to monitor these instances with Sentinel.
  28. #
  29. # However you can have Redis instances without the authentication enabled
  30. # mixed with Redis instances requiring the authentication (as long as the
  31. # password set is the same for all the instances requiring the password) as
  32. # the AUTH command will have no effect in Redis instances with authentication
  33. # switched off.
  34. #
  35. # Example:
  36. #
  37. # sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
  38.  
  39. # sentinel down-after-milliseconds <master-name> <milliseconds>
  40. #
  41. # Number of milliseconds the master (or any attached slave or sentinel) should
  42. # be unreachable (as in, not acceptable reply to PING, continuously, for the
  43. # specified period) in order to consider it in S_DOWN state (Subjectively
  44. # Down).
  45. #
  46. # Default is 30 seconds.
  47. sentinel down-after-milliseconds mymaster 30000
  48.  
  49. # sentinel parallel-syncs <master-name> <numslaves>
  50. #
  51. # How many slaves we can reconfigure to point to the new slave simultaneously
  52. # during the failover. Use a low number if you use the slaves to serve query
  53. # to avoid that all the slaves will be unreachable at about the same
  54. # time while performing the synchronization with the master.
  55. sentinel parallel-syncs mymaster 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 mymaster 180000
  81.  
  82. # SCRIPTS EXECUTION
  83. #
  84. # sentinel notification-script and sentinel reconfig-script are used in order
  85. # to configure scripts that are called to notify the system administrator
  86. # or to reconfigure clients after a failover. The scripts are executed
  87. # with the following rules for error handling:
  88. #
  89. # If script exists with "1" the execution is retried later (up to a maximum
  90. # number of times currently set to 10).
  91. #
  92. # If script exists with "2" (or an higher value) the script execution is
  93. # not retried.
  94. #
  95. # If script terminates because it receives a signal the behavior is the same
  96. # as exit code 1.
  97. #
  98. # A script has a maximum running time of 60 seconds. After this limit is
  99. # reached the script is terminated with a SIGKILL and the execution retried.
  100.  
  101. # NOTIFICATION SCRIPT
  102. #
  103. # sentinel notification-script <master-name> <script-path>
  104. #
  105. # Call the specified notification script for any sentinel event that is
  106. # generated in the WARNING level (for instance -sdown, -odown, and so forth).
  107. # This script should notify the system administrator via email, SMS, or any
  108. # other messaging system, that there is something wrong with the monitored
  109. # Redis systems.
  110. #
  111. # The script is called with just two arguments: the first is the event type
  112. # and the second the event description.
  113. #
  114. # The script must exist and be executable in order for sentinel to start if
  115. # this option is provided.
  116. #
  117. # Example:
  118. #
  119. # sentinel notification-script mymaster /var/redis/notify.sh
  120.  
  121. # CLIENTS RECONFIGURATION SCRIPT
  122. #
  123. # sentinel client-reconfig-script <master-name> <script-path>
  124. #
  125. # When the master changed because of a failover a script can be called in
  126. # order to perform application-specific tasks to notify the clients that the
  127. # configuration has changed and the master is at a different address.
  128. #
  129. # The following arguments are passed to the script:
  130. #
  131. # <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
  132. #
  133. # <state> is currently always "failover"
  134. # <role> is either "leader" or "observer"
  135. #
  136. # The arguments from-ip, from-port, to-ip, to-port are used to communicate
  137. # the old address of the master and the new address of the elected slave
  138. # (now a master).
  139. #
  140. # This script should be resistant to multiple invocations.
  141. #
  142. # Example:
  143. #
  144. # sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
  145.  
  146.  
  147. pidfile /var/run/redis_26389.pid
  148. dir /var/lib/redis/26389
  149. logfile /var/log/redis_26389.log
  150. daemonize yes
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement