Redis Persistent Replication Sentinel Cluster some understanding

Redis Persistent Replication Sentinel Cluster some understanding

I like to work in contact with a variety of database storage called the system, in general terms: Redis, Mysql, Kafka, ElasticSearch can be seen as a storage system. Individual storage systems to persist brush plate strategy, reliability assurance checkpoint mechanism, transaction mechanisms, data, some of the implementation details to ensure high availability of in-depth understanding of the basic principles behind the store, to compare them together, but also to better understand . When writing code, may only need to know the API they provide to complete most tasks, coupled with a strong operation and maintenance, and perhaps do not take focus on what to install, configure and maintain these "lock things", but this when the amount of data, performance issues, and are often unable to do anything.

Due to the use Redis in the work place is relatively simple whim that we look at the underlying data structure of a specific implementation principles, such as REDIS_ZSET, but the principle of storage, key expiration mechanism, little is known about the cluster. After reading "Redis Design and Implementation" and the official Documentation, feeling behind it all reflect the optimization: Redis is single-threaded (need to put the discussion under specific scenarios), Redis data types of the underlying implementation (object encoding) data less time uses a physical storage structure, automatically converted into another storage structure, there are some places uses for efficiency approximated idea in large volumes of data, these are so Redis very good.

Redis Persistent

Redis persistence start talking about, there are two: RDB and AOF. Since Redis is a memory database, so persistence mechanism to "conspicuous" than some of MySQL. In fact, for all of the outside storage systems, in addition to persistence mechanism to ensure the reliability of the data (the data is written to disk on which a permanent storage medium), behind it reflects: both disk and memory storage media differences in access speed. Disk access hundred milliseconds, the memory access may hundred microseconds, cpu cache access hundred nanosecond. It is this difference in the limited memory, disk brush strategy is to ensure that: the best operating data required for the program in the memory. For Redis, program data required in some data structure stored in memory, and that it needs is: how in-memory data "back up" to disk?

RDB: bgsave command execution save or generate rdb file, or to configuration parameters save 60 10000This put all the data stored on the disk. But this, there is still a big risk: After performing bgsave, Client and write some data to Redis Server on how to do? Or not enough time to perform bgsave Redis Server hung up on how to do?

AOF: Client write commands sent to the Server, Sever after the execution of the write command and append to aof_buf buffer, aof_buf buffer to somehow save the data to a file AOF. What way? This is related to the parameters and appendfsync.

Redis decide when to flush data to disk in aof_buf AOF files and the MySQL redo log buffer brush set parameters innodb_flush_log_at_trx_commitand Translog brush set parameters ElasticSearch's index.translog.durabilityvery similar. It is essentially how to balance the contradiction between the two efficiency and reliability:

How to ensure data is not lost one yet? Client writes a data disk I brush

Frequently refreshed disk, affecting Client write speed

The difference between RDB and AOF are:

• RDB is stored content data (key-value pairs), and save the AOF is a command (SET KEY VALUE), precisely because of AOF save file commands for optimizing the AOF: AOF AOF rewrite functions to reduce the file size.

• RDB is a point in time backup, I translate it into a designated backup. AOF according to the write command is continuously backed up.

  The RDB persistence performs point-in-time snapshots of your dataset at specified intervals.

  the AOF persistence logs every write operation received by the server, that will be played again at server startup, reconstructing the original dataset.

Redis Replication

Redis Replication is the cornerstone of Redis Sentinel and the Cluster. Other storage systems (such as ElasticSearch, Kafka) except that, Redis Replication is for a node , the node performs the SLAVEOF MASTER_IP PORTcommand to copy the asynchronous data to the master. In ElasticSearch or Kafka, they are naturally the data arranged multiple copies of the forms, the master copy ElasticSearch is called Primary shard, from the replica called Replica, Primary shard and replica distributed over different nodes, thus avoiding the Single Point Of Failure, and write data between multiple copies of the model is also known copy of the data model .

Redis Replication is copying data from a master node to the slave node, then copy it from where to start? Therefore, there is a complete re-synchronization (full resynchronization, triggered by the SYNC command) and partial synchronization (partial resynchronization, triggered by the PSYNC). When starting a new node from the master copy, perform a synchronization process (full or partial determination is performed synchronization), the synchronization is complete command into the propagation stage.

Here mention Redis partial resynchronization Replication ID involved, the version number is equivalent to the data in Redis Replication official document description:

Every Redis master has a replication ID: it is a large pseudo random string that marks a given story of the dataset.

Each master also takes an offset that increments for every byte of replication stream that it is produced to be sent to slaves, in order to update the state of the slaves with the new changes modifying the dataset.

When connected to Master Slave synchronization starts, it sends Replication ID, if they are consistent, comparison will be copied offset (offset), to determine whether part of resynchronization. How to deal with that after a certain Slave promoted to master, other Slave connect to the new master, the other held Slave Replication ID with the new master of Replication ID is certainly not the same, how to avoid that this situation could lead to a complete re-sync it?

However it is useful to understand what exctly is the replication ID, and why instances have actually two replication IDs the main ID and the secondary ID.

That there are two Replication ID: main ID and the secondary ID, by a secondary ID (old Replication ID), when connected to the other Slave new master, it does not require a complete re-synchronization:

The reason why Redis instances have two replication IDs is because of slaves that are promoted to masters. After a failover, the promoted slave requires to still remember what was its past replication ID, because such replication ID was the one of the former master. In this way, when other slaves will synchronize with the new master, they will try to perform a partial resynchronization using the old master replication ID.

Why are discussed below under Redis Replication is asynchronous? And based on Redis Replication Mechanism and the difference ElasticSearch and Kafka multi-copy mechanism is getting bigger, and there are very different in the realization of ideas.

Redis Replication Documentation for a while, here only discuss the first mechanisms

This system works using three main mechanisms:

1. When a master and a slave instances are well-connected, the master keeps the slave updated by sending a stream of commands to the slave, in order to replicate the effects on the dataset happening in the master side due to: client writes, keys expired or evicted, any other action changing the master dataset.

the master keeps the slave updated by sending a stream of commands to the slave, When sending it? Sending or what strategy? The sending strategy is Redis Replication is known as asynchronous replication reasons for it. Look at this one due to: client writes, keys expired or evicted, any other action changing, actually saying: redis master-slave replication how to handle Client write key expired, and so the key is Evict of? For example:

• After a Key Client write to the master node, this Key will be immediately synchronized to Slave success, and then returns a response to the Client?

• Redis Key expired how to do? Key was Evicted out how to do? expired and evicted or differentiated, focusing on key expired time to live (TTL) is after 0, and how to deal with key? Key expired, the keys may still exist in the Redis (active vs passive deletion policy to delete a policy). The evicted focus on: When the Redis memory usage reaches the max memory, according to maxmemory-policy configuration will delete a Key .

• In practice, generally uses master copy from the separate read and write, write Client Master, Read Slave. Therefore, after the keys on the Master expired, how promptly remove expired on Slave key so do not read Client expired data? Its official documentation says: Slave does not expire Key, Key on when the master has expired, send a command to the Slave DEL, let Slave also delete the expired key.

  so Redis uses three main techniques in order to make the replication of expired keys able to work:

  1. Slaves don't expire keys, instead they wait for masters to expire the keys. When a master expires a key (or evict it because of LRU), it synthesizes a DEL command which is transmitted to all the slaves.

In Redis Replication there is a problem: Allow writes only with N attached replicas: only when at least N Slave are "alive" in order to accept a write operation Client, which is the single point of failure in a way to ensure data reliability .

Starting with Redis 2.8, it is possible to configure a Redis master to accept write queries only if at least N slaves are currently connected to the master.

Note, however, due to the asynchronous replication feature Redis, and it does not guarantee Key must write the N Slave success. So I understand where the N Slave, in fact: as long as there are N slave and master node holds the normal connection, then you can write data

However, because Redis uses asynchronous replication it is not possible to ensure the slave actually received a given write, so there is always a window for data loss.

It is just a try to ensure data security mechanism, mainly by two parameters: min-slaves-to-writeand min-slaves-max-lag.

If there are at least N slaves, with a lag less than M seconds, then the write will be accepted.

You may think of it as a best effort data safety mechanism, where consistency is not ensured for a given write, but at least the time window for data loss is restricted to a given number of seconds. In general bound data loss is better than unbound one.

Then ElasticSearch and Kafka, but also with a very similar mechanism: ElasticSearch have a parameter wait_for_active_shards, it is also written in the Client a document to an ES index, check if there is an active fragment wait_for_active_shards this index, if so, it allows writing, of course, the number of active fragments and written examination (check-then-act) is a two-step operation, not an atomic operation , and therefore ElasticSearch also no guarantee that the document must successfully written wait_for_active_shards a slice to go. In fact, the return of the ACK response to the Client, a _shard field identifies the write operation succeeded several fragments failed several fragments. Also note that: ElasticSearch and Kafka introduce a "synchronous replica set" for a write operation (in-sync replication) mechanisms, Kafka also has a synchronized copy of the list of collections, remember broker parameters Kafka's min.insync.replicasrole in it? They are designed to relieve: the data is written only one node, it has not yet replicated to the other node, which will lead to the risk of downtime and data loss (this is often referred to single points of failure SPOF). ES five nodes of an index fragment below:

Extra talk about: try to ensure data security, is mentioned here by way of multiple copy / master-slave replication to ensure data security, aimed at cross-node, to avoid a single point of failure. There is also a stand-alone in terms of data security is for the persistence mechanism: write data to the memory, resulting in a dirty page, but has not yet had time to brush plate, the node is down how to do? Therefore, the storage system has a WAL (Write Ahead Log scheme), such as MySQL's redo log, ElasticSearch of Translog, its general idea is: the first to write a log write data, if failure occurs, the log files from the recovery has not yet persisted the data on the disk, thus ensuring data security.

Redis Sentinel vs Redis Cluster

Redis Sentinel Sentinel is a cluster monitor multiple sets master and slave node, Redis Cluster is a cluster composed of a plurality of master nodes, and each node can have a plurality of slave master nodes for data backup. Cluster Sentinel and have a high availability, its backing from the master copy by the data of "copy" stored on the plurality of nodes.

Redis Sentinel provides high availability for Redis. In practical terms this means that using Sentinel you can create a Redis deployment that resists without human intervention to certain kind of failures.

I think they are a major difference in data distribution, for Sentinel, it is all the data from one storage node (all key-value pairs), there is no so-called data in a distributed manner . If a Redis data store less than all of how to do? This is the Redis Cluster problem to be solved, it is common to store data by several master nodes, it can be linearly extended to 1000+ node.

High performance and linear scalability up to 1000 nodes. There are no proxies, asynchronous replication is used, and no merge operations are performed on values.

In Redis Cluster, the Key is the way by hashing a "slot assignment." The entire key space is divided into 16384 fixing grooves, each groove node which is responsible for assigning the processing tank. The distribution of data using the hash advantages: the ability to better ensure Key distribution is uniform, evenly distributed on each master node. There is clearly consistent hashing idea in it, the number of slots is fixed, only 16,384, but the number of nodes Redis can change dynamically, this time need only part of the data migration. When writing a Client Key, by first CRC16(kEY)%16383calculating the channel belongs to which this Key, and then query the slots array that is assigned to a slot which node, then put on a key-value pair stored to this node.

Speaking of data in a distributed manner, the nature of this problem is: Because the storage system is a cluster, more than one node, then put the data Which node (in fact, fragmentation / node partition resides) more appropriate on? It should be considered uniformly distributed data, i.e., data can not be inclined. In ElasticSearch when Client initiates the requested document index, without specifying docID, docID automatically generated, and the hash function murmur3 by selecting a suitable fragment to store the document. Similarly, in Kafka, a producer sends a message when the message is sent to the partition on which Kafka (Partition) it? This is the news partition mechanism Kafka, the default is polling Round-Robin algorithm, of course, you can also customize the message sent to the partitioning strategy specified partition.

Here focus on failover mechanism under highly :( failure of the automatic recovery)

Whether Redis Sentinel or Redis Cluster, if one node goes down, how to automatically restore it? Redis Sentinel's failover mechanism is as follows:

• Sentinel node of a monitor to a node fails, it will be marked as subjective offline

• Sentinel node to other nodes Sentinel asked whether the node has been really off the assembly line, when receiving the majority (sufficient number) of Sentinel nodes are considered when the node is offline, it will be marked as objective offline

• Sentinel cluster launch election to choose a primary Sentinel, responsible for the failed node Failover from the main Sentinel. Election algorithm Raft, election rules are first come first served: For example, multiple sources Sentinel (candidate Sentinel) poll request to the same goal Sentinel, who first arrived request, put the target Sentinel vote for whom. When a candidate Sentinel node acquired majority vote, has become the main Sentinel.

• Failover Sentinel by the main responsible for the failed node, choose to have "latest data" the Slave node as the new master node. Slave node called the latest data, in fact, is to determine: What slave node recently communicate with the Sentinel node, slave node configuration file priority, copy offset on the slave nodes and other factors, select the most appropriate slave node as the new master

  

Why should we elect a Sentinel Sentinel selected by the master in this way, by the main responsible for Failover Sentinel fault it? My understanding is: you first need to agree on the failed node, namely: agreed that a node failure does occur, then the recovery process should reach a consensus, can not appear: two Sentinel node failures while at the same node Failover situation, and in order to reach a consensus, consistency distributed election algorithm is the solution.

Finally, look at how Redis Cluster Failover is the failure of?

• Each node in the cluster on a regular basis to other nodes PING, a master node goes down, can not reply to PONG, it is marked as suspected offline (PFAILED)
• When most of the master node in the cluster that the node is down, the master node is marked as offline state (FAILED). The failure of the node is marked as FAILED node, the master node has a message to the cluster FAILE broadcasts.
• In this case, slave node has been found that it FAIL replication master node, and then initiates failover (with Redis Sentinel is different, where the fault failover initiated by the slave node)
• Each cluster master node to the next node failures master slave node to vote, access to most of the master slave nodes votes will become the new master node, where the election algorithm is also based on Raft implementation.

So far, Redis Persistent, Redis Replication, Redis Sentinel, Redis Cluster will probably introduced over. I found the Redis Tutorial and Documentation written is really good, there are "Redis Design and Implementation of" easy to understand, is a good understanding of the material Redis. Recent always wanted to summarize the principles behind each of the storage system, but unfortunately the technology and not enough time, can only write a little note as a record of it, I think the next is going to read the source code of the system, in order to have a better understanding.

Original link: https://www.cnblogs.com/hapjin/p/11181148.html

Reference: programmer cosmic timeline