Redis--主从复制

最新推荐文章于 2023-03-07 18:03:15 发布

小宇宙清歡渡

最新推荐文章于 2023-03-07 18:03:15 发布

阅读量179

点赞数

文章标签： redis 服务器数据库

本文链接：https://blog.csdn.net/weixin_42614150/article/details/125121885

版权

1.1: 主从复制的简介

主从复制，就是主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主。
主从复制的目的：
	1)	读写分离，性能扩展。
	2)	容灾快速恢复。
一主多从，只能有一个主服务器，可以有多个从服务器。
主服务器以写为主，从服务器以读为主。

1.2: 主从复制的搭建

1: 创建一主两从的模式，创建三个.conf文件并引入redis.conf文件
	include /opt/myRedis/redis.conf
  redis6379.conf
  redis6380.conf
  redis6381.conf
2: 在三个配置文件中配置相应的内容：
  1: 指定文件的pid文件
    pidfile /var/run/redis_6379.pid
    pidfile /var/run/redis_6380.pid
    pidfile /var/run/redis_6381.pid
  2: 指定端口号
    port 6379
    port 6380
    port 6381
  3: 指定rdb文件名称（/usr/local/var/db/redis/）
    dbfilename dump6379.rdb
    dbfilename dump6380.rdb
    dbfilename dump6381.rdb
3: 启动三个redis服务
4: 连接三个redis服务
5: 通过 info replication 打印主从复制的相关信息：
未配置主从复制之前：
    127.0.0.1:6379> info replication
    # Replication
    role:master	目前角色，主机
    connected_slaves:0	从服务器数量
    master_failover_state:no-failover
    master_replid:154269490340bab6e42eeab09063d6b59c6c40af
    master_replid2:0000000000000000000000000000000000000000
    master_repl_offset:0
    second_repl_offset:-1
    repl_backlog_active:0
    repl_backlog_size:1048576
    repl_backlog_first_byte_offset:0
    repl_backlog_histlen:0
    127.0.0.1:6379> 
配置一主多从的规则：    
	配置从服务器，不配置主服务器	
	在6380和6381主机上执行命令：slaveof <ip> <port> 成为某个实例的从服务器
	查看6379服务器状态：
    127.0.0.1:6379> info replication
    # Replication
    role:master	主机
    connected_slaves:2 从机数量
    slave0:ip=127.0.0.1,port=6380,state=online,offset=28,lag=0	从机1状态
    slave1:ip=127.0.0.1,port=6381,state=online,offset=28,lag=1	从机2状态
    master_failover_state:no-failover
    master_replid:8fb31f76ccb72aac931bc6952d5bf5caaa4532b7
    master_replid2:0000000000000000000000000000000000000000
    master_repl_offset:28
    second_repl_offset:-1
    repl_backlog_active:1
    repl_backlog_size:1048576
    repl_backlog_first_byte_offset:1
    repl_backlog_histlen:28
    127.0.0.1:6379> 
  查看6380和6381服务器状态：
    127.0.0.1:6380> info replication
    # Replication
    role:slave 从机
    master_host:127.0.0.1 主机地址
    master_port:6379	主机端口
    master_link_status:up
    master_last_io_seconds_ago:2
    master_sync_in_progress:0
    slave_read_repl_offset:126
    slave_repl_offset:126
    slave_priority:100
    slave_read_only:1
    replica_announced:1
    connected_slaves:0
    master_failover_state:no-failover
    master_replid:8fb31f76ccb72aac931bc6952d5bf5caaa4532b7
    master_replid2:0000000000000000000000000000000000000000
    master_repl_offset:126
    second_repl_offset:-1
    repl_backlog_active:1
    repl_backlog_size:1048576
    repl_backlog_first_byte_offset:15
    repl_backlog_histlen:112
    127.0.0.1:6380> 
6: 测试一主两仆
  在主机中写入数据：
  127.0.0.1:6379> set k1 v1
  OK
  127.0.0.1:6379>
  在从机中获取数据：
  127.0.0.1:6380> get k1
  "v1"
  127.0.0.1:6380> 
  但是在从机中写入数据时会出现错误：
  127.0.0.1:6380> set k2 v2
  (error) READONLY You can't write against a read only replica.
  127.0.0.1:6380> 
  从机中只能读取数据，不能写入数据，读写分离。

当从服务挂掉之后，重启从服务器之后，从服务器变成为主服务器，需要从新指定他的主服务器是谁，内容会自动复制到此从服务器中。	
当主服务器挂掉之后，从服务器还是从服务器，从服务器不会变成主服务器。主服务器重启之后，还是之前的主服务器。

1.3: 主从复制的原理

1: 主从关系建立后，Slave节点向Master节点发送一个 SYNC 命令请求进行主从同步。
2: Master节点收到 SYNC 命令后，执行 fork 创建一个子进程，子进程中将所有的数据按特定编码存储到 RDB（Redis Database） 文件中，这就产生了数据库的快照。开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令。主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
3: 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照。Master节点将此快照发送给Slave节点，Slave节点接收并载入快照。
4: Master节点接着将生成快照、发送快照期间积压的写命令发送给Slave节点，Slave节点接收这些命令并执行，命令执行后，Slave节点中的数据也就有了同样的变更。
5: 此后，Master节点源源不断地新执行的写命令同步到Slave节点，Slave节点执行传播来的命令。如此，主从数据保持一致。需要说明的是，命令传播存在时延的，所以任意时刻，不能保证主从节点间数据完全一致。

全量复制：就是Slave服务器接收到数据库文件时，将其存盘加载到内存中。
增量辅助：Master服务器将新的收集到的写命令依次传递给Slave服务器，完成数据同步。

1.4: 主从复制-薪火相传

上一个slave可以是下一个slave的Master，slave同样可以接收其他slave的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。但是也产生了另一个风险：一旦某个slave出现意外停止运行后，以这台slave为主的其他slave都无法保存数据
设置：和普通的主从复制一样都是slaveof <ip> <port>，只不过master不再是只有一个
如果中间切换master：和普通的主从复制一样，都是清除之前的数据，重新建立并且拷贝最新数据

1.5: 主从复制-反客为主

1: 哪怕这个slave变成了另外一个slave的master，但他的身份仍然是slave，也就是也就无法完成写操作。
2: 如果在master没有关闭时这个slave要完成写操作，那可以执行slaveof no noe让其不再成为任何服务器的slave，从而成为其他slave的master，这也就是常说的反客为主。
3: 当一个master关闭后，后面的slave可以立刻自动升级为master，而后面的salve无需修改，这个就是我们常说的哨兵模式。

1.6: 主从复制-哨兵模式

哨兵模式简单来说就是反客为主的主动版，能够后台监控master是否故障，如果发生故障则根据投票数自动将slave转换为master。
配置哨兵
	在一主二从模式下自定义目录下新建sentinel.conf文件
在配置文件中填写内容
  sentinel  monitor  mymaster  127.0.0.1  6379  1
  其中mymaster为监控对象起的服务器名称， 1 为 至少有多少个哨兵同意迁移的数量。
启动哨兵
	执行redis-sentinel  /myredis/sentinel.conf
要想让Redis的sentinel（士兵守护）进程在后台自动运行，只要在sentinel配置文件里加上
  设置daemonize
  	daemonize yes
  设置日志文件
  	logfile /var/log/sentinel/5000/sentinel.log
复制延迟：
		由于所有的写操作都先在Master上操作，然后同步更新到Slave还是那个，所以从Master同步到Slave机器上有一定的延迟，当系统繁忙时，延迟问题会更加严重，当Slave机器数量也增加的话，会使的这个问题更加严重。
		
选择规则：
	1: 选择优先级靠前的，优先级0到100，越小优先级越高。
	2: 选择偏移量最大的，偏移量是指数据库中数据最多的。
	3: 选择runid最小的从服务，每个redis实例启动后会随机生成一个40位的runid。
	
如何查看优先级，在redis.conf文件中：
  # By default the priority is 100.
  replica-priority 100