精华内容
下载资源
问答
  • redis同步日志

    千次阅读 2017-03-16 13:14:43
    1.如果master不设置密码,那么... #slaveof ip 端口 slaveof 221.224.85.186 6379  ...配置好我们看下redis日志 看是否同步成功 5014:S 25 Jan 10:53:53.667 * Connecting to MASTER 221.224.85.186:6379 50

    1.如果master不设置密码,那么直接在slave服务器配置slaveof即可 配置如下

    #slaveof ip 端口
    slaveof  221.224.85.186 6379 

    配置好我们看下redis的日志 看是否同步成功

    复制代码
    5014:S 25 Jan 10:53:53.667 * Connecting to MASTER 221.224.85.186:6379
    5014:S 25 Jan 10:53:53.667 * MASTER <-> SLAVE sync started
    5014:S 25 Jan 10:53:53.700 * Non blocking connect for SYNC fired the event.
    5014:S 25 Jan 10:53:53.734 * Master replied to PING, replication can continue...
    5014:S 25 Jan 10:53:53.832 * Partial resynchronization not possible (no cached master)
    5014:S 25 Jan 10:53:53.867 * Full resync from master: 4d6221e370675f397c396c9222b1b60bfcea1efb:1
    5014:S 25 Jan 10:53:53.985 * MASTER <-> SLAVE sync: receiving 844 bytes from master
    5014:S 25 Jan 10:53:53.985 * MASTER <-> SLAVE sync: Flushing old data
    5014:S 25 Jan 10:53:53.985 * MASTER <-> SLAVE sync: Loading DB in memory
    5014:S 25 Jan 10:53:53.985 * MASTER <-> SLAVE sync: Finished with success
    复制代码
    5014:S 25 Jan 10:53:53.667 * Connecting to MASTER 221.224.85.186:6379
    这句是从上面slave服务器日志里面获取的,我们可以看到连接的master的服务器的ip是221.224.85.186

    MASTER <-> SLAVE sync: Finished with success
    看到输出的语句是success表示同步成功.

    2.master设置密码的情况下同步数据,其实很简单,我们只要让slave能连上master就可以了,我们在slave的配置文件中加一句话即可。
    masterauth 123456

     OK。

     不然可能会出现一下错误

     

    复制代码
    4939:S 25 Jan 09:53:20.450 # MASTER aborted replication with an error: NOAUTH Authentication required.
    4939:S 25 Jan 09:53:21.291 * Connecting to MASTER 120.27.137.142:6379
    4939:S 25 Jan 09:53:21.292 * MASTER <-> SLAVE sync started
    4939:S 25 Jan 09:53:21.317 * Non blocking connect for SYNC fired the event.
    4939:S 25 Jan 09:53:21.342 * Master replied to PING, replication can continue...
    4939:S 25 Jan 09:53:21.368 * (Non critical) Master does not understand REPLCONF listening-port: -NOAUTH Authentication required.
    4939:S 25 Jan 09:53:21.393 * (Non critical) Master does not understand REPLCONF capa: -NOAUTH Authentication required.
    4939:S 25 Jan 09:53:21.393 * Partial resynchronization not possible (no cached master)
    4939:S 25 Jan 09:53:21.419 # Unexpected reply to PSYNC from master: -NOAUTH Authentication required.
    4939:S 25 Jan 09:53:21.419 * Retrying with SYNC...
    4939:S 25 Jan 09:53:21.444 # MASTER aborted replication with an error: NOAUTH Authentication required.
    复制代码
    展开全文
  • Redis数据同步

    2020-09-10 10:26:23
    数据尽量少丢失,AOF(Append Only File)日志和RDB(Redis DataBase)快照机制保证这一点。 服务尽量少中断,Redis的做法是增加副本冗余量。 Redis 提供了主从库模式,以保证数据副本的一致,主从库之间采用的是...

    高可靠性

    • 数据尽量少丢失,AOF(Append Only File)日志和RDB(Redis DataBase)快照机制保证这一点。
    • 服务尽量少中断,Redis的做法是增加副本冗余量
    • Redis 提供了主从库模式,以保证数据副本的一致,主从库之间采用的是读写分离的方式。

    主从库间如何进行第一次同步

    • 启动多个 Redis 实例的时候,它们相互之间就可以通过 replicaof(Redis 5.0 之前使用 slaveof)命令形成主库和从库的关系,之后会按照三个阶段完成数据的第一次同步。
    • 例如,现在有实例 1(ip:172.16.19.3)和实例 2(ip:172.16.19.5),我们在实例 2 上执行replicaof 172.16.19.3 6379,实例 2 就变成了实例 1 的从库,并从实例 1 上复制数据
      在这里插入图片描述
    • 第一阶段是主从库间建立连接、协商同步的过程,主要是为全量复制做准备。在这一步,从库和主库建立起连接,并告诉主库即将进行同步,主库确认回复后,主从库间就可以开始同步了。
    • 具体来说,从库给主库发送 psync命令,表示要进行数据同步,主库根据这个命令的参数来启动复制。psync 命令包含了主库的 runID 和复制进度 offset 两个参数。
      • runID,是每个 Redis 实例启动时都会自动生成的一个随机 ID,用来唯一标记这个实例。当从库和主库第一次复制时,因为不知道主库的 runID,所以将 runID 设为“?”。
      • offset,此时设为 -1,表示第一次复制。
    • 主库收到 psync 命令后,会用 FULLRESYNC 响应命令带上两个参数:主库 runID 和主库目前的复制进度 offset,返回给从库。从库收到响应后,会记录下这两个参数。这里有个地方需要注意,FULLRESYNC 响应表示第一次复制采用的全量复制,也就是说,主库会把当前所有的数据都复制给从库
    • 在第二阶段,主库将所有数据同步给从库。从库收到数据后,在本地完成数据加载。这个过程依赖于内存快照生成的 RDB 文件。具体来说,主库执行 bgsave 命令,生成 RDB 文件,接着将文件发给从库。从库接收到 RDB 文件后,会先清空当前数据库,然后加载 RDB 文件。这是因为从库在通过 replicaof 命令开始和主库同步前,可能保存了其他数据。为了避免之前数据的影响,从库需要先把当前数据库清空。
    • 在主库将数据同步给从库的过程中,主库不会被阻塞,仍然可以正常接收请求。否则,Redis 的服务就被中断了。但是,这些请求中的写操作并没有记录到刚刚生成的 RDB 文件中。为了保证主从库的数据一致性,主库会在内存中用专门的 replication buffer,记录 RDB 文件生成后收到的所有写操作
    • 最后,也就是第三个阶段,主库会把第二阶段执行过程中新收到的写命令,再发送给从库。具体的操作是,当主库完成 RDB 文件发送后,就会把此时 replication buffer 中的修改操作发给从库,从库再重新执行这些操作。这样一来,主从库就实现同步了。

    主从级联模式分担全量复制时的主库压力

    • 通过“主 - 从 - 从”模式将主库生成 RDB 和传输 RDB 的压力,以级联的方式分散到从库上。
    • 在部署主从集群的时候,可以手动选择一个从库(比如选择内存资源配置较高的从库),用于级联其他的从库。然后,我们可以再选择一些从库(例如三分之一的从库),在这些从库上执行如下命令,让它们和刚才所选的从库,建立起主从关系。
    • 在这里插入图片描述
    • 一旦主从库完成了全量复制,它们之间就会一直维护一个网络连接,主库会通过这个连接将后续陆续收到的命令操作再同步给从库,这个过程也称为基于长连接的命令传播,可以避免频繁建立连接的开销。

    主从库间网络断了怎么办?

    • 在 Redis 2.8 之前,如果主从库在命令传播时出现了网络闪断,那么,从库就会和主库重新进行一次全量复制,开销非常大。
    • 从 Redis 2.8 开始,网络断了之后,主从库会采用增量复制的方式继续同步。只会把断连期间主库收到的命令,同步给从库。
    • repl_backlog_buffer 是一个环形缓冲区,主库会记录自己写到的位置,从库则会记录自己已经读到的位置。
    • 刚开始的时候,主库和从库的写读位置在一起,这算是它们的起始位置。随着主库不断接收新的写操作,它在缓冲区中的写位置会逐步偏离起始位置,我们通常用偏移量来衡量这个偏移距离的大小,对主库来说,对应的偏移量就是 master_repl_offset。主库接收的新写操作越多,这个值就会越大。同样,从库在复制完写操作命令后,它在缓冲区中的读位置也开始逐步偏移刚才的起始位置,此时,从库已复制的偏移量slave_repl_offset 也在不断增加。正常情况下,这两个偏移量基本相等。
    • 主从库的连接恢复之后,从库首先会给主库发送 psync 命令,并把自己当前的 slave_repl_offset 发给主库,主库会判断自己的 master_repl_offset 和 slave_repl_offset 之间的差距。
    • 若主库在断连期间收到新的写操作命令,则master_repl_offset 会大于 slave_repl_offset。此时,主库只用把 master_repl_offset 和 slave_repl_offset 之间的命令操作同步给从库就行。
    • 因为 repl_backlog_buffer 是一个环形缓冲区,所以在缓冲区写满后,主库会继续写入,此时,就会覆盖掉之前写入的操作。如果从库的读取速度比较慢,就有可能导致从库还未读取的操作被主库新写的操作覆盖了,这会导致主从库间的数据不一致
    • 可以调整 repl_backlog_size 这个参数。这个参数和所需的缓冲空间大小有关。缓冲空间的计算公式是:缓冲空间大小 = 主库写入命令速度 * 操作大小 - 主从库间网络传输命令速度 * 操作大小
    • 在实际应用中,考虑到可能存在一些突发的请求压力,我们通常需要把这个缓冲空间扩大一倍,即 repl_backlog_size = 缓冲空间大小 * 2,这也就是 repl_backlog_size 的最终值。
    展开全文
  • redis主从同步

    2020-01-05 19:45:28
    最近没事又在折腾redis,做主从的时候发现出了点小问题,一直报被拒绝 从:slaveof host port 排查顺序: *.默认关闭防火墙 1.先看日志,返回如下: (Non critical) Master does not understand REPLCONF listening-...

    最近没事又在折腾redis,做主从的时候发现出了点小问题,一直报被拒绝

    从:slaveof host port

    排查顺序:
    *.默认关闭防火墙
    1.先看日志,返回如下:

    (Non critical) Master does not understand REPLCONF listening-port: -NOAUTH Au
    thentication required.
    (Non critical) Master does not understand REPLCONF capa: -NOAUTH Authenticati
    on required.
    

    连接被拒绝,这时我才想起来主从都有密码,需要在从服务器配置信息上加一条:

    vim /etc/redis.conf
    masterauth 123456     #123456是我的密码
    

    然后还是发现有问题
    查了半天也没找到原因,最后折腾了半天后得出了如下结论:
    在从服务为其配置完主服务器密码后,需要重启服务,再执行一遍slaveof host port
    同步成功

    :
    Replica 192.168.0.102:6379 asks for synchronization
    Starting BGSAVE for SYNC with target: disk
    Background saving started by pid 56694
    DB saved on disk
    RDB: 0 MB of memory used by copy-on-write
    Background saving terminated with success
    Synchronization with replica 192.168.0.102:6379 succeeded
    
    从:
    MASTER <-> REPLICA sync started
    Non blocking connect for SYNC fired the event.
    Master replied to PING, replication can continue...
    Trying a partial resynchronization (request 810c3cad9a877c73d1e4e1d6a181e4281
    Full resync from master: 5d13cb2252f0e2a3ac6ad408b35cfa91b9884b99:0
    Discarding previously cached master state.
    MASTER <-> REPLICA sync: receiving 175 bytes from master
    MASTER <-> REPLICA sync: Flushing old data
    MASTER <-> REPLICA sync: Loading DB in memory
    MASTER <-> REPLICA sync: Finished with success
    

    主从流程:
    1.从库发起同步
    2.主库收到请求后执行basave保存当前内存中的数据到硬盘
    3.主库将持久化的数据发送给从库的数据目录
    4.从库收到主库的持久化数据之后,先清空自己当前内存中的数据
    5.从库将主库发送过来的持久化文件加载到自己的内存

    局限性:
    1.执行主从复制前,将数据各备份一份
    2.建议将主从复制写入到配置文件
    3.在业务低峰期做主从复制
    4.拷贝数据时后会占用带宽
    5.主从不能完成自动切换,需要人工介入

    展开全文
  • 为了分担读压力,Redis支持主从复制,Redis的主从结构可以采用一主多从或者级联结构,Redis主从复制可以根据是否是全量分为全量同步和增量同步。下图为级联结构。 全量同步 Redis全量复制一般发生在Slave初始化...

    Redis主从复制原理总结

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

    全量同步


    Redis全量复制一般发生在Slave初始化阶段,这时Slave需要将Master上的所有数据都复制一份。具体步骤如下: 
    -  从服务器连接主服务器,发送SYNC命令; 
    -  主服务器接收到SYNC命名后,开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令; 
    -  主服务器BGSAVE执行完后,向所有从服务器发送快照文件,并在发送期间继续记录被执行的写命令; 
    -  从服务器收到快照文件后丢弃所有旧数据,载入收到的快照; 
    -  主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令; 
    -  从服务器完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令;

    完成上面几个步骤后就完成了从服务器数据初始化的所有操作,从服务器此时可以接收来自用户的读请求。

    增量同步


    Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。 
    增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令,从服务器接收并执行收到的写命令。
     
     

    Redis主从同步策略


    主从刚刚连接的时候,进行全量同步;全同步结束后,进行增量同步。当然,如果有需要,slave 在任何时候都可以发起全量同步。redis 策略是,无论如何,首先会尝试进行增量同步,如不成功,要求从机进行全量同步。
     
    注意点
    如果多个Slave断线了,需要重启的时候,因为只要Slave启动,就会发送sync请求和主机全量同步,当多个同时出现的时候,可能会导致Master IO剧增宕机。

    Redis主从复制的配置十分简单,它可以使从服务器是主服务器的完全拷贝。需要清除Redis主从复制的几点重要内容:

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    1)Redis使用异步复制。但从Redis 2.8开始,从服务器会周期性的应答从复制流中处理的数据量。

    2)一个主服务器可以有多个从服务器。

    3)从服务器也可以接受其他从服务器的连接。除了多个从服务器连接到一个主服务器之外,多个从服务器也可以连接到一个从服务器上,形成一个

       图状结构。

    4)Redis主从复制不阻塞主服务器端。也就是说当若干个从服务器在进行初始同步时,主服务器仍然可以处理请求。

    5)主从复制也不阻塞从服务器端。当从服务器进行初始同步时,它使用旧版本的数据来应对查询请求,假设你在redis.conf配置文件是这么配置的。

       否则的话,你可以配置当复制流关闭时让从服务器给客户端返回一个错误。但是,当初始同步完成后,需要删除旧的数据集和加载新的数据集,在

       这个短暂的时间内,从服务器会阻塞连接进来的请求。

    6)主从复制可以用来增强扩展性,使用多个从服务器来处理只读的请求(比如,繁重的排序操作可以放到从服务器去做),也可以简单的用来做数据冗余。

    7)使用主从复制可以为主服务器免除把数据写入磁盘的消耗:在主服务器的redis.conf文件中配置“避免保存”(注释掉所有“保存“命令),然后连接一个配

       置为“进行保存”的从服务器即可。但是这个配置要确保主服务器不会自动重启(要获得更多信息请阅读下一段)

    主从复制的一些特点:

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    1)采用异步复制;

    2)一个主redis可以含有多个从redis;

    3)每个从redis可以接收来自其他从redis服务器的连接;

    4)主从复制对于主redis服务器来说是非阻塞的,这意味着当从服务器在进行主从复制同步过程中,主redis仍然可以处理外界的访问请求;

    5)主从复制对于从redis服务器来说也是非阻塞的,这意味着,即使从redis在进行主从复制过程中也可以接受外界的查询请求,只不过这时候从redis返回的是以前老的数据,

       如果你不想这样,那么在启动redis时,可以在配置文件中进行设置,那么从redis在复制同步过程中来自外界的查询请求都会返回错误给客户端;(虽然说主从复制过程中

       对于从redis是非阻塞的,但是当从redis从主redis同步过来最新的数据后还需要将新数据加载到内存中,在加载到内存的过程中是阻塞的,在这段时间内的请求将会被阻,

       但是即使对于大数据集,加载到内存的时间也是比较多的);

    6)主从复制提高了redis服务的扩展性,避免单个redis服务器的读写访问压力过大的问题,同时也可以给为数据备份及冗余提供一种解决方案;

    7)为了编码主redis服务器写磁盘压力带来的开销,可以配置让主redis不在将数据持久化到磁盘,而是通过连接让一个配置的从redis服务器及时的将相关数据持久化到磁盘,

       不过这样会存在一个问题,就是主redis服务器一旦重启,因为主redis服务器数据为空,这时候通过主从同步可能导致从redis服务器上的数据也被清空;

    Redis大概主从同步是怎么实现的?

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    全量同步:

    master服务器会开启一个后台进程用于将redis中的数据生成一个rdb文件,与此同时,服务器会缓存所有接收到的来自客户端的写命令(包含增、删、改),当后台保存进程

    处理完毕后,会将该rdb文件传递给slave服务器,而slave服务器会将rdb文件保存在磁盘并通过读取该文件将数据加载到内存,在此之后master服务器会将在此期间缓存的

    命令通过redis传输协议发送给slave服务器,然后slave服务器将这些命令依次作用于自己本地的数据集上最终达到数据的一致性。

     

    部分同步:

    从redis 2.8版本以前,并不支持部分同步,当主从服务器之间的连接断掉之后,master服务器和slave服务器之间都是进行全量数据同步,但是从redis 2.8开

    始,即使主从连接中途断掉,也不需要进行全量同步,因为从这个版本开始融入了部分同步的概念。部分同步的实现依赖于在master服务器内存中给每个slave服务器维护了

    一份同步日志和同步标识,每个slave服务器在跟master服务器进行同步时都会携带自己的同步标识和上次同步的最后位置。当主从连接断掉之后,slave服务器隔断时间

    (默认1s)主动尝试和master服务器进行连接,如果从服务器携带的偏移量标识还在master服务器上的同步备份日志中,那么就从slave发送的偏移量开始继续上次的同步

    操作,如果slave发送的偏移量已经不再master的同步备份日志中(可能由于主从之间断掉的时间比较长或者在断掉的短暂时间内master服务器接收到大量的写操作),则

    必须进行一次全量更新。在部分同步过程中,master会将本地记录的同步备份日志中记录的指令依次发送给slave服务器从而达到数据一致。

    主从同步中需要注意几个问题

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    1)在上面的全量同步过程中,master会将数据保存在rdb文件中然后发送给slave服务器,但是如果master上的磁盘空间有效怎么办呢?那么此时全部同步对于master来说

    将是一份十分有压力的操作了。此时可以通过无盘复制来达到目的,由master直接开启一个socket将rdb文件发送给slave服务器。(无盘复制一般应用在磁盘空间有限但是网

    络状态良好的情况下)

     

    2)主从复制结构,一般slave服务器不能进行写操作,但是这不是死的,之所以这样是为了更容易的保证主和各个从之间数据的一致性,如果slave服务器上数据进行了修改,

    那么要保证所有主从服务器都能一致,可能在结构上和处理逻辑上更为负责。不过你也可以通过配置文件让从服务器支持写操作。(不过所带来的影响还得自己承担哦。。。)

     

    3)主从服务器之间会定期进行通话,但是如果master上设置了密码,那么如果不给slave设置密码就会导致slave不能跟master进行任何操作,所以如果你的master服务器

    上有密码,那么也给slave相应的设置一下密码吧(通过设置配置文件中的masterauth);

     

    4)关于slave服务器上过期键的处理,由master服务器负责键的过期删除处理,然后将相关删除命令已数据同步的方式同步给slave服务器,slave服务器根据删除命令删除

    本地的key。

    当主服务器不进行持久化时复制的安全性

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    在进行主从复制设置时,强烈建议在主服务器上开启持久化,当不能这么做时,比如考虑到延迟的问题,应该将实例配置为避免自动重启。

     

    为什么不持久化的主服务器自动重启非常危险呢?

    为了更好的理解这个问题,看下面这个失败的例子,其中主服务器和从服务器中数据库都被删除了。

     

    设置节点A为主服务器,关闭持久化,节点B和C从节点A复制数据。

    这时出现了一个崩溃,但Redis具有自动重启系统,重启了进程,因为关闭了持久化,节点重启后只有一个空的数据集。

    节点B和C从节点A进行复制,现在节点A是空的,所以节点B和C上的复制数据也会被删除。

    当在高可用系统中使用Redis Sentinel,关闭了主服务器的持久化,并且允许自动重启,这种情况是很危险的。

    比如主服务器可能在很短的时间就完成了重启,以至于Sentinel都无法检测到这次失败,那么上面说的这种失败的情况就发生了。

     

    如果数据比较重要,并且在使用主从复制时关闭了主服务器持久化功能的场景中,都应该禁止实例自动重启。

    Redis主从复制是如何工作的

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    如果设置了一个从服务器,在连接时它发送了一个SYNC命令,不管它是第一次连接还是再次连接都没有关系。

     

    然后主服务器开始后台存储,并且开始缓存新连接进来的修改数据的命令。当后台存储完成后,主服务器把数据文件发送到从服务器,

    从服务器将其保存在磁盘上,然后加载到内存中。然后主服务器把刚才缓存的命令发送到从服务器。这是作为命令流来完成的,并且

    和Redis协议本身格式相同。

     

    你可以通过telnet自己尝试一下。在Redis服务器工作时连接到Redis端口,发送SYNC命令,会看到一个批量的传输,并且主服务器接收

    的每一个命令都会通过telnet会话重新发送一遍。

     

    当主从服务器之间的连接由于某些原因断开时,从服务器可以自动进行重连接。当有多个从服务器同时请求同步时,主服务器只进行一个后台存储。

     

    当连接断开又重新连上之后,一般都会进行一个完整的重新同步,但是从Redis2.8开始,只重新同步一部分也可以。

    部分重新同步

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    从Redis 2.8开始,如果遭遇连接断开,重新连接之后可以从中断处继续进行复制,而不必重新同步。

     

    它的工作原理是这样:

    主服务器端为复制流维护一个内存缓冲区(in-memory backlog)。主从服务器都维护一个复制偏移量(replication offset)和master run id 

    当连接断开时,从服务器会重新连接上主服务器,然后请求继续复制,假如主从服务器的两个master run id相同,并且指定的偏移量在内存缓冲

    区中还有效,复制就会从上次中断的点开始继续。如果其中一个条件不满足,就会进行完全重新同步(在2.8版本之前就是直接进行完全重新同步)。

    因为主运行id不保存在磁盘中,如果从服务器重启了的话就只能进行完全同步了。

     

    部分重新同步这个新特性内部使用PSYNC命令,旧的实现中使用SYNC命令。Redis2.8版本可以检测出它所连接的服务器是否支持PSYNC命令,不支持的

    话使用SYNC命令。

    无磁盘复制

    1

    2

    3

    4

    通常来讲,一个完全重新同步需要在磁盘上创建一个RDB文件,然后加载这个文件以便为从服务器发送数据。

     

    如果使用比较低速的磁盘,这种操作会给主服务器带来较大的压力。Redis从2.8.18版本开始尝试支持无磁盘的复制。

    使用这种设置时,子进程直接将RDB通过网络发送给从服务器,不使用磁盘作为中间存储。

    配置

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    主从复制的配置十分简单:把下面这行加入到从服务器的配置文件中即可。

    slaveof 192.168.1.1 6379

     

    当然你需要把其中的192.168.1.1 6379替换为你自己的主服务器IP(或者主机名hostname)和端口。另外你可以调用SLAVEOF命令,

    主服务器就会开始与从服务器同步。

     

    关于部分重新同步,还有一些针对复制内存缓冲区的优化参数。查看Redis介质中的Redis.conf示例获得更多信息。

     

    使用repl-diskless-sync配置参数来启动无磁盘复制。使用repl-diskless-sync-delay 参数来配置传输开始的延迟时间,以便等待

    更多的从服务器连接上来。查看Redis介质中的Redis.conf示例获得更多信息。

    只读从服务器

    1

    2

    3

    4

    5

    6

    7

    8

    从Redis 2.6开始,从服务器支持只读模式,并且是默认模式。这个行为是由Redis.conf文件中的slave-read-only 参数控制的,

    可以在运行中通过CONFIG SET来启用或者禁用。

     

    只读的从服务器会拒绝所有写命令,所以对从服务器不会有误写操作。但这不表示可以把从服务器实例暴露在危险的网络环境下,

    因为像DEBUG或者CONFIG这样的管理命令还是可以运行的。不过你可以通过使用rename-command命令来为这些命令改名来增加安全性。

     

    你可能想知道为什么只读限制还可以被还原,使得从服务器还可以进行写操作。虽然当主从服务器进行重新同步或者从服务器重启后,

    这些写操作都会失效,还是有一些使用场景会想从服务器中写入临时数据的,但将来这个特性可能会被去掉。

    限制有N个以上从服务器才允许写入

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    从Redis 2.8版本开始,可以配置主服务器连接N个以上从服务器才允许对主服务器进行写操作。但是,因为Redis使用的是异步主从复制,

    没办法确保从服务器确实收到了要写入的数据,所以还是有一定的数据丢失的可能性。

     

    这一特性的工作原理如下:

    1)从服务器每秒钟ping一次主服务器,确认处理的复制流数量。

    2)主服务器记住每个从服务器最近一次ping的时间。

    3)用户可以配置最少要有N个服务器有小于M秒的确认延迟。

    4)如果有N个以上从服务器,并且确认延迟小于M秒,主服务器接受写操作。

     

    还可以把这看做是CAP原则(一致性,可用性,分区容错性)不严格的一致性实现,虽然不能百分百确保一致性,但至少保证了丢失的数据不会超过M秒内的数据量。

     

    如果条件不满足,主服务器会拒绝写操作并返回一个错误。

    1)min-slaves-to-write(最小从服务器数)

    2)min-slaves-max-lag(从服务器最大确认延迟)

    Redis 持久化日志

    RDB 是主进程 fork一个子进程进行的、所以不影响主进程的操作。

    AOF 和主进程是一个线程(redis是单线程)会对主进程对外提供请求的效率造成影响,接收请求、处理请求、写aof文件这三步是串行原子执行的。而非异步多线程执行的。

    ======            通过redis实现服务器崩溃等数据恢复             ======
    由于redis存储在内存中且提供一般编程语言常用的数据结构存储类型,所以经常被用于做服务器崩溃宕机的数据恢复处理。服务器可以在某些指定过程中将需要保存的数据以json对象等方式存储到redis中,也就是我们常说的快照,当服务器运行时读取redis来判断是否有待需要恢复数据继续处理的业务。当一次业务处理结束后再删除redis的数据即可。redis提供两种将内存数据导出到硬盘实现数据备份的方法

    1)RDB方式(默认)


    RDB方式的持久化是通过快照(snapshotting)完成的,当符合一定条件时Redis会自动将内存中的所有数据进行快照并存储在硬盘上。进行快照的条件可以由用户在配置文件中自定义,由两个参数构成:时间和改动的键的个数。当在指定的时间内被更改的键的个数大于指定的数值时就会进行快照。RDB是redis默认采用的持久化方式,在配置文件中已经预置了3个条件:
    save 900 1      #900秒内有至少1个键被更改则进行快照
    save 300 10     #300秒内有至少10个键被更改则进行快照
    save 60 10000   #60秒内有至少10000个键被更改则进行快照

     

    可以存在多个条件,条件之间是"或"的关系,只要满足其中一个条件,就会进行快照。 如果想要禁用自动快照,只需要将所有的save参数删除即可。
    Redis默认会将快照文件存储在当前目录(可CONFIG GET dir来查看)的dump.rdb文件中,可以通过配置dir和dbfilename两个参数分别指定快照文件的存储路径和文件名。

     

    Redis实现快照的过程


    -  Redis使用fork函数复制一份当前进程(父进程)的副本(子进程);
    -  父进程继续接收并处理客户端发来的命令,而子进程开始将内存中的数据写入硬盘中的临时文件;
    -  当子进程写入完所有数据后会用该临时文件替换旧的RDB文件,至此一次快照操作完成。
    -  在执行fork的时候操作系统(类Unix操作系统)会使用写时复制(copy-on-write)策略,即fork函数发生的一刻父子进程共享同一内存数据,当父进程要更改其中某片数据时(如执行一个写命令 ),操作系统会将该片数据复制一份以保证子进程的数据不受影响,所以新的RDB文件存储的是执行fork一刻的内存数据。

     

    Redis在进行快照的过程中不会修改RDB文件,只有快照结束后才会将旧的文件替换成新的,也就是说任何时候RDB文件都是完整的。这使得我们可以通过定时备份RDB文件来实 现Redis数据库备份。RDB文件是经过压缩(可以配置rdbcompression参数以禁用压缩节省CPU占用)的二进制格式,所以占用的空间会小于内存中的数据大小,更加利于传输。

     

    除了自动快照,还可以手动发送SAVE或BGSAVE命令让Redis执行快照,两个命令的区别在于,前者是由主进程进行快照操作,会阻塞住其他请求,后者会通过fork子进程进行快照操作。 Redis启动后会读取RDB快照文件,将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同,这个时间也不同。通常将一个记录一千万个字符串类型键、大小为1GB的快照文件载入到内 存中需要花费20~30秒钟。 通过RDB方式实现持久化,一旦Redis异常退出,就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合,通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。如果数据很重要以至于无法承受任何损失,则可以考虑使用AOF方式进行持久化。

    日志格式

    是压缩过的占用体积小,容灾恢复快
    $cat dump.rdb
    REDIS0008    redis-ver4.0.1
    redis-bits@ctimeYused-mem 
                                    aof-preamblerepl-id(484f9d49a700c4b9b136f0fd40d2d6e5a8460438
                                                                                                   repl-offa;^foobarfoobar^KJ_U

    OMG...一堆乱码隐约可以看到一些和redis相关的字符串为了更直观的感受下RDB的内容我们用redis自带的工具redis-check-rdb来看下

    
     
    redis-check-rdb dump.rdb
    [offset 0] Checking RDB file dump.rdb
    [offset 26] AUX FIELD redis-ver = '4.0.1'
    [offset 40] AUX FIELD redis-bits = '64'
    [offset 52] AUX FIELD ctime = '1504234774'
    [offset 67] AUX FIELD used-mem = '2139016'
    [offset 83] AUX FIELD aof-preamble = '0'
    [offset 133] AUX FIELD repl-id = '484f9d49a700c4b9b136f0fd40d2d6e5a8460438'
    [offset 148] AUX FIELD repl-offset = '0'
    [offset 150] Selecting DB ID 0
    [offset 173] Selecting DB ID 2
    [offset 194] Checksum OK
    [offset 194] \o/ RDB looks OK! \o/
    [info] 2 keys read
    [info] 1 expires
    [info] 0 already expired

    这下就好看多了首先可以看到是一些AUX FIELD辅助域4.0特有用来配合全新的主从同步方式PSYNC2后面会专门来介绍PSYNC2然后可以看到DB0和DB2是有内容的Checksum也OK最后是说一共有2个key其中一个设置了过期时间到目前为止还都没有过期。

    2)AOF方式


    默认情况下Redis没有开启AOF(append only file)方式的持久化,可以在redis.conf中通过appendonly参数开启:

    appendonly yes
    在启动时Redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中,载入的速度相较RDB会慢一些

    开启AOF持久化后每执行一条会更改Redis中的数据的命令,Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同,都是通过dir参数设置的,默认的文件名是appendonly.aof,可以通过appendfilename参数修改:

    appendfilename appendonly.aof
    配置redis自动重写AOF文件的条件

    auto-aof-rewrite-percentage 100  # 当目前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写,如果之前没有重写过,则以启动时的AOF文件大小为依据

    auto-aof-rewrite-min-size 64mb   # 允许重写的最小AOF文件大小
    配置写入AOF文件后,要求系统刷新硬盘缓存的机制

    # appendfsync always   # 每次执行写入都会执行同步,最安全也最慢
    appendfsync everysec   # 每秒执行一次同步操作
    # appendfsync no       # 不主动进行同步操作,而是完全交由操作系统来做(即每30秒一次),最快也最不安全

    Redis允许同时开启AOF和RDB,既保证了数据安全又使得进行备份等操作十分容易。此时重新启动Redis后Redis会使用AOF文件来恢复数据,因为AOF方式的持久化可能丢失的数据更少

    日志格式

    没有压缩的,文件大,容灾恢复慢

    同样的数据我们来看下在AOF文件中是如何保存的
    
    $cat appendonly.aof
    *2
    $6
    SELECT
    $1
    0
    *3
    $3
    set
    $3
    foo
    $3
    bar
    *3
    $9
    PEXPIREAT
    $3
    foo
    $13
    1504255377087
    *2
    $6
    

     很明显一条一条的没有压缩的命令

    3)混合RDF/AOF 方式

    在redis4.0 可以开启会和模式,默认时关闭的

    混合持久化同样也是通过bgrewriteaof完成的,不同的是当开启混合持久化时,fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件,然后在将重写缓冲区的增量命令以AOF方式写入到文件,写入完成后通知主进程更新统计信息,并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说:新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据,如下图:

     

    数据恢复

    当我们开启了混合持久化时,启动redis依然优先加载aof文件,aof文件加载可能有两种情况如下:

    aof文件开头是rdb的格式, 先加载 rdb内容再加载剩余的 aof。

    aof文件开头不是rdb的格式,直接以aof格式加载整个文件。

    日志格式

    此时的aof文件已经和只开启AOF持久化文件不一样了,上半部分是RDB持久化的数据,下半部分是AOF格式数据。

    显而易见前半段是RDB格式的全量数据后半段是redis命令格式的增量数据。

    展开全文
  • redis主从同步修复

    2013-11-13 15:53:57
    Redis从端无法从主端同步数据,在日志中有如下报错信息:找了一份2.6.16的源码,根据错误信息,定位到如下代码:根据以上代码,到Redis主端执行BGSAVE,会报如下错误信息:由此可以判定,是由于Redis主端无法写入...
  • 简介Redis(全称:Remote Dictionary Server 远程字典服务)是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的API。本章我们将介绍如何基于...
  •  Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,和Memcached类似,它支持存储的value类型相对更多,包括string(字符串)、list(链表)、set(集合)、zset(sorted ...
  • Redis数据同步:主从库实现数据一致 Redis实例宕机了怎么办 我们知道通过AOF和RDB,如果Redis发生了宕机,它们可以分别通过回放日志和重新读入 RDB文件的方式恢复数据,从而保证尽量少丢失数据,提升可靠性。 不过,...
  • Canal+Kaka实现mysql与Redis数据同步 一、Canal简介 canal主要用途是基于 MySQL 数据库增量日志解析,提供增量数据订阅和消费,早期阿里巴巴因为杭州和美国双机房部署,存在跨机房同步的业务需求,实现方式主要是...
  • 首先查看redis日志,发现告警时间点redis主节点被重启了,发生了主备切换,并且在日志中发现这么一段 [3081] 06 Dec 02:33:28.090 # Client addr=****:35810 fd=122 name= age=88 idle=88 flags=S db=0 sub=0 ...
  • 通过redis主存复制(一主两从) 数据同步过程日志,分析Redis主从复制的工作原理,Redis允许同时开启AOF和RDB,既保证了数据安全又使得进行备份等操作十分容易。此时重新启动RedisRedis会使用AOF文件来恢复数据,...
  • redis 4 增量同步日志详解1、1主 2从 环境下,关闭原先的master节点2、在新的master上执行 slaveof no one看到的日志:6855:M 02 Sep 15:43:16.871 # Setting secondary replication ID to 2ba403b0a69dcacbfe92650...
  • 从 2010 年开始,业务逐步尝试数据库日志解析获取增量变更进行同步,由此衍生出了大量的数据库增量订阅和消费业务。 2.工作原理 MySQL主备复制原理 MySQL master 将数据变更写入二进制日志( binary log, ...
  • 1、redis的索引索引的结构索引会决定一个数据是如何进行存储和检索,常用的索引的结构有哈希表(适合键值对的存储结构,精确查找快)、B+树( 适合磁盘数据的检索,适合排序、范围查找)、字典树(适合做字符串模糊...
  • Redis主从同步源码浅析-Master端

    千次阅读 2015-04-23 18:01:06
    关于Redis的主从同步的基本介绍这里有:Replication, 不多介绍了。本文只涉及到主库的代码,从库的相关代码改天补上。...同步采用类似mysql的操作日志重放方式,将写操作分发到从库重放。每次从库启动必须从主库重新
  • repl-ping-slave-period主从心跳ping的...repl-backlog-size 主节点保存操作日志的大小。默认1M repl-backlog-ttl 主节点保存操作日志的时间。默认3600秒 client-output-buffer-limit 这个参数分为3部分,第二部...
  • 基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的API。 redis是一个key-value存储系统。 它支持存储的value类型:string(字符串)、list(链表)、set(集合)、zset(sorted set 有序集合)和hash(哈希...
  • 前两节课,我们学习了 AOF 和 RDB,如果 Redis 发生了宕机,它们可以分别通过回放日志和重新读入 RDB 文件的方式恢复数据,从而保证尽量少丢失数据,提升可靠性。 不过,即使用了这两种方法,也依然存在服务不可用...
  • 前几天,在修改一台从节点的redis的监听端口后,重启了下redis,发现...查看了redis日志,发现日志里出现很多的“I/O error trying to sync with MASTER:connection lost'” 百度了下,发现是client-output-buffe...
  • 本文是我自己经过实践记录的,环境搭建简单快速,适合于前期学习(如果想深入了解Kafka、Redis、MySQL集群同步等相关知识本文不适用)。使用canal同步有两种方案,一种是使用canal原始的tcp方式,一种是使用canal+...
  • redis和mysql数据同步

    2021-04-17 22:49:15
    redis mysql同步 redis持久化 RDB模式,较MBR省磁盘空间 部署lamp架构 server1: 开启redis服务 systemctl start redis redis-cli vim /etc/redis/redis.conf ##编辑配置文件,打开日志,每秒刷新 appendfsync ...
  • Redis同步操作失败的原因

    千次阅读 2015-07-30 18:19:35
    今天弄了下 Redis 的主从同步,设置方法其实很简单的,但崩溃的是遇到个莫名其妙的问题,始终同步不了。。 看了看错误日志:Unable to connect to MASTER: Invalid argument全是参数错误,搞了好半天,终于在 ...
  • redis之aof日志持久化复制代码Aof 的配置appendonly no # 是否打开 aof日志功能appendfsync always # 每1个命令,都立即同步到aof. 安全,速度慢appendfsync everysec # 折衷方案,每秒写1次appendfsync no # 写入工作...
  • Redis部分再同步同步复制

    千次阅读 2013-12-15 10:35:29
    正如我在以前的博客文章中写道,目前我正在开发Redis Slave的部分再同步功能。 我们的想法是,我们有复制流的后备日志,可达到指定的字节数量(默认将是几百兆字节)。 如果一个Slave连接丢失时,它会再次建立连接,...
  • 本文从两大方面介绍阿里云Redis服务,一是Redis内核支持基于时间点的备份恢复,一是Redis基于AOF日志的增量同步机制设计,并分别通过假设场景,详细的分析了备份恢复流程和AOF PSYNC流程。一起来了解下吧。Redis内核...
  • 同步需要一直运行着,所以这个创建一个普通的Maven工程,然后打成jar包放到服务器进行运行(最好现在本地测试了没有问题在放上去) 以下是依赖 <dependencies> <!--阿里巴巴canal--> <dependency&...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 633
精华内容 253
热门标签
关键字:

redis日志同步

redis 订阅