Redis articles from 6-replication master copy mode and Sentinel

Outline

• Official Description: https: //redis.io/topics/replication
• Role: Read (Slave) write (Master) separation, disaster recovery
• Sentinel unattended mode
• Cons: master-slave replication will no doubt bring a delay (Master to Slave machine synchronous machine), Sentinel mode using the delay will be more obvious.

---

Preparation test configuration (a two backup host machine)

Copying the plurality of configuration files are named to distinguish redis {port} .conf

• Master port 6379
• Slave1 port 6380
• Slave2 port 6381
• Other convenient configuration differences
  • Way to start using a background service daemonize yes
  • pidfile redis{port}.pid
  • logfile redis{port}.log
  • dbfilename dump{port}.rdb

---

Test 1 Master <Slave1, Slave2

• Respectively starts and connects the three services
  redis-server redis{port}.conf ps -ef|grep redis|grep -v grep redis-cli -p {port}
• Client to view information about master-slave replication info replication
# Replication role:master connected_slaves:0 master_replid:d3d1de9a393d82c4dc1787800471fffba1323b3a master_replid2:0000000000000000000000000000000000000000 master_repl_offset:0 second_repl_offset:-1 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0
• Began to copy data from a master

  • Master

    set k1 v1
    set k2 v2

  • Slave1 and Slave2

    get k1
    slaveof 127.0.0.1 6379
    get k1
    get k2

  • We can see Slave Master data has been copied over the
  • Master continues to set KV, data synchronization verification Slave
  • View copy information from the master again info replicationcan see the information matches
  • Will be written on Slave error
    (error) READONLY You can't write against a read only replica.
• The Master shutdown, Slave does not move
  • Slave View info replication
  • Slave data still can be seen, and also the relationship with the Master
  • When Master is restarted, the master-slave relationship ever recover
• The Slave1 shutdown, Master does not move
  • Slave2 master-slave relationship will not change
  • Slave1 after the restart, master-slave relationship is gone, need to re- slaveof 127.0.0.1 6379synchronize data
  • If you want to hang Slave / broken after restart "again later", the need for Slave-server configuration replicaof 127.0.0.1 6379

---

Test 2 Master <Slave1 <Slave2 (Slave1 Slave2 is the Master)

• It can be a Slave Master Slave of the next, so you can share the writing pressure Master
• Slave2 change Master:slaveof 127.0.0.1 6380
• View from the main Slave1 information changes:info replication
• Currently Overall, data integrity, and before the "one main two servant" model is the same, only now Slave2 is Slave1 synchronize data from, into a "passing the torch" mode, Slave1 how to share the pressure of the Master? Continue ..
• The Master shutdown, the analog Master machine hung up, this time can Slave1 slaveof no one, so that the new Master Slave1 "to become masters" (role has become Slave Master), so that you can write to them, and continue to master-slave relationship and Slave2
• At this point, the original Master restart recovery services, will become a separate Master service, the original Slave1, Slave2 isolated out.
• Then, re-hang Slave1 to Master, restore the most primitive "one main two servant" relationship, you will find Slave1 and Slave2 in Slave1 "to become masters" during the writing of the data is gone, and become Master of the data. It can be seen after the change Slave Master, Slave data will be cleared first, and then synchronize the data for the new Master

---

Sentinel (sentinel) mode

Explanation

• The previous test, hang up when the Master, you also need to artificially converted to a Slave Master, in fact, a machine hang may occur at any time, such as early morning, so you can not rely on man-made process.
• Sentry mode to make up for the shortcomings of the above, to achieve the so-called "lights-out" effect.
• Effect 1: Use Sentinel mode, the other will start a process of Master monitoring, if monitoring the Master fails, the Slave automatically upgraded to a new Master (see sentinel log can see details of the vote) in accordance with the voting mechanism.
• Effect 2: Sentinel mode Slave1 upgraded to Master, if the original Master restored after sentinel surveillance to automatically downgrade linked to the original Master Slave1, completely changing the master-slave relationship.

Configuration and testing

• Recovery "two main slave" mode, a Master (79), two Slave (80,81)
• New sentinel profile vi sentinel.conf, content:
  sentinel monitor master6379 127.0.0.1 6379 1
  Description:
  • sentinel monitor ... Master monitor indicates the sentinel on the rear of the machine
  • master6379 To listen to the Master behind a name
  • 127.0.0.1 6379 Master interception target ip and port services
  • The last digit indicates the number of sentinel m = 1 vote, that is, when there are n sentinel (sentinel clusters) think the Master hung up when, will think it's really hung up, and then failover operation. This is a stand-alone test, it is set to 1 n directly.
  • The new line can be, listen to multiple hosts Master
• Start Sentinel
  redis-sentinel sentinel.conf 或者 redis-server sentinel.conf --sentinel
  after the start you can see the log:
  # Sentinel ID is 89568e210930ec9fe58e4cf856a5ef8e14501955 # +monitor master master6379 127.0.0.1 6379 quorum 1 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ master6379 127.0.0.1 6379 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ master6379 127.0.0.1 6379
• The Master shutdown, observation Sentinel logs
  # +sdown master master6379 127.0.0.1 6379 # +odown master master6379 127.0.0.1 6379 #quorum 1/1 # +new-epoch 1 # +try-failover master master6379 127.0.0.1 6379 # +vote-for-leader 89568e210930ec9fe58e4cf856a5ef8e14501955 1 # +elected-leader master master6379 127.0.0.1 6379 # +failover-state-select-slave master master6379 127.0.0.1 6379 # +selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ master6379 127.0.0.1 6379 * +failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ master6379 127.0.0.1 6379 * +failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ master6379 127.0.0.1 6379 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ master6379 127.0.0.1 6379 # +failover-state-reconf-slaves master master6379 127.0.0.1 6379 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ master6379 127.0.0.1 6379 * +slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ master6379 127.0.0.1 6379 * +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ master6379 127.0.0.1 6379 # +failover-end master master6379 127.0.0.1 6379 # +switch-master master6379 127.0.0.1 6379 127.0.0.1 6380 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ master6379 127.0.0.1 6380 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ master6379 127.0.0.1 6380 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ master6379 127.0.0.1 6380
  can be seen, sentinel surveillance to 79Master hung up, then vote OK, and then re-elected 80 new Master.
• View original Slave from the main information can be seen 80Slave's role became Master
• Restart 79Master, view logs and sentinel master-slave relationship
  * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ master6379 127.0.0.1 6380
  can also be seen from the log, the sentry to 79 convert-to-slave operation