A brief analysis of the principle of cluster master-slave replication in Redis

This article will give you an in-depth understanding of the master-slave replication principle of Redis cluster. I hope it will be helpful to you!

# 1. First of all, think about a question, why does redis need a distributed solution when its performance is so high?

1. To achieve higher performance: High-concurrency applications will have an impact on single-machine performance. More redis servers are needed to share the pressure and achieve load balancing

2. To achieve high availability: If Single machine to prevent downtime/hardware failure

3. Achieve scalability: Single machine memory and hardware are limited, realize horizontal expansion

redundant or sharded storage to achieve the above features.

2. Master-slave replication-replication configuration

Like Kafka, Mysql, and Rocketmq, redis supports cluster deployment. Cluster nodes are divided into master and slave. The master node It is the master, and the slave node is the slave (the latest is called a replica). The slave will synchronize the latest data from the master through the replication mechanism. Redis provides a very convenient command to enable master-slave replication. [Related recommendations: Redis Video Tutorial]

How to configure and enable master-slave replication?

Take building a pseudo cluster locally as an example. Port 6379 is the slave node and port 6378 is the master node.

1. Configure replicaof masterip masterport in redis.conf of the slave node. After starting the slave node, it will automatically connect to the master node and start synchronizing data.

If a new master node is replaced, this configuration will be rewritten.

2, or specify

./redis-server --replicaof masterip masterport

3 when starting the redis-server program, or log in to the client and execute the following command

slaveof masterip masterport

Note that this method is modified during operation , can achieve failover

Note: A slave node can also be the master node of other nodes, forming a cascade replication relationship. But other nodes also synchronize data from the top-level master node.

After configuring the cluster, check the cluster status through info replication

You can check the role information of the node in the cluster through the role command

Note that slave nodes are read-only. An error will be reported when writing the command.

How does slave exit the cluster? You can execute the following command:

slaveof no one

3. Master-slave replication process

1. First, the replica-replica joins the cluster

2. Establish a connection with the master, and check whether the data needs to be synchronized from the master node through a timer.

Source code description:

//每1s执行这个方法
void replicationCron(void) {
    ...
    //检查是否需要连接到master 如果是REPL_STATE_CONNECT状态，必须连接到master
    //#define REPL_STATE_CONNECT 1  Must connect to master 
    if (server.repl_state == REPL_STATE_CONNECT) {
        serverLog(LL_NOTICE,"Connecting to MASTER %s:%d",
            server.masterhost, server.masterport);
        //和master创建连接    
        if (connectWithMaster() == C_OK) {
            serverLog(LL_NOTICE,"MASTER <-> REPLICA sync started");
        }
    }
    
    //发送ping命令给slave 
    if ((replication_cron_loops % server.repl_ping_slave_period) == 0 &&
        listLength(server.slaves))
    {
        /* Note that we don&#39;t send the PING if the clients are paused during
         * a Redis Cluster manual failover: the PING we send will otherwise
         * alter the replication offsets of master and slave, and will no longer
         * match the one stored into &#39;mf_master_offset&#39; state. */
        int manual_failover_in_progress =
            server.cluster_enabled &&
            server.cluster->mf_end &&
            clientsArePaused();

        if (!manual_failover_in_progress) {
            ping_argv[0] = createStringObject("PING",4);
            replicationFeedSlaves(server.slaves, server.slaveseldb,
                ping_argv, 1);
            decrRefCount(ping_argv[0]);
        }
    }
    
    //发送换行符到所有slave,告诉slave等待接收rdb文件
    listRewind(server.slaves,&li);
    while((ln = listNext(&li))) {
        client *slave = ln->value;

        int is_presync =
            (slave->replstate == SLAVE_STATE_WAIT_BGSAVE_START ||
            (slave->replstate == SLAVE_STATE_WAIT_BGSAVE_END &&
             server.rdb_child_type != RDB_CHILD_TYPE_SOCKET));

        if (is_presync) {
            if (write(slave->fd, "\n", 1) == -1) {
                /* Don&#39;t worry about socket errors, it&#39;s just a ping. */
            }
        }
    }
    ...
}

3. Full copy process - supports diskless copy or rdb persistent copy

When the slave is connected to the master, use the psync (previously the sync command, which does not allow partial resynchronization, so now use PSYNC instead) command to initialize replication, and the master node replication id and processing Send to the master after exceeding the maximum offset.

The master node has the following two attributes, a replication id (mark instance), and an offset (mark written to the stream of the slave node)

Replication ID, offset

If there is not enough backlog in the master node buffer work, or if the replica references a historical record (replication ID) that is no longer known, a full resynchronization will occur

Source code description:

    //没有在rdb进程，没有aof重写进程
    if (server.rdb_child_pid == -1 && server.aof_child_pid == -1) {
        time_t idle, max_idle = 0;
        int slaves_waiting = 0;
        int mincapa = -1;
        listNode *ln;
        listIter li;

        listRewind(server.slaves,&li);
        while((ln = listNext(&li))) {
            client *slave = ln->value;
            //判断slave是否是等待bgsave状态
            if (slave->replstate == SLAVE_STATE_WAIT_BGSAVE_START) {
            //多久没有发送心跳或查询数据了 空闲时间间隔
                idle = server.unixtime - slave->lastinteraction;
                if (idle > max_idle) max_idle = idle;
                slaves_waiting++;
                mincapa = (mincapa == -1) ? slave->slave_capa :
                                            (mincapa & slave->slave_capa);
            }
        }

        if (slaves_waiting &&
            (!server.repl_diskless_sync ||
             max_idle > server.repl_diskless_sync_delay))
        {
            /* Start the BGSAVE. The called function may start a
             * BGSAVE with socket target or disk target depending on the
             * configuration and slaves capabilities. */
             //bgsave rdb生成
            startBgsaveForReplication(mincapa);
        }
    }

During the replication process, slave state transition process.

#4. In the command propagation stage, after full synchronization is performed, the master and slave will propagate commands to achieve data consistency.

4. Understanding replication ids

Every time an instance is restarted from scratch as the primary instance, or the replica is promoted to primary instance, a new replication ID will be generated for this instance. If two replicas have the same replication ID, they may have the same data at different times. For a given history (replication ID) that holds the latest data set, the offset is understood as a logical time. It needs to be judged by the two data of Replication ID and offset. Used to determine where the slave node has synchronized data.

5. Master-slave replication FAQ

1. What will happen if the slave itself has data?

slave first deletes its own data and then loads it with the rdb file.

2. During the process of generating rdb files, how to deal with client writing commands?

Save to the memory cache, and send it to the slave after the rdb is sent.

3. How does Redis replication handle key expiration?

1. The copy will not expire the key, but will wait for the host to expire the key. When the master expires a key (or evicts it due to LRU), it synthesizes a DEL command that is transmitted to all replicas.

2. However, due to the expiration of the host driver, sometimes the replica may still have a logically expired memory key because the master server cannot provide the DEL command in time. To handle this, the replica uses its logical clock to report that a key does not exist, only for read operations that do not violate the consistency of the data set (because new commands from the master will arrive)

3. Key expiration is not performed during Lua script execution. When a Lua script is run, time is conceptually frozen in the master node, so a given key will exist or not exist for all the time the script is running. This prevents the key from expiring in the middle of a script and requiring the key to send the same script to the replica in a way that guarantees the same effect in the dataset.

Once a replica is promoted to primary, it will start expiring keys independently and does not require any help from the old primary.

6. Master-slave replication summary

1. The problem of data backup is solved, but the RDB file is large, and the recovery time is long when transferring large files

2. If the master is abnormal, you need to manually elect the replica as the master

3. In the case of 1 master and multiple slaves, 1 master and 1 slave, there is still a single point problem

4. Redis Version 2.8.18 and later supports diskless replication with higher performance.

7. Replication instructions

1. Asynchronous replication is used by default, and the number of synchronized commands is confirmed through asynchronous asynchronous execution

2. One master can have multiple Each copy

3. A copy can also have its own copy. Starting from redis4.0, the copy will receive exactly the same replication stream from the master node

4. Replication can be used for scalability property, and can also be used for multiple copies of read-only queries

For more programming-related knowledge, please visit:Introduction to Programming! !

The above is the detailed content of A brief analysis of the principle of cluster master-slave replication in Redis. For more information, please follow other related articles on the PHP Chinese website!