Redis主备同步

slave状态变迁

#define REDIS_REPL_NONE 0 /* No active replication */
#define REDIS_REPL_CONNECT 1 /* Must connect to master */
#define REDIS_REPL_CONNECTING 2 /* Connecting to master */
#define REDIS_REPL_RECEIVE_PONG 3 /* Wait for PING reply */
#define REDIS_REPL_TRANSFER 4 /* Receiving .rdb from master */
#define REDIS_REPL_CONNECTED 5 /* Connected to master */

server.repl_state储存slave当前的复制状态

* redis启动时初始化为REDIS_REPL_NONE

* 当接受到slaveof命令后,该redis转换为slave,同时状态变为REDIS_REPL_CONNECT

周期性执行的replicationCron会检查slave当前的状态,来执行不同的操作

  • 如果slave处于REDIS_REPL_CONNECT,调用connectWithMaster建立到master的连接,状态转换为REDIS_REPL_CONNECTING
  • 连接建立后,向master发送PING,状态转换为REDIS_REPL_RECEIVE_PONG
  • 接受到PONG后,如果master配置了需要认证,则slave发送AUTH消息,AUTH通过后;slave发送REPLCONF listening-port消息到master告知自身监听的端口;最后向master发送SYNC命令来请求同步rdb文件,同时状态转换为REDIS_REPL_TRANSFER。
  • 当master向slave发送rdb后,slave就开始读取rdb文件(master发送rdb前会先告知rdb文件的总长度),slave接受完rdb文件后,会emptyDb清空数据库,然后调用rdbLoad加载从master接受到的rdb文件,加载完成后状态变为REDIS_REPL_CONNECTED,接下来slave会继续接受从master同步过来的新操作,以保证主备的一致性。

master状态变迁

#define REDIS_REPL_WAIT_BGSAVE_START 6 /* We need to produce a new RDB file. */
#define REDIS_REPL_WAIT_BGSAVE_END 7 /* Waiting RDB file creation to finish. */
#define REDIS_REPL_SEND_BULK 8 /* Sending RDB file to slave. */
#define REDIS_REPL_ONLINE 9 /* RDB file transmitted, sending just updates. */

server.slaves里维护所有的slave列表,slave.replstate里记录着每个slave当前的同步状态(从master的视角看)。

  • 当master接受到slave发来的sync/psync命令时,将该slave的状态转换为REDIS_REPL_WAIT_BGSAVE_START
  • master为该slave后台启动rdbSaveBackground,并将该slave的状态转换为REDIS_REPL_WAIT_BGSAVE_END (如果master己收到sync时,master正在为某个slave转储rdb文件,则新的slave可以直接进入REDIS_REPL_WAIT_BGSAVE_END状态)
  • 当rdbSaveBackground完成后,slave的状态转换为REDIS_REPL_SEND_BULK,master开始将rdb文件发送给slave,发送前会先发送rdb文件的长度信息。
  • 当rdb文件发送完成后,slave的状态转换为REDIS_REPL_ONLINE。

master在为slave启动rdbSaveBackground后,master上的更新会累积到slave的连接缓冲区,等到slave接受完rdb文件之后,将缓冲区里累积的更新同步到slave上

主备同步时序

  1. 管理员向server发送slaveof master-ip master-port,将该server变为master的slave
  2. slave建立到master的网络连接
  3. slave向master发送PING检测网络状态,master回复+PONG
  4. slave向master发送AUTH进行认证(可选),master恢复+OK
  5. slave向master发送REPLCONF listening-port,master恢复+OK
  6. slave向master发送sync/psync,master开始后台转储rdb文件
  7. master转储rdb完成后,向slave发送rdb文件,slave接受rdb文件并清空数据库,load从master接受到的rdb文件
  8. master将rdb转储及传输期间累积的更新操作同步到slave
  9. master与slave数据到达一致,接下来master接受到的所有更新操作都会同步到slave

主备同步状态维护

master周期性的ping slave(默认10s),当ping不通slave超过60s(默认)后,就会认为slave挂掉了,便会断开与该slave的连接;同理,slave如果超过一定时间没有接受到master的PING,会认为master挂掉了,便会断开与master的连接。

当master、slave连接断开后,slave需要重新向master请求同步rdb文件;2.8版本里redis一定程度支持增量同步,master将同步数据同步给slave时,会同时存储到一个环形缓冲区(默认1M大小),这个缓冲区永远存储最新的同步数据;另外master、slave都会记录当前同步的offset。

当slave与master断开后,slave会先尝试进行PSYNC增量同步,如果连接断开期间,master没有重启过,并且slave的offset在master的环形缓冲区内,则可直接进行增量同步,比如:

假设环形缓冲区的长度为1000, master的同步offset为10000,此时缓冲区里记录的是9001-10000的同步数据,slave同步到9500时,与master断开了连接;slave重新建立与master连接后,会带上offset 9500,请求增量同步,master发现该slave的offset在9001-10000之间,可以进行增量同步,将9501-10000的同步数据发送给slave,以达到主备一致的状态。

时间: 2024-09-12 08:22:02

Redis主备同步的相关文章

haproxy配置监控redis主备切换(转)

环境前提:     redis sentinel配置,三台主机,且配置运行良好        配置文件中添加: frontend ft_redis  bind 0.0.0.0:6379 name redis  default_backend bk_redis   backend bk_redis  option tcp-check  tcp-check connect  tcp-check send PING\r\n  tcp-check expect string +PONG  tcp-che

MySQL内核月报 2014.10-TokuDB· 主备复制·Read Free Replication

尽管MySQL 5.6和MariaDB 10.x在replication上已经做了不少优化,TokuDB 7.5也做了一个"进一步"的优化:Read Free Replication(RFR),目的是提高备库(slave)重放速度,减少主备延迟. RFR的原理比较简单:就是避免一些"不必要"的读来减少read IO. Read IO 当在slave上执行:UPDATE/DELETE操作的时候,MySQL进行read-modify-write操作,可能会产生read IO操作,而INSERT的时候

求教oracle dataguard 主备库日志无法同步的问题

问题描述 求教oracle dataguard 主备库日志无法同步的问题 现在做data guard 测试,试了很多次,主库的日志一直 无法同步到备份库.求高手解答. 测试环境 主库::操作系统 redhat 5.8 地址 192.168.1.135 数据库版本 oracle 10.2.0 备库: 操作系统 redhat 5.8 地址 192.168.1.3 数据库版本 oracle 10.2.0 主库参数文件 orcl.__db_cache_size=390070272 orcl.__java

主备不一致:Table definition on master and slave does not match

昨天一同事在线上做变更,为了保证主库的稳定性,先在备库把binlog关闭,然后在进行DDL变更,在通过切换HA,把备库切换为主库,在老的主库上做DDL变更 看上去这样做法没有太大的问题,但是当备库变更一做完,HA切换到备库,开始老主库变更的时候,备库就出现复制出现错误: Last_Error: Table definition on master and slave does not match: Column 10 type mismatch – received type 3, dbname

mysql 主备复制下的可靠性漫谈(三)

引言:    前面两期主要针对各种故障条件下,对数据可靠性带来的挑战及普通应对策略.本文主要针对在主备非强同步复制模式下,能否保证数据可靠性来讨论. 复制模式概述:    异步模式:主库收到commit 请求后,依次执行:写redo log prepare,写入binlog,写redo log commit,返回客户端成功.         半同步模式:主库收到commit 后,依次执行 redo log prepare,写binlog/发往备库(两个步骤并行),等待备库回复收到ack,redo

MySQL主备复制原理、实现及异常处理

复制概述 MySQL支持三种复制方式:基于行(Row)的复制.基于语句(Statement)的复制和混合类型(Mixed)的复制. 基于语句的复制早在3.23版本中就存在,而基于行的复制方式在5.1版本中才被加进来.这两种方式都是通过在主库上记录二进制日志.在备库重放日志的方式来实现异步的数据复制. 混合类型的复制:默认采用基于语句的复制,一旦发现基于语句的无法精确的复制时,就会采用基于行的复制. 复制通常不会增加主库的开销,主要是启用二进制日志带来的开销,但出于备份或及时从崩溃中恢复的目的,这

PostgreSQL PG主备流复制机制

PostgreSQL在9.0之后引入了主备流复制机制,通过流复制,备库不断的从主库同步相应的数据,并在备库apply每个WAL record,这里的流复制每次传输单位是WAL日志的record.而PostgreSQL9.0之前提供的方法是主库写完一个WAL日志文件后,才把WAL日志文件传送到备库,这样的方式导致主备延迟特别大.同时PostgreSQL9.0之后提供了Hot Standby,备库在应用WAL record的同时也能够提供只读服务,大大提升了用户体验. 主备总体结构 PG主备流复制的

java中redis主-主实现方案

问题的提出 redis(特指2.8.14及以下)replication仅支持主从复制.在实际生产环境中,这种单向主从复制,没有办法做高可用(当然,如果允许数据丢失的话,可以采用keepalived,采用其notify_master/notify_slave机制,强制实现主从的角色互换,这种方式对主从强行互换的过程中,如果存在未同步的数据,将会彻底丢失,是一种极其危险的方案,用于生产环境是不可取的). 所谓他山之石,可以攻玉.mysql提供成熟的主主复制,结合keepalived动态IP,可以做到

数据库内核月报 - 2015 / 10-PgSQL · 特性分析 · PG主备流复制机制

PostgreSQL在9.0之后引入了主备流复制机制,通过流复制,备库不断的从主库同步相应的数据,并在备库apply每个WAL record,这里的流复制每次传输单位是WAL日志的record.而PostgreSQL9.0之前提供的方法是主库写完一个WAL日志文件后,才把WAL日志文件传送到备库,这样的方式导致主备延迟特别大.同时PostgreSQL9.0之后提供了Hot Standby,备库在应用WAL record的同时也能够提供只读服务,大大提升了用户体验. 主备总体结构 PG主备流复制的