Shulou(Shulou.com)06/01 Report--

How to analyze redis replication, for this problem, this article details the corresponding analysis and solution, hoping to help more small partners who want to solve this problem find a simpler and easier way.

Compared with the use of RDS, NOSQL database although used, but ignored a lot, compared to the replication between databases,(physical replication, logical replication),redis replication, many people think it is relatively simple. There are some questions below.

1 redis What are the memory requirements for replication?

2 redis copy whether to push data or pull data

3 If two redis have the same replicationID and offset, can their data be consistent?

Can redis have two duplicate IDs?

First of all, there are a few facts that need not be listed.

1 replication is asynchronous

2 replication does not prevent work on master servers

3 Master can connect multiple slaves

4 Replications are controllable

5 Slaves are read-only.

6 copies can be master, that is, with the concept of cascade

The replication configuration is simple, as long as the replica information is configured in the slave repository and master authentication, the initial replication will work.

After the replication relationship between Master and replica is established, the master sends instructions to replica and sends information about the operation that occurred, key expiration, and processing to replica.

When the master and replica primary keys are disconnected due to some reasons, reconnect and synchronize again, and synchronize the data that is not in replica from master to replica. When this replication method cannot be synchronized normally, snapshot all the current data in master first and send it to replica. Then, in the subsequent replication process, the data operated by master is copied and re-placed into replica.

Question 1

Redis has more memory to consider in replication than stand-alone redis, typically 60% of redis 'allocated memory is used for primary tasks, and the rest is needed for bgsave and post-synchronization services.

The last sentence means that the data copied by reids is actually poured into memory, rather than the traditional database to perform the operation of falling disk and hardening the data. Therefore, redis data replication is memory-dependent, and the larger the memory reservation, the faster the replication speed, so reserving enough memory for REDIS is beneficial to accelerate replication.

Question 2 redis data should belong to the push way

I have actually looked up some information on this question, but there is no clear definition of whether the data is pull or push. But the official text below may answer that question. When replica is connected to the master, it sends psync command to the master, which contains if there is already a master and there is a replica, then send the offset of the master and replica it currently owns, and then the master will compare its current offset according to this information, and if data can be sent, it will start sending data. A full resynchronization occurs if the replica references a history (replica ID) that is no longer known: in this case, the replica gets a complete copy of the dataset from scratch.

So based on this text I think the way redis replicates is by pushing data from the master.

Question 3

The replication ID basically marks the history of a given dataset. Each time an instance starts from scratch as a primary instance, or a replica is promoted to primary, a new replica ID is generated for that instance. Replicas connected to the master inherit their replication IDs after the handshake. Therefore, there is an association between two instances with the same ID because they have the same data, but possibly at different times. For a given history record (copy ID) that holds the most recent data set, the offset acts as a logical time to understand. So two REDIS data with the same copy ID and OFFSET offset are synchronized.

Question 4

The reason Redis instances have two replica ids is to promote the replica to the primary replica. After a failover, the promoted replica still needs to remember its previous replica ID because such replica ID is the previous primary replica ID. This way, when other replicas are to synchronize with the new primary replica, they will attempt to perform a partial resynchronization using the old primary replica ID. This will work as expected because when the replica is promoted to primary ID, it will set its secondary ID to primary ID, keeping in mind the offset at which this ID switch occurred. Later, it will select a new random copy ID because a new history is started. When processing a new copy of the connection, the primary copy matches their IDs and offsets (up to a given offset for safety) using the current ID and secondary ID. In short, this means that replicas connected to the newly promoted primary do not have to perform full synchronization after a failover. Therefore, after a failover, a REDIS has to mount other new replicas, and it has two replica IDs.

About how to analyze redis copy the answer to the problem to share here, I hope the above content can be of some help to everyone, if you still have a lot of doubts not solved, you can pay attention to the industry information channel to learn more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.