redis主从_redis主从复制 - CSDN
精华内容
参与话题
  • redis——redis主从复制

    2018-07-11 18:43:00
    为了分担读压力,Redis支持主从复制,Redis的主从结构可以采用一主多从或者级联结构,Redis主从复制可以根据是否是全量分为全量同步和增量同步。一、概念主从复制,是指将一台Redis服务器的数据,复制到其他的Redis...

    和MySQL主从复制的原因一样,Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了分担读压力,Redis支持主从复制,Redis的主从结构可以采用一主多从或者级联结构,Redis主从复制可以根据是否是全量分为全量同步和增量同步。


    一、概念

    主从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(master),后者称为从节点(slave);数据的复制是单向的,只能由主节点到从节点。默认情况下,每台Redis服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点。


    二、作用

    1.主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。

    2.当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。

    3.在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。

    4.高可用基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础。


    三、建立复制

    需要注意,主从复制的开启,完全是在从节点发起的;不需要我们在主节点做任何事情。
    从节点开启主从复制,有3种方式:
    (1)配置文件
    在从服务器的配置文件中加入:slaveof <masterip> <masterport>
    (2)启动命令
    redis-server启动命令后加入 --slaveof <masterip> <masterport>
    (3)客户端命令
    Redis服务器启动后,直接通过客户端执行命令:slaveof <masterip> <masterport>,则该Redis实例成为从节点。
    上述3种方式是等效的,下面以客户端命令的方式为例,看一下当执行了slaveof后,Redis主节点和从节点的变化。

    通过slaveof <masterip> <masterport>命令建立主从复制关系以后,可以通过slaveof no one断开。需要注意的是,从节点断开复制后,不会删除已有的数据,只是不再接受主节点新的数据变化。

    四、实现步骤

    建立连接

    一、保存主节点信息
    从节点服务器内部维护了两个字段,即masterhost和masterport字段,用于存储主节点的ip和port信息。
    需要注意的是,slaveof是异步命令,从节点完成主节点ip和port的保存后,向发送slaveof命令的客户端直接返回OK,实际的复制操作在这之后才开始进行。

    二、建立socket连接
    从节点每秒1次调用复制定时函数replicationCron(),如果发现了有主节点可以连接,便会根据主节点的ip和port,创建socket连接。如果连接成功,则:
    从节点:为该socket建立一个专门处理复制工作的文件事件处理器,负责后续的复制工作,如接收RDB文件、接收命令传播等。
    主节点:接收到从节点的socket连接后(即accept之后),为该socket创建相应的客户端状态,并将从节点看做是连接到主节点的一个客户端,后面的步骤会以从节点向主节点发送命令请求的形式来进行。

    三、发送ping命令
    从节点成为主节点的客户端之后,发送ping命令进行首次请求,目的是:检查socket连接是否可用,以及主节点当前是否能够处理请求。
    从节点发送ping命令后,可能出现3种情况:
    (1)返回pong:说明socket连接正常,且主节点当前可以处理请求,复制过程继续。
    (2)超时:一定时间后从节点仍未收到主节点的回复,说明socket连接不可用,则从节点断开socket连接,并重连。
    (3)返回pong以外的结果:如果主节点返回其他结果,如正在处理超时运行的脚本,说明主节点当前无法处理命令,则从节点断开socket连接,并重连。

    四、身份验证
    如果从节点中设置了masterauth选项,则从节点需要向主节点进行身份验证;没有设置该选项,则不需要验证。从节点进行身份验证是通过向主节点发送auth命令进行的,auth命令的参数即为配置文件中的masterauth的值。

    如果主节点设置密码的状态,与从节点masterauth的状态一致(一致是指都存在,且密码相同,或者都不存在),则身份验证通过,复制过程继续;如果不一致,则从节点断开socket连接,并重连。

    五、发送从节点端口信息

    身份验证之后,从节点会向主节点发送其监听的端口号(前述例子中为6380),主节点将该信息保存到该从节点对应的客户端的slave_listening_port字段中;该端口信息除了在主节点中执行info Replication时显示以外,没有其他作用。

    数据同步

    主从节点之间的连接建立以后,便可以开始进行数据同步,该阶段可以理解为从节点数据的初始化。具体执行的方式是:从节点向主节点发送psync命令(Redis2.8以前是sync命令),开始同步。
    数据同步阶段是主从复制最核心的阶段,根据主从节点当前状态的不同,可以分为全量复制和部分复制,下面会有一章专门讲解这两种复制方式以及psync命令的执行过程,这里不再详述。

    需要注意的是,在数据同步阶段之前,从节点是主节点的客户端,主节点不是从节点的客户端;而到了这一阶段及以后,主从节点互为客户端。原因在于:在此之前,主节点只需要响应从节点的请求即可,不需要主动发请求,而在数据同步阶段和后面的命令传播阶段,主节点需要主动向从节点发送请求(如推送缓冲区中的写命令),才能完成复制。

    命令传播

    数据同步阶段完成后,主从节点进入命令传播阶段;在这个阶段主节点将自己执行的写命令发送给从节点,从节点接收命令并执行,从而保证主从节点数据的一致性。
    在命令传播阶段,除了发送写命令,主从节点还维持着心跳机制:PING和REPLCONF ACK。由于心跳机制的原理涉及部分复制,因此将在介绍了部分复制的相关内容后单独介绍该心跳机制。
    延迟与不一致
    需要注意的是,命令传播是异步的过程,即主节点发送写命令后并不会等待从节点的回复;因此实际上主从节点之间很难保持实时的一致性,延迟在所难免。数据不一致的程度,与主从节点之间的网络状况、主节点写命令的执行频率、以及主节点中的repl-disable-tcp-nodelay配置等有关。
    repl-disable-tcp-nodelay no:该配置作用于命令传播阶段,控制主节点是否禁止与从节点的TCP_NODELAY;默认no,即不禁止TCP_NODELAY。当设置为yes时,TCP会对包进行合并从而减少带宽,但是发送的频率会降低,从节点数据延迟增加,一致性变差;具体发送频率与Linux内核的配置有关,默认配置为40ms。当设置为no时,TCP会立马将主节点的数据发送给从节点,带宽增加但延迟变小。

    一般来说,只有当应用对Redis数据不一致的容忍度较高,且主从节点之间网络状况不好时,才会设置为yes;多数情况使用默认值no。


    五、缺陷

    主从复制虽然解决或缓解了数据冗余、故障恢复、读负载均衡等问题,但其缺陷仍很明显,如故障恢复无法自动化;写操作无法负载均衡;存储能力受到单机的限制。每次slaveof断开后,(无论是主动断开,还是网络故障),再连接master;都要master全部dump出来rdb,再aof,即同步的过程都要重新执行1遍。所以不要多台slaveof同时启动,否则master可能IO剧增。
    展开全文
  • 一般的文档,都把redis的集群方式分成三种:主从、哨兵、集群(这里的集群只是广义集群的一种)。但是这么分类很不严谨,哨兵模式,单独使用是没有意义的,哨兵的作用有两个: 监控:监控主节点和从节点是否正常...

    1 概述

      一般的文档,都把redis的集群方式分成三种:主从、哨兵、集群(这里的集群只是广义集群的一种)。但是这么分类很不严谨,哨兵模式,单独使用是没有意义的,哨兵的作用有两个:

    • 监控:监控主节点和从节点是否正常运行
    • 提醒:当被监控的某个Redis节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
    • 故障迁移:主数据库出现故障时自动将从数据库转换为主数据库

      说白了,哨兵就是一个打辅助的,本身并不提供数据存储功能,能独立使用的方式只有两种,主从模式和集群模式,所以我认为将redis分为两类比较合适:

    1. 主从集群配合哨兵使用
    2. 分布式(分区)集群

    2 主从集群

      主从集群,将数据库分为两中角色,一种是主数据库(master),另一种是从数据库(slave)。主数据库可以进行读写操作,从数据库只能有读操作(并不一定,只是推荐这么做,后续会说明)。当主数据库有数据写入,会将数据同步复制给从节点,一个主数据库可以同时拥有多个从数据库,而从数据库只能拥有一个主数据库。值得一提的是,从节点也可以有从节点,级联结构。
    图片来源:https://www.cnblogs.com/kevingrace/p/5685332.html
    配置
    在从节点的redis.conf配置文件中加入
    slaveof 主数据库ip 主数据库port
    先启动主节点,再启动从节点即可

    2.1 复制原理

      当从节点启动后,会向主数据库发送SYNC命令。同时主数据库收到SYNC命令后会开始在后台保存快照(即RDB持久化,在主从复制时,会无条件触发RDB),并将保存快照期间接收到的命令缓存起来,当快照完成后,redis会将快照文件和所有缓存命令发送给数据库。从数据库接收到快照文件和缓存命令后,会载入快照文件和执行命令,也就是说redis是通过RDB持久化文件和redis缓存命令来时间主从复制。一般在建立主从关系时,一次同步会进行复制初始化。
      以上过程为复制初始化,复制初始化结束后,主数据库每当受到写命令时,就会将命令同步给从数据库,保证主从数据一致性。
      这里需要提一句,在Redis2.6之前,每次主从数据库断开连接后,Redis需要重新执行复制初始化,在数据量大的情况下,非常低效。而在Redis2.8之后,在断线重连后,主数据库只需要将断线期间执行的命令传送给从数据库。
    在这里插入图片描述

    2.2 乐观复制

      Redis采用了乐观复制的策略,也就是在一定程度内容忍主从数据库的内容不一致。具体来说,Redis在主从复制的过程中,本身就是异步的,在主从数据库执行完客户端请求后会立即将结果返回给客户端,并异步的将命令同步给从数据库,但是这里并不会等待从数据库完全同步之后,再返回客户端。这一特性虽然保证了主从复制期间性能不受影响,但是也会产生一个数据不一致的时间窗口,如果在这个时间窗口期间网络突然断开连接,就会导致两者数据不一致。如果不在配置文件中添加其他策略,那就默认会采用这种方式,乐观二字也就体现在这里(是不是有点想当然的认为自己不会这么倒霉的停在这个空窗期)。
      当然了,上面这种方式并不是绝对的,只要牺牲一点性能,还是可以避免上述问题。在配置文件中:

    min-slaves-to-write 3
    min-slaves-max-lag 10

      前者表示当3个或者3个以上的从数据库同步主数据库时,主数据库才是可写的,否则会返回错误。
      后者表示允许从数据库最长失联时间(单位s),如果从数据库最后与主数据库保持联的时间小于这个时间,则认为还存活。

    2.3 增量复制

    增量复制是基于以下4点实现的:

    1. 主节点除了备份RDB文件之外还会维护者一个环形积压队列,以及环形队列的写索引和从节点同步的全局offset,环形队列用于存储最新的操作数据。
    2. 从数据库会存储主数据库的运行id,每个redis实例会拥有一个唯一的运行id,当实例重启后,就会自动生成一个新的id。
    3. 主节点在复制同步阶段,主数据库每将一个命令传递给从数据库时,都会将命令存放到积压队列,并记录当前积压队列中存放命令的偏移量。
    4. 从数据库接收到主数据库传来的命令时,会记录下偏移量。

      在2.8之后,主从复制不再发送SYNC命令,取而代之的是PSYNC,格式为:“PSYNC ID offset”。
      当从节点和主节点断开重连之后,会把从节点维护的offset,也就是上一次同步到哪里的这个值告诉主节点,同时会告诉主节点上次和当前从节点连接的主节点的runid,满足下面两个条件,Redis不会全量复制,也就是说,不满足以下条件还是会全量复制

    1.从节点传递的run id和master的run id一致。
    2.主节点在环形队列上可以找到对应offset的值。

    积压队列本质上是一个固定长度的循环队列,默认情况下积压队列的大小为1MB,可以通过配置文件:

    repl-backlog-size 1mb

    来设置,积压队列越大,允许主从数据库断线的时间就越长
    Redis同时也提供了当没有slave需要同步的时候,多久可以释放环形队列,默认一小时:

    repl-backlog-ttl 3600

    3 哨兵模式

    哨兵的作用就是健康redis节点的运行状态。

    1.监控主数据库和从数据库是否能够正常运行
    2.主数据库出现故障时自动将从数据库转换为主数据库。

    普通的主从模式,当主数据库崩溃时,需要手动切换从数据库成为主数据库:

    1. 在从数据库中使用SLAVE NO ONE命令将从数据库提升成主数据继续服务。

    2. 启动之前崩溃的主数据库,然后使用SLAVEOF命令将其设置成新的主数据库的从数据库,即可同步数据。

    注意: 当开启复制并且主数据库关闭持久化功能时,一定不能使用Suoervisor自动重启功能。当主数据库重启后,因为没有开启持久化功能,数据都被清空,从数据库也会同步清空,导致从数据库的持久化失去意义。

    手动重启和恢复都相对麻烦,这时候就需要哨兵登场了。
    哨兵是一个独立的进程:
    在这里插入图片描述
      哨兵本身也有单点故障的问题,所以在一个一主多从的Redis系统中,可以使用多个哨兵进行监控,哨兵不仅会监控主数据库和从数据库,哨兵之间也会相互监控。

    在这里插入图片描述

    3.1 哨兵实现原理

    哨兵在启动进程时,会读取配置文件的内容,通过如下的配置找出需要监控的主数据库:

    sentinel monitor master-name ip port quorum
    master-name是主数据库的名字
    ip和port 是当前主数据库地址和端口号
    quorum表示在执行故障恢复操作前需要多少哨兵节点同意。

      这里之所以只需要连接主节点,是因为通过主节点的info命令,获取从节点信息,从而和从节点也建立连接,同时也能通过主节点的info信息知道新增从节点的信息。

      一个哨兵节点可以监控多个主节点,但是并不提倡这么做,因为当哨兵节点崩溃时,同时有多个集群切换会发生故障。
    哨兵启动后,会与主数据库建立两条连接。

    1.订阅主数据库_sentinel_:hello频道以获取同样监控该数据库的哨兵节点信息
    2.定期向主数据库发送info命令,获取主数据库本身的信息。

    和主数据库建立连接后会定时执行以下三个操作:

    1. 每隔10s向主数据库和从数据库发送info命令
    2. 每隔2s向主数据里和从数据库的_sentinel_:hello频道发送自己的信息。
    3. 每隔1s向所有数据库节点和所有哨兵节点发送ping命令。

      第一条操作的作用是获取当前数据库信息,比如发现新增从节点时,会建立连接,并加入到监控列表中,当主从数据库的角色发生变化进行信息更新。

      第二条操作的作用是将自己的监控数据和哨兵分享,发送的内容为:
    <哨兵地址>,<哨兵端口>,<哨兵运行id>,<哨兵配置版本>,<主数据库名字>,<主数据库地址>,<主数据库端口>,<主数据库配置版本>,每个哨兵会订阅数据库的_sentinel_:hello频道,当其他哨兵收到消息后,会判断该哨兵是不是新的哨兵,如果是则将其加入哨兵列表,并建立连接。

      第三条操作的作用是监控节点是否存活。该时间间隔有down-after-millisecond实现,当该值小于1s时,哨兵会按照设定的值发送ping,当大于1s时,哨兵会间隔1s发送ping命令。

    3.2 主观下线和客观下线

      当超过down-after-millisecond时间后,如果节点未回复,则哨兵认为主观下线。主观下线表示当前哨兵认为该节点已经下面,如果该节点为主数据库,哨兵会进一步判断是够需要对其进行故障恢复,这时候就要发送SENTINEL is-master-down-by-addr命令询问其他哨兵节点是否认为该主节点是主观下线,当达到指定数量时,哨兵就会认为是客观下线,该数量由sentinel monitor master-name ip port quorum的quorum参数设定。
      当主节点客观下线时就需要进行主从切换,主从切换的步骤为:

    1. 选出领头哨兵
    2. 领头哨兵从在线的从数据库中,选择优先级最高的从数据库。优先级可以通过slave-priority选项设置。
    3. 如果优先级相同,则从复制的命令偏移量越大(即复同步数据越多,数据越新),越优先。
    4. 如果以上条件都一样,则选择run ID较小的从数据库。

      选择一个从数据库后,哨兵发送slave no one命令升级为主数据库,并发送slaveof命令将其他从节点的主数据库设置为新的主数据库。
      其中选择领头哨兵的过程使用了Raft算法,其具体思想如下:

    1. 发送主数据库客观下线的哨兵向每个哨兵命令,要求对方选择自己为领头。
    2. 如果没有选择过其他哨兵,则会同意请求
    3. 如果发现有超过半数,且超过quorum的哨兵同意自己的请求,则自己就是哨兵领头。

    这种算法在多个哨兵同时参选时,会出现没有任何节点当选的可能。此时,每个哨兵会等待一个随机时间重新参选,每个节点的随机时间不一定相同,进行下一轮选举,直到成功。

    展开全文
  • Redis主从同步配置(详细图解)

    万次阅读 2019-08-29 12:03:34
    说明:该篇博客是博主一字一码编写的,实属不易,请尊重原创,谢谢大家! 一丶主从概念 一个master可以拥有多个slave,一个slave又可以拥有多个slave,如此... master和slave都是一个redis实例(redis服务) 二...

    说明:该篇博客是博主一字一码编写的,实属不易,请尊重原创,谢谢大家!

    一丶主从概念

    • 一个master可以拥有多个slave,一个slave又可以拥有多个slave,如此下去,形成了强大的多级服务器集群架构
    • master用来写数据,slave用来读数据,经统计:网站的读写比率是10:1
    • 通过主从配置可以实现读写分离
    • master和slave都是一个redis实例(redis服务)

     二丶主从配置

    说明:搭建redis主服务和从服务可以在同一台电脑上搭建,也可以在不同电脑上搭建,博主这里使用一台电脑进行搭建

    1.配置主

    • step1 查看电脑中的ip地址

    • step2 编辑redis配置文件sudo vi /etc/redis/redis.conf,绑定本机IP地址,不要写127.0.0.1

    • step3 重启redis服务,查看redis服务,出现配置的IP地址以及默认端口号6379

    2.配置从

    • step1 复制etc/redis/redis.conf文件命名为slave.conf,用作于从服务配置文件,该配置文件名字随便起

    • step2 编辑slave.conf配置文件sudo vi slave.conf,需要配置三个地方,分别是绑定ip和端口号以及主从复制(类似于双机备份),因为博主这里使用的是同一台电脑,所以ip不用动,端口号不能与主服务的端口号一致博主这里改的6378,slaveof 配置主服务的ip(也就是本地ip)端口号为6379

    • step3 启动从服务,即redis启动配置文件为slave.conf

    3.查看主从关系

    • step1 执行redis-cli -h 192.168.4.63 info Replication 命令查看主服务角色信息,没写端口-p 6379因为不写默认为此端口

    • step2 redis-cli -h 192.168.4.63 -p 6378 info Replication 命令查看从服务角色信息

    三丶数据操作

    1.连接到主服务(master),在主上设置键和值

    2.连接到从服务(slave),在从上获取主上设置的键的值

    3.在从服务上(slave)设置键值,提示该服务只有读的权限,主从配置成功

    展开全文
  • redis主从配置(一主多从)

    千次阅读 2020-03-28 22:01:22
    主从简介 ...redis主从同步是异步进行的,这意味着主从同步不会影响主逻辑,也不会降低redis的处理性能。 主从架构中,可以考虑关闭主服务器的数据持久化功能,只让从服务器进行持久化,这样可以提...

    主从简介

    redis安装

    1、主从 – 用法

    像MySQL一样,redis是支持主从同步的,而且也支持一主多从以及多级从结构。
    主从结构,一是为了纯粹的冗余备份,二是为了提升读性能,比如很消耗性能的SORT就可以由从服务器来承担。
    redis的主从同步是异步进行的,这意味着主从同步不会影响主逻辑,也不会降低redis的处理性能。
    主从架构中,可以考虑关闭主服务器的数据持久化功能,只让从服务器进行持久化,这样可以提高主服务器的处理性能。

    2、主从同步原理
    主从 – 同步原理
    从服务器会向主服务器发出SYNC指令,当主服务器接到此命令后,就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作,也就是将主服务器的数据写入RDB文件中。在数据持久化期间,主服务器将执行的写指令都缓存在内存中。
    在BGSAVE指令执行完成后,主服务器会将持久化好的RDB文件发送给从服务器,从服务器接到此文件后会将其存储到磁盘上,然后再将其读取到内存中。这个动作完成后,主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。
    
    另外,要说的一点是,即使有多个从服务器同时发来SYNC指令,主服务器也只会执行一次BGSAVE,然后把持久化好的RDB文件发给多个从服务器。
    
    而在2.8版本之后,redis支持了效率更高的增量同步策略,这大大降低了连接断开的恢复成本。主服务器会在内存中维护一个缓冲区,缓冲区中存储着将要发给从服务器的内容。从服务器在与主服务器出现网络瞬断之后,从服务器会尝试再次与主服务器连接,一旦连接成功,主服务器就会向从服务器发送增量内容。
    
    增量同步功能,需要服务器端支持全新的PSYNC指令。这个指令,只有在redis-2.8之后才具有。
    
    BGSAVE指令:
    在后台异步(Asynchronously)保存当前数据库的数据到磁盘。
    BGSAVE 命令执行之后立即返回 OK ,然后 Redis fork 出一个新子进程,原来的 Redis 进程(父进程)继续处理客户端请求,而子进程则负责将数据保存到磁盘,然后退出。
    

    3、部署三台机器redis—主从同步

    redis-master----192.168.246.202
    redis-slave-1-----192.168.246.203
    redis-slave-2-----192.168.246.204
    1.首先三台服务器将redis部署完成。
    2.编辑master的redis配置文件:
    [root@redis-master ~]# cd /data/application/redis/
    [root@redis-master redis]# vim redis.conf
    

    在这里插入图片描述
    在这里插入图片描述
    关闭protected-mode模式,此时外部网络可以直接访问

    开启protected-mode保护模式,需配置bind ip或者设置访问密码

    3.启动主节点redis服务
    [root@redis-master src]# cd /data/application/redis/src
    [root@redis-master src]# ./redis-server ../redis.conf &   会加载此文件中的配置信息
    
    4.修改slave1的配置文件:
    [root@redis-slave-1 ~]# cd /data/application/redis/
    [root@redis-slave-1 redis]# vim redis.conf      ---修改如下:
    

    在这里插入图片描述

    5.启动从节点1的redis服务
    [root@redis-slave-1 ~]# cd /data/application/redis/src/
    [root@redis-slave-1 src]# ./redis-server ../redis.conf &
    
    6.修改slave2的配置文件
    [root@redis-slave-2 ~]# cd /data/application/redis/
    [root@redis-slave-2 redis]# vim redis.conf       ---修改和从节点1 一样
    
    7.启动从节点2的redis服务
    [root@ansible-web2 ~]# cd /data/application/redis/src/
    [root@ansible-web2 src]# ./redis-server ../redis.conf &
    
    9.测试主从
    1.在master上面执行
    [root@redis-master redis]# cd src/
    [root@redis-master src]# ./redis-cli 
    127.0.0.1:6379> ping
    PONG
    127.0.0.1:6379> set name jack
    OK
    127.0.0.1:6379> get name
    "jack"
    127.0.0.1:6379>
    
    2.分别在slave-1和slave-2上面执行:
    [root@redis-slave-1 redis]# cd src/
    [root@redis-slave-1 src]# ./redis-cli 
    127.0.0.1:6379> ping
    PONG
    127.0.0.1:6379> get name
    "jack"
    127.0.0.1:6379>
    [root@redis-slave-2 src]# ./redis-cli 
    127.0.0.1:6379> ping
    PONG
    127.0.0.1:6379> get name
    "jack"
    127.0.0.1:6379>
    查看复制状态
    master执行:
    127.0.0.1:6379> info replication
    # Replication
    role:master
    connected_slaves:2
    slave0:ip=192.168.246.203,port=6379,state=online,offset=490,lag=0
    slave1:ip=192.168.246.204,port=6379,state=online,offset=490,lag=1
    ==============================================================================
    slave上面执行:
    127.0.0.1:6379> info replication
    # Replication
    role:slave
    master_host:192.168.246.202
    master_port:6379
    master_link_status:up
    

    注意:从服务器一般默认禁止写入操作:slave-read-only yes

    展开全文
  • Redis主从同步,及两种高可用方式

    万次阅读 多人点赞 2018-10-15 19:22:03
    一、Redis 介绍 Redis是一个开源的使用ANSI C语言编写、...区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,并且在此基础上实现了master-slave(主从)同步。 Redis 是一个高性能的k...
  • Redis主从模式

    千次阅读 2019-01-14 14:16:25
    Redis主从模式  目录: 1、Redis主从模式简单介绍: 2、Redis主从模式的部署安装: 3、测试从服务器的只读: 4、测试主节点宕机故障恢复: 1、Redis主从模式简单介绍: 图1.1 主从模式架构 主从模式: ...
  • Redis主从同步+自动切换

    万次阅读 2018-07-10 15:54:09
    一构建:1.两台centos7服务器: 192.168.1.100和192.168.1.1152. 安装必须的软件包:yum install gcc gcc-c++ kernel-devel automake autoconf libtool make wget tcl ... 下载redis源码包并安装:wget http://...
  • Redis主从同步原理-SYNC

    千次阅读 2019-05-18 16:13:19
    和MySQL主从复制的原因一样,Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了分担读压力,Redis支持主从复制,Redis的主从结构... Redis主从复制可以根据是否是全量分为全量同步和增量...
  • Redis配置主从复制,实现读写分离

    千次阅读 2018-09-04 22:31:45
    由于redis的高性能,在应用中对其依赖很高,有时候一台redis服务器性能不够,需要配置redis集群。最简单的就是一台用来读,一台用来写。一般对读的需求比较大,所以可以配置一主(读)多从(写)。 本次是在本地...
  • Redis实现主从复制(Master&Slave)

    万次阅读 2017-11-15 15:11:03
    前面给大家讲解了单机版redis的基本操作,现在继续给大家讲解一下Redis的进阶部分,主从复制和读写分离。 一、Master&Slave是什么?  也就是我们所说的主从复制,主机数据更新后根据配置和策略,自动同步到备机 的...
  • Redis主从复制

    千次阅读 2019-02-20 10:03:31
    Redis主从复制前言 通过持久化功能,Redis保证了即使在服务器重启的情况下也不会丢失(或少量丢失)数据,但是由于数据是存储在一台服务器上的,如果这台服务器出现故障,比如硬盘坏了,也会导致数据丢失。 为了...
  •  ./redis-cli -h 192.168.203.141 -p 8001 -c 2.然后在输入 cluster nodes 命令,然后就会显示出各个节点的主从信息了 转载于:https://www.cnblogs.com/fengzifengfeng/p/10421431.html...
  • redis主从模式之前提到过,这里我们使用redis来实现主从模式。 首先在VMware虚拟机中的Linux中打开两个终端,一个是用户jack,一个是newuser: 然后我们jack作为主机,redis服务运行在6379端口,我们设置newuser...
  • redis主从复制失败的坑

    千次阅读 2017-09-07 00:19:22
    刚刚学习redis,整个主从复制试试,结果从机改完配置文件内的slaveof之后启动从机服务不能成功。 一直提示writing to master unknown error。 查看客户端的info发现master_link_status 是down的状态。 没...
  • 首先你需要连接上redis [root@localhost src]# ./redis-cli -p 6384 --第一步从客户端命令工具连接redis 127.0.0.1:6384> auth 123456 --输入登录密码,登录  [root@localhost src]#info replication --...
  • Redis主从数据库同步问题

    千次阅读 2019-07-04 10:15:55
    Redis主从同步原理-SYNC 和MySQL主从复制的原因一样,Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了分担读压力,Redis支持主从复制,Redis的主从结构可以采用一主多从或者级联结构,下图...
  • redis主从同步原理(浅谈)

    千次阅读 多人点赞 2019-03-07 16:01:20
    主从模式可以保证redis的高可用,那么redis是怎么保证主从服务器的数据一致性的,接下来我们浅谈下redis主(master)从(slave)同步的原理。 2.初次全量同步 当一个redis服务器初次向主服务器发送salveof命令时,redis...
  • redis设置密码和redis主从复制

    千次阅读 2017-12-23 19:05:43
    redis设置密码和redis主从复制 一、redis设置密码 1、Redis实用特性  安全性 主从复制(侦听器)事务处理 持久化机制 发布订阅消息  2、安全性:设置客户端连接后进行任何其他指定前需要使用的密码 打开...
  • Redis主从复制的功能非常强大,它有以下好处:1.避免Redis单点故障 2.构建读写分离架构,满足读多写少的应用场景1.主从架构1.1 Redis主从架构拓扑图结构 1.2 主从结构搭建Redis集群不用安装多个Redis,只需复制多个...
  • 前提:现在有主从结构,主库没有配置持久化,从库配置AOF。(主库用来备份和写服务,从库用来提供读服务) 场景:哪一天主库突然宕了,怎么办? 非常危险的动作:重新启动主库。 要知道这样一来,最坏情况数据...
1 2 3 4 5 ... 20
收藏数 65,958
精华内容 26,383
关键字:

redis主从