Removing unused configuration and assocated variables
This commit is contained in:
parent
8bc6371d33
commit
6129031de4
|
|
@ -10,7 +10,6 @@
|
||||||
</service_access>
|
</service_access>
|
||||||
<service_restriction service='ead_web'>
|
<service_restriction service='ead_web'>
|
||||||
<ip interface='auto' netmask='rdClmask' netmask_type='SymLinkOption' ip_type='SymLinkOption'>rdClIP</ip>
|
<ip interface='auto' netmask='rdClmask' netmask_type='SymLinkOption' ip_type='SymLinkOption'>rdClIP</ip>
|
||||||
<ip interface='auto' netmask='255.255.255.255' ip_type='SymLinkOption'>redisMasterIP</ip>
|
|
||||||
</service_restriction>
|
</service_restriction>
|
||||||
</files>
|
</files>
|
||||||
<variables>
|
<variables>
|
||||||
|
|
@ -42,9 +41,6 @@
|
||||||
<variable name='redisRole' type='string' description="Role du serveur Redis">
|
<variable name='redisRole' type='string' description="Role du serveur Redis">
|
||||||
<value>Leader</value>
|
<value>Leader</value>
|
||||||
</variable>
|
</variable>
|
||||||
<variable name='redisMasterIP' type='ip' description="Adresse IP du Leader Redis"/>
|
|
||||||
<variable name='redisMasterPort' type='number' description="Port d'écoute du Leader Redis"/>
|
|
||||||
<variable name='redisMasterPassword' type='string' description="Passphrase d'accès à la grappe Redis"/>
|
|
||||||
<variable name='rdClMember' type='string' description="Nom du noeud" multi='True'/>
|
<variable name='rdClMember' type='string' description="Nom du noeud" multi='True'/>
|
||||||
<variable name='rdClMemberIP' type='ip' description="Adresse IP du noeud" multi='True'/>
|
<variable name='rdClMemberIP' type='ip' description="Adresse IP du noeud" multi='True'/>
|
||||||
<variable name='rdClMemberPort' type='number' description="Port d'écoute du noeud" multi='True'/>
|
<variable name='rdClMemberPort' type='number' description="Port d'écoute du noeud" multi='True'/>
|
||||||
|
|
@ -69,18 +65,9 @@
|
||||||
<condition name='disabled_if_in' source='redisMode'>
|
<condition name='disabled_if_in' source='redisMode'>
|
||||||
<param>Local</param>
|
<param>Local</param>
|
||||||
<target type='variable'>redisRole</target>
|
<target type='variable'>redisRole</target>
|
||||||
<target type='variable'>redisMasterIP</target>
|
|
||||||
<target type='variable'>redisMasterPort</target>
|
|
||||||
<target type='variable'>redisMasterPassword</target>
|
|
||||||
<target type='filelist'>redisCl</target>
|
<target type='filelist'>redisCl</target>
|
||||||
</condition>
|
</condition>
|
||||||
|
|
||||||
<condition name='disabled_if_in' source='redisRole'>
|
|
||||||
<param>Leader</param>
|
|
||||||
<target type='variable'>redisMasterIP</target>
|
|
||||||
<target type='variable'>redisMasterPort</target>
|
|
||||||
</condition>
|
|
||||||
|
|
||||||
<condition name='disabled_if_in' source='redisRole'>
|
<condition name='disabled_if_in' source='redisRole'>
|
||||||
<param>Node</param>
|
<param>Node</param>
|
||||||
<target type='filelist'>redisCl</target>
|
<target type='filelist'>redisCl</target>
|
||||||
|
|
|
||||||
219
tmpl/redis.conf
219
tmpl/redis.conf
|
|
@ -246,225 +246,6 @@ dbfilename dump.rdb
|
||||||
# Note that you must specify a directory here, not a file name.
|
# Note that you must specify a directory here, not a file name.
|
||||||
dir /var/lib/redis
|
dir /var/lib/redis
|
||||||
|
|
||||||
%if %%getVar('redisRole','Leader') == "Node"
|
|
||||||
################################# REPLICATION #################################
|
|
||||||
|
|
||||||
# Master-Slave replication. Use slaveof to make a Redis instance a copy of
|
|
||||||
# another Redis server. A few things to understand ASAP about Redis replication.
|
|
||||||
#
|
|
||||||
# 1) Redis replication is asynchronous, but you can configure a master to
|
|
||||||
# stop accepting writes if it appears to be not connected with at least
|
|
||||||
# a given number of slaves.
|
|
||||||
# 2) Redis slaves are able to perform a partial resynchronization with the
|
|
||||||
# master if the replication link is lost for a relatively small amount of
|
|
||||||
# time. You may want to configure the replication backlog size (see the next
|
|
||||||
# sections of this file) with a sensible value depending on your needs.
|
|
||||||
# 3) Replication is automatic and does not need user intervention. After a
|
|
||||||
# network partition slaves automatically try to reconnect to masters
|
|
||||||
# and resynchronize with them.
|
|
||||||
#
|
|
||||||
slaveof %%redisMasterIP %%redisMasterPort
|
|
||||||
|
|
||||||
# If the master is password protected (using the "requirepass" configuration
|
|
||||||
# directive below) it is possible to tell the slave to authenticate before
|
|
||||||
# starting the replication synchronization process, otherwise the master will
|
|
||||||
# refuse the slave request.
|
|
||||||
#
|
|
||||||
masterauth %%redisMasterPassword
|
|
||||||
|
|
||||||
# When a slave loses its connection with the master, or when the replication
|
|
||||||
# is still in progress, the slave can act in two different ways:
|
|
||||||
#
|
|
||||||
# 1) if slave-serve-stale-data is set to 'yes' (the default) the slave will
|
|
||||||
# still reply to client requests, possibly with out of date data, or the
|
|
||||||
# data set may just be empty if this is the first synchronization.
|
|
||||||
#
|
|
||||||
# 2) if slave-serve-stale-data is set to 'no' the slave will reply with
|
|
||||||
# an error "SYNC with master in progress" to all the kind of commands
|
|
||||||
# but to INFO and SLAVEOF.
|
|
||||||
#
|
|
||||||
slave-serve-stale-data yes
|
|
||||||
|
|
||||||
# You can configure a slave instance to accept writes or not. Writing against
|
|
||||||
# a slave instance may be useful to store some ephemeral data (because data
|
|
||||||
# written on a slave will be easily deleted after resync with the master) but
|
|
||||||
# may also cause problems if clients are writing to it because of a
|
|
||||||
# misconfiguration.
|
|
||||||
#
|
|
||||||
# Since Redis 2.6 by default slaves are read-only.
|
|
||||||
#
|
|
||||||
# Note: read only slaves are not designed to be exposed to untrusted clients
|
|
||||||
# on the internet. It's just a protection layer against misuse of the instance.
|
|
||||||
# Still a read only slave exports by default all the administrative commands
|
|
||||||
# such as CONFIG, DEBUG, and so forth. To a limited extent you can improve
|
|
||||||
# security of read only slaves using 'rename-command' to shadow all the
|
|
||||||
# administrative / dangerous commands.
|
|
||||||
slave-read-only yes
|
|
||||||
|
|
||||||
# Replication SYNC strategy: disk or socket.
|
|
||||||
#
|
|
||||||
# -------------------------------------------------------
|
|
||||||
# WARNING: DISKLESS REPLICATION IS EXPERIMENTAL CURRENTLY
|
|
||||||
# -------------------------------------------------------
|
|
||||||
#
|
|
||||||
# New slaves and reconnecting slaves that are not able to continue the replication
|
|
||||||
# process just receiving differences, need to do what is called a "full
|
|
||||||
# synchronization". An RDB file is transmitted from the master to the slaves.
|
|
||||||
# The transmission can happen in two different ways:
|
|
||||||
#
|
|
||||||
# 1) Disk-backed: The Redis master creates a new process that writes the RDB
|
|
||||||
# file on disk. Later the file is transferred by the parent
|
|
||||||
# process to the slaves incrementally.
|
|
||||||
# 2) Diskless: The Redis master creates a new process that directly writes the
|
|
||||||
# RDB file to slave sockets, without touching the disk at all.
|
|
||||||
#
|
|
||||||
# With disk-backed replication, while the RDB file is generated, more slaves
|
|
||||||
# can be queued and served with the RDB file as soon as the current child producing
|
|
||||||
# the RDB file finishes its work. With diskless replication instead once
|
|
||||||
# the transfer starts, new slaves arriving will be queued and a new transfer
|
|
||||||
# will start when the current one terminates.
|
|
||||||
#
|
|
||||||
# When diskless replication is used, the master waits a configurable amount of
|
|
||||||
# time (in seconds) before starting the transfer in the hope that multiple slaves
|
|
||||||
# will arrive and the transfer can be parallelized.
|
|
||||||
#
|
|
||||||
# With slow disks and fast (large bandwidth) networks, diskless replication
|
|
||||||
# works better.
|
|
||||||
repl-diskless-sync no
|
|
||||||
|
|
||||||
# When diskless replication is enabled, it is possible to configure the delay
|
|
||||||
# the server waits in order to spawn the child that transfers the RDB via socket
|
|
||||||
# to the slaves.
|
|
||||||
#
|
|
||||||
# This is important since once the transfer starts, it is not possible to serve
|
|
||||||
# new slaves arriving, that will be queued for the next RDB transfer, so the server
|
|
||||||
# waits a delay in order to let more slaves arrive.
|
|
||||||
#
|
|
||||||
# The delay is specified in seconds, and by default is 5 seconds. To disable
|
|
||||||
# it entirely just set it to 0 seconds and the transfer will start ASAP.
|
|
||||||
repl-diskless-sync-delay 5
|
|
||||||
|
|
||||||
# Slaves send PINGs to server in a predefined interval. It's possible to change
|
|
||||||
# this interval with the repl_ping_slave_period option. The default value is 10
|
|
||||||
# seconds.
|
|
||||||
#
|
|
||||||
# repl-ping-slave-period 10
|
|
||||||
|
|
||||||
# The following option sets the replication timeout for:
|
|
||||||
#
|
|
||||||
# 1) Bulk transfer I/O during SYNC, from the point of view of slave.
|
|
||||||
# 2) Master timeout from the point of view of slaves (data, pings).
|
|
||||||
# 3) Slave timeout from the point of view of masters (REPLCONF ACK pings).
|
|
||||||
#
|
|
||||||
# It is important to make sure that this value is greater than the value
|
|
||||||
# specified for repl-ping-slave-period otherwise a timeout will be detected
|
|
||||||
# every time there is low traffic between the master and the slave.
|
|
||||||
#
|
|
||||||
# repl-timeout 60
|
|
||||||
|
|
||||||
# Disable TCP_NODELAY on the slave socket after SYNC?
|
|
||||||
#
|
|
||||||
# If you select "yes" Redis will use a smaller number of TCP packets and
|
|
||||||
# less bandwidth to send data to slaves. But this can add a delay for
|
|
||||||
# the data to appear on the slave side, up to 40 milliseconds with
|
|
||||||
# Linux kernels using a default configuration.
|
|
||||||
#
|
|
||||||
# If you select "no" the delay for data to appear on the slave side will
|
|
||||||
# be reduced but more bandwidth will be used for replication.
|
|
||||||
#
|
|
||||||
# By default we optimize for low latency, but in very high traffic conditions
|
|
||||||
# or when the master and slaves are many hops away, turning this to "yes" may
|
|
||||||
# be a good idea.
|
|
||||||
repl-disable-tcp-nodelay no
|
|
||||||
|
|
||||||
# Set the replication backlog size. The backlog is a buffer that accumulates
|
|
||||||
# slave data when slaves are disconnected for some time, so that when a slave
|
|
||||||
# wants to reconnect again, often a full resync is not needed, but a partial
|
|
||||||
# resync is enough, just passing the portion of data the slave missed while
|
|
||||||
# disconnected.
|
|
||||||
#
|
|
||||||
# The bigger the replication backlog, the longer the time the slave can be
|
|
||||||
# disconnected and later be able to perform a partial resynchronization.
|
|
||||||
#
|
|
||||||
# The backlog is only allocated once there is at least a slave connected.
|
|
||||||
#
|
|
||||||
# repl-backlog-size 1mb
|
|
||||||
|
|
||||||
# After a master has no longer connected slaves for some time, the backlog
|
|
||||||
# will be freed. The following option configures the amount of seconds that
|
|
||||||
# need to elapse, starting from the time the last slave disconnected, for
|
|
||||||
# the backlog buffer to be freed.
|
|
||||||
#
|
|
||||||
# A value of 0 means to never release the backlog.
|
|
||||||
#
|
|
||||||
# repl-backlog-ttl 3600
|
|
||||||
|
|
||||||
# The slave priority is an integer number published by Redis in the INFO output.
|
|
||||||
# It is used by Redis Sentinel in order to select a slave to promote into a
|
|
||||||
# master if the master is no longer working correctly.
|
|
||||||
#
|
|
||||||
# A slave with a low priority number is considered better for promotion, so
|
|
||||||
# for instance if there are three slaves with priority 10, 100, 25 Sentinel will
|
|
||||||
# pick the one with priority 10, that is the lowest.
|
|
||||||
#
|
|
||||||
# However a special priority of 0 marks the slave as not able to perform the
|
|
||||||
# role of master, so a slave with priority of 0 will never be selected by
|
|
||||||
# Redis Sentinel for promotion.
|
|
||||||
#
|
|
||||||
# By default the priority is 100.
|
|
||||||
slave-priority 100
|
|
||||||
|
|
||||||
# It is possible for a master to stop accepting writes if there are less than
|
|
||||||
# N slaves connected, having a lag less or equal than M seconds.
|
|
||||||
#
|
|
||||||
# The N slaves need to be in "online" state.
|
|
||||||
#
|
|
||||||
# The lag in seconds, that must be <= the specified value, is calculated from
|
|
||||||
# the last ping received from the slave, that is usually sent every second.
|
|
||||||
#
|
|
||||||
# This option does not GUARANTEE that N replicas will accept the write, but
|
|
||||||
# will limit the window of exposure for lost writes in case not enough slaves
|
|
||||||
# are available, to the specified number of seconds.
|
|
||||||
#
|
|
||||||
# For example to require at least 3 slaves with a lag <= 10 seconds use:
|
|
||||||
#
|
|
||||||
# min-slaves-to-write 3
|
|
||||||
# min-slaves-max-lag 10
|
|
||||||
#
|
|
||||||
# Setting one or the other to 0 disables the feature.
|
|
||||||
#
|
|
||||||
# By default min-slaves-to-write is set to 0 (feature disabled) and
|
|
||||||
# min-slaves-max-lag is set to 10.
|
|
||||||
|
|
||||||
# A Redis master is able to list the address and port of the attached
|
|
||||||
# slaves in different ways. For example the "INFO replication" section
|
|
||||||
# offers this information, which is used, among other tools, by
|
|
||||||
# Redis Sentinel in order to discover slave instances.
|
|
||||||
# Another place where this info is available is in the output of the
|
|
||||||
# "ROLE" command of a masteer.
|
|
||||||
#
|
|
||||||
# The listed IP and address normally reported by a slave is obtained
|
|
||||||
# in the following way:
|
|
||||||
#
|
|
||||||
# IP: The address is auto detected by checking the peer address
|
|
||||||
# of the socket used by the slave to connect with the master.
|
|
||||||
#
|
|
||||||
# Port: The port is communicated by the slave during the replication
|
|
||||||
# handshake, and is normally the port that the slave is using to
|
|
||||||
# list for connections.
|
|
||||||
#
|
|
||||||
# However when port forwarding or Network Address Translation (NAT) is
|
|
||||||
# used, the slave may be actually reachable via different IP and port
|
|
||||||
# pairs. The following two options can be used by a slave in order to
|
|
||||||
# report to its master a specific set of IP and port, so that both INFO
|
|
||||||
# and ROLE will report those values.
|
|
||||||
#
|
|
||||||
# There is no need to use both the options if you need to override just
|
|
||||||
# the port or the IP address.
|
|
||||||
#
|
|
||||||
# slave-announce-ip 5.5.5.5
|
|
||||||
# slave-announce-port 1234
|
|
||||||
%end if
|
|
||||||
################################## SECURITY ###################################
|
################################## SECURITY ###################################
|
||||||
|
|
||||||
# Require clients to issue AUTH <PASSWORD> before processing any other
|
# Require clients to issue AUTH <PASSWORD> before processing any other
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue