1, redis What is the master-slave replication
Support data synchronization between multiple databases. Only a master database (master), may be from one or more databases (slave)
Primary database, can read and write
From the database, you can only read
When the primary database, doing the write operation, when finished, sends a signal to the Redis database, and transmits the information to the data from the database from the database backup.
Procedure:
1: When one, the master sends sync commands to the database from the database starts,
2: After receiving the sync command to the master database starts to save the snapshot (operation performed rdb) in the background, and during storage of the received command is cached
3: when the snapshot is complete, redis the snapshot file and send all buffered commands to the database.
4: receive from the database, the snapshot files will load and execute commands received from the cache.
2, when the main data It is down, how do?
Primary database, then down, will recommend a database from a database (slave) from the database, the master database as
3. How do you know the primary database goes down?
Sentinel mechanisms:
Redis Sentinel (sentinel) system for managing multiple Redis server, the system performs the following three tasks:
• Monitoring (Monitoring): Sentinel (sentinel) will continue to check if your Master and Slave functioning properly.
Remind (Notification): When monitoring a Redis problems, Sentinel (sentinel) can send notifications to the administrator or other applications via the API.
Automatic failover (Automatic failover): When a Master does not work, Sentinel (sentinel) will start an automatic failover operation, it will be one of the Slave Master failure upgraded to the new Master, and let the failure of other Master copy to the new Master Slave; when the client tries to connect Master failure, the cluster will return to the client terminal address of the new Master of such cluster may be used in place of Master Master failure.
Sentinel (sentinel) is a distributed system, you can run multiple Sentry (sentinel) in a process architecture, these processes use rumors protocol (gossipprotocols) to receive information about whether the Master off the assembly line, and use the voting agreement (agreement protocols ) to decide whether to perform automatic failover, as well as the new select which Slave Master.
each Sentinel (sentinel) will, master, slave regularly send messages to other Sentinel (sentinel), in order to confirm whether the other party "living", if it is found the other at a specified time (configurable) does not respond within, for the time being that the other side has been linked to (so-called "subjective view down" subjective Down, referred sdown).
if the "sentinel group" in the most sentinel, reported a master did not respond, the system was considered the master "completely dead" (ie: the objective real machine down, Objective Down, referred odown), vote through a certain algorithm, from the rest of the slave node, selected from a lift to master, and then automatically modify the configuration.
While the Sentinel (Sentinel) released as a separate executable redis-sentinel, but it is actually just a run in the special mode the Redis server, you can --sentinel given the option to start the Sentinel (sentinel) by ordinary when you start a Redis server.
Sentinel (sentinel) of some of the design ideas and is very similar zookeeper
4, from a single master copy and sentinel architecture of FIG.
5, the configuration from the master copy
192.168.178.110 (master)
192.168.178.112（slave）
192.168.178.115 (slave)
After three computers normal installation configuration redis, slave need to be configured as follows
vi /usr/local/redis/etc/redis.conf
slaveof 192.168.178.110 6379
masterauth 123456 --- Main redis server configuration password, you need to configure both are such configuration
After configuration, main redis
set name 'chris'
Two values can be obtained from redis get name, and there is no written authority
6, configure Sentinel
192.168.178.110 (master)
192.168.178.112（slave）
192.168.178.115 (slave)
192.168.178.115 (sentinel) Sentinel
In the sentinel redis server configuration is as follows:
1. Copy etc directory to
CP sentinel.conf / usr / local / Redis / etc
2. Modify sentinel.conf profile
sentinel monitor mymast 192.168.110.133 6379 1 # Name IP port number of the primary node election frequency
Sentinel Pass mymaster the auth-123456
. 3 modify the heartbeat detection 30 ms
Sentinel-Down After 30-milliseconds mymaster
4.sentinel Parallel-2 --- The syncs mymaster do how much more qualified node
5. start Sentinel mode
./redis-server / usr / local / redis / etc / sentinel .conf --sentinel &
Before starting sentinel, the first main redis, sequentially starting from redis;
Sentinel log follows: As can be seen from the relationship between the master
10687:X 02 Aug 22:51:03.405 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
10687:X 02 Aug 22:51:03.407 # Sentinel ID is 37ac433a3cdc235ae1326987feb3f13909612f84
10687:X 02 Aug 22:51:03.407 # +monitor master mymaster 192.168.178.110 6379 quorum 1
10687:X 02 Aug 22:51:03.409 * +slave slave 192.168.178.112:6379 192.168.178.112 6379 @ mymaster 192.168.178.110 6379
10687:X 02 Aug 22:51:03.413 * +slave slave 192.168.178.115:6379 192.168.178.115 6379 @ mymaster 192.168.178.110 6379
10687:X 02 Aug 22:51:03.463 # +sdown slave 192.168.178.115:6379 192.168.178.115 6379 @ mymaster 192.168.178.110 6379
10687:X 02 Aug 22:51:03.463 # +sdown slave 192.168.178.112:6379 192.168.178.112 6379 @ mymaster 192.168.178.110 6379
10687:X 02 Aug 22:51:03.521 # -sdown slave 192.168.178.112:6379 192.168.178.112 6379 @ mymaster 192.168.178.110 6379
On the master or the slave print server info master-slave relationship can be seen
7 Test
The 192.168.178.110 shutdown
# Keyspace
127.0.0.1:6379> SHUTDOWN
not connected>
Sentinel has been elected the new master redis
10687:X 02 Aug 22:54:36.822 # +sdown master mymaster 192.168.178.110 6379
10687:X 02 Aug 22:54:36.822 # +odown master mymaster 192.168.178.110 6379 #quorum 1/1
10687:X 02 Aug 22:54:36.822 # +new-epoch 1
10687:X 02 Aug 22:54:36.822 # +try-failover master mymaster 192.168.178.110 6379
10687:X 02 Aug 22:54:36.825 # +vote-for-leader 37ac433a3cdc235ae1326987feb3f13909612f84 1
10687:X 02 Aug 22:54:36.825 # +elected-leader master mymaster 192.168.178.110 6379
10687:X 02 Aug 22:54:36.825 # +failover-state-select-slave master mymaster 192.168.178.110 6379
10687:X 02 Aug 22:54:36.926 # +selected-slave slave 192.168.178.112:6379 192.168.178.112 6379 @ mymaster 192.168.178.110 6379
10687:X 02 Aug 22:54:36.926 * +failover-state-send-slaveof-noone slave 192.168.178.112:6379 192.168.178.112 6379 @ mymaster 192.168.178.110 6379
10687:X 02 Aug 22:54:36.985 * +failover-state-wait-promotion slave 192.168.178.112:6379 192.168.178.112 6379 @ mymaster 192.168.178.110 6379
10687:X 02 Aug 22:54:37.879 # +promoted-slave slave 192.168.178.112:6379 192.168.178.112 6379 @ mymaster 192.168.178.110 6379
10687:X 02 Aug 22:54:37.879 # +failover-state-reconf-slaves master mymaster 192.168.178.110 6379
10687:X 02 Aug 22:54:37.932 # +failover-end master mymaster 192.168.178.110 6379
10687:X 02 Aug 22:54:37.932 # +switch-master mymaster 192.168.178.110 6379 192.168.178.112 6379
10687:X 02 Aug 22:54:37.932 * +slave slave 192.168.178.115:6379 192.168.178.115 6379 @ mymaster 192.168.178.112 6379
10687:X 02 Aug 22:54:37.932 * +slave slave 192.168.178.110:6379 192.168.178.110 6379 @ mymaster 192.168.178.112 6379
10687:X 02 Aug 22:54:37.990 # +sdown master mymaster 192.168.178.112 6379
10687:X 02 Aug 22:54:37.990 # +odown master mymaster 192.168.178.112 6379 #quorum 1/1
10687:X 02 Aug 22:54:37.990 # +new-epoch 2
10687:X 02 Aug 22:54:37.990 # +try-failover master mymaster 192.168.178.112 6379
10687:X 02 Aug 22:54:37.993 # +vote-for-leader 37ac433a3cdc235ae1326987feb3f13909612f84 2
10687:X 02 Aug 22:54:37.993 # +elected-leader master mymaster 192.168.178.112 6379
10687:X 02 Aug 22:54:37.993 # +failover-state-select-slave master mymaster 192.168.178.112 6379
10687:X 02 Aug 22:54:37.993 # +sdown slave 192.168.178.110:6379 192.168.178.110 6379 @ mymaster 192.168.178.112 6379
10687:X 02 Aug 22:54:37.994 # +sdown slave 192.168.178.115:6379 192.168.178.115 6379 @ mymaster 192.168.178.112 6379
10687:X 02 Aug 22:54:38.095 # -failover-abort-no-good-slave master mymaster 192.168.178.112 6379
10687:X 02 Aug 22:54:38.172 # Next failover delay: I will not start a failover before Fri Aug 2 23:00:38 2019
10687:X 02 Aug 22:54:38.900 # -sdown master mymaster 192.168.178.112 6379
10687:X 02 Aug 22:54:38.900 # -odown master mymaster 192.168.178.112 6379
Twice elected, 192.168.178.112 was elected master
See info 192,168.178.112 is master again