专业建设家电维修网站公司,网站建设的要求及标准,商城网站布局,wordpress 4.9.6 漏洞1. 是什么
1.1 官网地址 https://redis.io/docs/management/replication/ 1.2 一句话 1. 就是主从复制#xff0c;master以写为主#xff0c;slave以读为主 2. 当master数据变化的时候#xff0c;自动将新的数据异步同步到其它slave数据库 2. 能干嘛 1. 读写分离 2. 容灾…1. 是什么
1.1 官网地址 https://redis.io/docs/management/replication/ 1.2 一句话 1. 就是主从复制master以写为主slave以读为主 2. 当master数据变化的时候自动将新的数据异步同步到其它slave数据库 2. 能干嘛 1. 读写分离 2. 容灾恢复 3. 数据备份 4. 水平扩容支撑高并发 3. 怎么玩
3.1 配从(库)不配主(库)
3.2 权限细节 1. master如果配置了requirepass参数:需要密码登陆 2. 那么slave就要配置masterauth来设置校验密码否则的话master会拒绝slave的访问请求 3.3 基本操作命令 1. info replication 可以查看复制节点的主从关系和配置信息 2 replicaof 主库IP 主库端口 一般写入进redis.conf配置文件内 3. slaveof 主库IP 主库端 每次与master断开之后都需要重新连接除非你配置进redis.conf文件 在运行期间修改slave节点的信息如果该数据库已经是某个主数据库的从数据库那么会停止和原主数据库的同步关系转而和新的主数据库同步重新拜码头 4. slaveof no one 使当前数据库停止与其他数据库的同步转成主数据库自立为王 4. 案例演示
4.1 架构说明
4.1.1 一个master两个slave 4.1.2 拷贝多个redis.conf文件 redis6379.conf redis6380.conf redis6381.conf 4.2 小口诀
4.2.1 三边网络相互ping通且注意防火墙配置
4.2.2 三大命令 1. 主从复制 replicaof 主库IP 主库端 配从(库)不配主(库) 2. 改换门庭 slaveof 新主库IP 新主库端门 3. 自立为王 slaveof no one 4.3 修改配置文件细节操作,以 redis6379.conf为例
1.开启daemonize yes 2.注释掉bind 127.0.0.1 3.protected-mode no 4.指定端口 5.指定当前工作目录dir 6.pid文件名字,pidfile 7.log文件名字,logfile 8.requirepass 9.dump.rdb名字 10.aof文件,appendfilename 11.从机访问主机的通行密码masterauth必须 , 从机需要配置主机不用 4.4 常用3招
4.4.1 一主二仆 方案1: 配置文件固定写死 1. 配置文件执行 replicaof 主库IP 主库端口 2. 配从(库)不配主(库) 配置从机6380 配置从机6381 3. 先master后两台slave依次启动 4. 主从关系查看 ~ 日志 主机日志 备机日志 ~ 命令 info replication命令查看 主从问题演示 1.从机可以执行写命令吗? 2.从机切入点问题 slave是从头开始复制还是从切入点开始复制? master启动写到k3 slave1跟着master同时启动跟着写到k3 slave2写到k3后才启动那之前的是否也可以复制 Y首次一锅端后续跟随master写slave跟 3.主机shutdown后从机会上位吗? 主机shutdown后情况如何从机是上位还是原地待命 从机不动原地待命从机数据可以正常使用等待主机重启动归来 4.主机shutdown后重启后主从关系还在吗? 从机还能否顺利复制? 5.某台从机down后master继续从机重启后它能跟上大部队吗? 方案2: 命令操作手动指定 1. 从机停机去掉配置文件中的配置项3台目前都是主机状态各不从属 2. 3台master 目 3. 预设的从机上执行命令 ~ slaveof 主库IP 主库端 ~ 效果 4. 用命令使用的话2台从机重启后关系还在吗? 配置 VS 命令的区别当堂试验讲解 配置持久稳定 命令当次生效 4.4.2 薪火相传 1. Aslave可以是下个slave的masterslave同样可以接收其他slaves的连接和同步请求那么该slave作为了链条中下一个的master可以有效减轻主master的写压力 2. 中途变更转向:会清除之前的数据重新建立拷贝最新的 3. slaveof 新主库IP 新主库端口 4.4.3 反客为主 SLAVEOF no one 使当前数据库停止与其他数据库的同步转成主数据库 5. 复制原理和工作流程
5.1 slave启动同步初请
5.1.1 slave启动成功连接到master后会发送一个sync命令
5.1.2 slave首次全新连接master,一次完全同步 (全量复制)将被自动执行slave自身原有数据会被master数据覆盖清除
5.2 首次连接全量复制
5.2.1 master节点收到sync命令后会开始在后台保存快照(即RDB持久化主从复制时会触发RDB),同时收集所有接收到的用于修改数据集命令缓存起来master节点执行RDB持久化完后master将rdb快照文件和所有缓存的命令发送到所有slave,以完成一次完全同步
5.2.2 而slave服务在接收到数据库文件数据后将其存盘并加载到内存中从而完成复制初始化
5.3 心跳持续保持通信 repl-ping-replica-period 10 master发出PING包的周期默认是10秒 5.4 进入平稳增量复制 Master继续将新的所有收集到的修改命令自动依次传给slave,完成同步 5.5 从机下线重连续传 master会检查backlog里面的offsetmaster和slave都会保存一个复制的offset还有-个masterIdoffset是保存在backlog中的。Master只会把已经复制的offset后面的数据复制给Slave类似断点续传 6. 复制的缺点
6.1 复制延时信号衰减 由于所有的写操作都是先在Master上操作然后同步更新到Slave上所以从Master同步到Slave机器有一定的延迟当系统很繁忙的时候延迟问题会更加严重Slave机器数量的增加也会使这个问题更加严重。 6.2 master挂了如何办? 默认情况下不会在slave节点中自动重选一个master 那每次都要人工干预? 无人值守安装变成刚需
