(Docker容器技术)学习Docker中 镜像与容器数据卷、映射关系!手把手带你安装 MySql主从同步 和 Redis三主三从集群!并且进行主从切换与扩容操作,还有分析 哈希分区 等知识点!

1. 镜像

1.1 镜像是什么

镜像(images)是一种轻量级、可执行的独立软件包,它包含运行某个软件所需的所有内容

  • 我们把应用程序和配置依赖打包好形成一个可交付的运行环境(包括代码、运行时需要的库、环境变量和配置文件等),

    这个打包好的运行环境就是image镜像文件

只有通过这个镜像文件才能生成Docker容器实例(类似Java中new出来一个对象)。

1.2 分层拉取

以我们的pull为例,在下载的过程中我们可以看到docker的镜像好像是在一层一层的在下载

在这里插入图片描述

1.3 UnionFS(联合文件系统)

Union文件系统(UnionFS)是一种**分层、轻量级并且高性能的文件系统**,它支持对文件系统的修改作为一次提交来一层层的叠加,同时可以将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem)

Union 文件系统是 Docker 镜像的基础。

镜像可以通过分层来进行继承,基于基础镜像(没有父镜像),可以制作各种具体的应用镜像。

**特性:**一次同时加载多个文件系统,但从外面看起来,只能看到一个文件系统,联合加载会把各层文件系统叠加起来,这样最终的文件系统会包含所有底层的文件和目录

1.4 Docker镜像加载原理

docker的镜像实际上由一层一层的文件系统组成,这种层级的文件系统UnionFS。

bootfs(boot file system)主要包含bootloaderkernel, bootloader主要是引导加载kernel

  1. Linux刚启动时会加载bootfs文件系统

    在Docker镜像的最底层是引导文件系统bootfs。

    这一层与我们典型的Linux/Unix系统是一样的,包含boot加载器和内核。

  2. 当boot加载完成之后整个内核就都在内存中了,此时内存的使用权已由bootfs转交给内核,此时系统也会卸载bootfs。

    rootfs (root file system),在bootfs之上。

在这里插入图片描述

包含的就是典型 Linux 系统中

  • /dev
  • /proc
  • /bin
  • /etc
  • 等标准目录和文件

rootfs就是各种不同的操作系统发行版,比如Ubuntu,Centos等等。

1.4.1 镜像的大小

平时我们安装进虚拟机的CentOS都是好几个G,为什么docker的镜像才200M??

在这里插入图片描述

对于一个精简的OS,rootfs可以很小,只需要包括最基本的命令、工具和程序库就可以了,因为底层直接用Host的kernel,自己只需要提供 rootfs 就行了。

由此可见对于不同的linux发行版, bootfs基本是一致的, rootfs会有差别, 因此不同的发行版可以公用bootfs。

1.5 为什么采取分层架构

镜像分层有这么些好处

  • 共享资源

  • 方便复制迁移

  • 可以复用

比如说有多个镜像都从相同的 base 镜像构建而来,那么 Docker Host 只需在磁盘上保存一份 base 镜像;

同时内存中也只需加载一份 base 镜像,就可以为所有容器服务了。

而且镜像的每一层都可以被共享。

1.6 要点

Docker镜像层都是只读的,容器层是可写的

当容器启动时,一个新的可写层被加载到镜像的顶部

这一层通常被称作容器层,“容器层”之下的都叫作:镜像层

在这里插入图片描述

当容器层启动时,一个新的可写层被加载到镜像的顶部

所有对容器的改动(添加、删除、修改)都只会发生再容器层中

只有容器层是可写的,容器层下面的所有镜像层都是只读的

1.7 commit

docker commit 容器ID

commit提交容器副本使之成为一个新的镜像

具体参数:

docker commit -m="提交的描述信息" -a="作者" 容器ID 要创建的目标镜像名:[标签名]

Docker中的镜像分层,支持通过扩展现有镜像,创建新的镜像

类似Java继承于一个Base基础类,自己再按需扩展。

新镜像是从 base 镜像一层一层叠加生成的。每安装一个软件,就在现有镜像的基础上增加一层

2. 容器数据卷

在这里插入图片描述

容器数据卷,亦可以说是数据映射,将容器内部的目标文件或目录映射到本机的文件或目录中,这样就可以通过本机的文件来操控容器内的文件了

这样方便我们对于容器的配置

使用命令:

docker run -it --privileged=true -v /宿主机绝对路径目录:/容器内目录 镜像名

2.1 宿主vs容器之间映射添加容器卷

直接命令添加

公式:

docker run -it -v /宿主机目录:/容器内目录 ubuntu /bin/bash
# 例如
docker run -it --name myu3 --privileged=true -v /tmp/myHostData:/tmp/myDockerData ubuntu /bin/bash
docker run -it --privileged=true -v /宿主机绝对路径目录:/容器内目录 镜像名

查看数据卷是否挂载成功

docker inspect 容器ID

在这里插入图片描述

容器和宿主机之间数据共享

  1. docker修改,主机同步获得
  2. 主机修改,docker同步获得
  3. docker容器stop,主机修改,docker容器重启看数据是否同步

2.2 读写规则映射添加说明

2.2.1 读写(默认)

docker run -it -v /宿主机绝对路径目录:/容器内目录:rw 镜像名

2.2.2 只读

容器示例内部被限制,只能读取不能写

docker run -it -v /宿主机绝对路径目录:/容器内目录:ro 镜像名

ro :read only

此时如果宿主机写入内容,可以同步给容器内,容器可以读取到

2.3 卷的继承和共享

docker run -it --volumes-from 父类容器别名 --name 别名 镜像名

3. Mysql主从同步

3.1 新建主服务容器示例 3307

docker run -p 3307:3306 --name mysql-master \
-v /mydata/mysql-master/log:/var/log/mysql \
-v /mydata/mysql-master/data:/var/lib/mysql \
-v /mydata/mysql-master/conf:/etc/mysql/conf.d \
-e MYSQL_ROOT_PASSWORD=root  \
--name mysql-master \
-d mysql:8.0.39

创建一个端口3307的 mysql:8.0.39 容器

日志目录映射在:/mydata/mysql-master/log

数据目录映射在:/mydata/mysql-master/data

配置目录映射在:/mydata/mysql-master/conf

3.2 创建配置文件

进入 /mydata/mysql-master/conf 目录下新建my.cnf 文件

[mysqld]

## 设置server_id,同一局域网中需要唯一
server_id=101

## 指定不需要同步的数据库名称
binlog-ignore-db=mysql

## 开启二进制日志功能
log-bin=mall-mysql-bin

## 设置二进制日志使用内存大小(事务)
binlog_cache_size=1M  

## 设置使用的二进制日志格式(mixed,statement,row)
binlog_format=mixed  

## 二进制日志过期清理时间。默认值为0,表示不自动清理。
expire_logs_days=7  

## 跳过主从复制中遇到的所有错误或指定类型的错误,避免slave端复制中断。
## 如:1062错误是指一些主键重复,1032错误是因为主从数据库数据不一致
slave_skip_errors=1062

当创建完毕后,需要重启master实例

docker restart mysql-master

3.3 创建数据同步用户

进入master3307容器,并登入mysql

docker exec -it mysql-master /bin/bash
mysql -u root -p root

在master3307容器内部,创建数据同步用户

CREATE USER 'slave'@'%' IDENTIFIED BY '123456';
GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* To 'slave'@'%';

3.4 创建从容器实例3308

docker run -p 3308:3306 --name mysql-master \
-v /mydata/mysql-slave/log:/var/log/mysql \
-v /mydata/mysql-slave/data:/var/lib/mysql \
-v /mydata/mysql-slave/conf:/etc/mysql/conf.d \
-e MYSQL_ROOT_PASSWORD=root  \
--name mysql-slave \
-d mysql:8.0.39

当创建完毕后,也需要重启slave实例

docker restart mysql-slave

3.5 配置主从同步

change master to master_host='192.168.81.102', master_user='slave', master_password='123456', master_port=3307, master_log_file='mall-mysql-bin.000001', master_log_pos=617, master_connect_retry=30 get_master_public_key=1;

参数说明:

参数说明
master_host主数据库的IP地址
master_port主数据库的运行端口
master_user在主数据库创建的用于同步数据的用户账号
master_password在主数据库创建的用于同步数据的用户密码
master_log_file指定从数据库要复制数据的日志文件,通过查看主数据的状态,获取File参数
master_log_pos指定从数据库从哪个位置开始复制数据,通过查看主数据的状态,获取Position参数
master_connect_retry连接失败重试的时间间隔,单位为秒

在这里插入图片描述

当 从库,IO和SQL都处于Yes状态,就代表主从同步成功

3.6 可能出现的报错:

3.6.1 日志不一致

Got fatal error 1236 from source when reading data from binary log: 'binlog truncated in the middle of event; consider out of disk space on source; the first event 'mall-mysql-bin.000001' at 617, the last event read from './mall-mysql-bin.000001' at 126, the last byte read from './mall-mysql-bin.000001' at 712.'

出现这种报错,可能代表你的主从日志不一致,这时候需要更改一下从库针对主库的日志版本即可

3.6.1.1 刷新主库日志

刷新binlog日志

flush logs;

刷新后的日志会+1

例如上面的 File: mysql-bin.000001 会变成 File: mysql-bin.000002

再次查看master状态

mysql> flush logs;
Query OK, 0 rows affected (0.02 sec)

mysql> show master status\G;
*************************** 1. row ***************************
             File: mall-mysql-bin.000002
         Position: 157
     Binlog_Do_DB: 
 Binlog_Ignore_DB: mysql
Executed_Gtid_Set: 
1 row in set (0.00 sec)

ERROR: 
No query specified
3.6.1.2 修改从库

直接在原来的基本配置上进行修改

CHANGE MASTER TO MASTER_LOG_FILE='mall-mysql-bin.000002',MASTER_LOG_POS=157;

MASTER_LOG_FILE=主库日志版本(即是 File: mall-mysql-bin.000002)

MASTER_LOG_POS=主库位置(即是 Position: 157)

然后进行重启

start slave;

然后再进行查看从库状态

mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for source to send event
                  Master_Host: 192.168.81.102
                  Master_User: slave
                  Master_Port: 3307
                Connect_Retry: 30
              Master_Log_File: mall-mysql-bin.000002
          Read_Master_Log_Pos: 157
               Relay_Log_File: mall-mysql-relay-bin.000003
                Relay_Log_Pos: 331
        Relay_Master_Log_File: mall-mysql-bin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 157
              Relay_Log_Space: 720
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 101
                  Master_UUID: aac84732-b850-11ef-a9a7-0242ac110003
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Replica has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
       Master_public_key_path: 
        Get_master_public_key: 1
            Network_Namespace: 
1 row in set, 1 warning (0.00 sec)

ERROR: 
No query specified

4. Redis集群

在处理非常多条数据缓存的场景,如何设计存储案例?

  • redis进行分布式存储

4.1 三种分区

好比要缓存2~3亿数据

4.1.1 哈希取余分区

在这里插入图片描述

2亿条记录就是2亿个v,v,我们单机不行必须要分布式多机

假设有3台机器构成一个集群,用户每次读写操作都是根据公式

  • hash(key)%N

计算出哈希值,用来决定数据映射到哪一个节点上。

优点:

  • 简单粗暴,直接有效只需要预估好数据规划好节点,例如3台、8台、10台,就能保证一段时间的数据支撑。
  • 使用Hash算法让固定的一部分请求落到同一台服务器上,这样每台服务器固定处理一部分请求(并维护这些请求的信息),起到负载均衡+分而治之的作用。

缺点:

  • 原来规划好的节点,进行扩容或者缩容就比较麻烦了,

    不管扩缩,每次数据变动导致节点有变动,映射关系需要重新进行计算,在服务器个数固定不变时没有问题

    如果需要弹性扩容或故障停机的情况下,原来的取模公式就会发生变化:Hash(key)/3会变成Hash(key) /?

    此时地址经过取余运算的结果将发生很大变化,根据公式获取的服务器也会变得不可控。某个redis机器宕机了,由于台数数量变化,会导致hash取余全部数据重新洗牌。

4.1.2 一致性哈希算法分区

4.1.2.1 是什么?

一致性哈希算法在1997年由麻省理工学院中提出的,设计目标是为了解决:

  • 分布式缓存数据变动和映射问题
    • 例如:某个机器宕机了,分母数量改变了,自然取余数不OK了。
4.1.2.2 能干嘛?

提出一致性Hash解决方案

目的是当服务器个数发生变动时,尽量减少影响客户端到服务器的映射关系

4.1.2.3 三大步骤
4.1.2.3.1 算法构建一致性哈希环

​ 一致性哈希算法必然有个hash函数并按照算法产生hash值,这个算法的所有可能哈希值会构成一个全量集,这个集合可以成为一个hash空间[0,2^32-1]

​ 这个是一个线性空间,但是在算法中,我们通过适当的逻辑控制将它首尾相连(0 = 2^32),这样让它逻辑上形成了一个环形空间。

它也是按照使用取模的方法,前面笔记介绍的节点取模法是对节点(服务器)的数量进行取模

而一致性Hash算法是对2^32 取模,简单来说:

  • 一致性Hash算法将整个哈希值空间组织成一个虚拟的圆环,

    如假设某哈希函数H的值空间为0-2^32-1 (即哈希值是一个32位无符号整形),整个哈希环如下图:

    在这里插入图片描述

整个空间按顺时针方向组织,圆环的正上方的点代表0,0点右侧的第一个点代表1,以此类推,2、3、4、……直到2^32-1 ,也就是说0点左侧的第一个点代表2^32-1, 0和2^32-1 在零点中方向重合,我们把这个由2^32 个点组成的圆环称为Hash环。

4.1.2.3.2 节点映射

​ 将集群中各个IP节点映射到环上的某一个位置。

​ 将各个服务器使用Hash进行一个哈希,具体可以选择服务器的IP或主机名作为关键字进行哈希,这样每台机器就能确定其在哈希环上的位置。

​ 假如4个节点NodeA、B、C、D,经过IP地址的哈希函数计算(hash(ip)),使用IP地址哈希后在环空间的位置如下:

在这里插入图片描述

4.1.2.3.3 key落到服务器的落键规则

当我们需要存储一个kv键值对时,首先计算key的hash值,hash(key),将这个key使用相同的函数Hash计算出哈希值并确定此数据在环上的位置,从此位置沿环顺时针“行走”,第一台遇到的服务器就是其应该定位到的服务器,并将该键值对存储在该节点上。

如我们有Object A、Object B、Object C、Object D四个数据对象,经过哈希计算后,在环空间上的位置如下:

在这里插入图片描述

根据一致性Hash算法,数据A会被定为到Node A上,B被定为到Node B上,C被定为到Node C上,D被定为到Node D上。

4.1.2.3 优点
4.1.2.3.1 容错性:

在这里插入图片描述

假设Node C宕机,可以看到此时对象A、B、D不会受到影响,只有C对象被重定位到Node D。一般的,在一致性Hash算法中,如果一台服务器不可用,则受影响的数据仅仅是此服务器到其环空间中前一台服务器(即沿着逆时针方向行走遇到的第一台服务器)之间数据,其它不会受到影响。

简单说,就是C挂了,受到影响的只是B、C之间的数据,并且这些数据会转移到D进行存储。

4.1.2.3.2 扩展性:

数据量增加了,需要增加一台节点NodeX,X的位置在A和B之间,那收到影响的也就是A到X之间的数据,重新把A到X的数据录入到X上即可,不会导致hash取余全部数据重新洗牌。

在这里插入图片描述

4.1.2.4 缺点:Hash换的数据倾斜问题

一致性Hash算法在服务节点太少时,容易因为节点分布不均匀而造成数据倾斜(被缓存的对象大部分集中缓存在某一台服务器上)问题,

例如系统中只有两台服务器:

在这里插入图片描述

4.1.2.5 一致性Hash分区小结

为了在节点数目发生改变时尽可能少的迁移数据

将所有的存储节点排列在收尾相接的Hash环上,每个key在计算Hash后会顺时针找到临近的存储节点存放。

而当有节点加入或退出时仅影响该节点在Hash环上顺时针相邻的后续节点。

  • 优点

加入和删除节点只影响哈希环中顺时针方向的相邻的节点,对其他节点无影响。

  • 缺点

数据的分布和节点的位置有关,因为这些节点不是均匀的分布在哈希环上的,所以数据在进行存储时达不到均匀分布的效果。

4.1.3 哈希槽分区

4.1.3.1 是什么?
  • 为什么出现

哈希槽实质就是一个数组,数组[0,2^14 -1]形成hash slot空间。

  • 能干什么

解决均匀分配的问题,在数据和节点之间又加入了一层,把这层称为哈希槽(slot),用于管理数据和节点之间的关系,现在就相当于节点上放的是槽,槽里放的是数据。

在这里插入图片描述

槽解决的是粒度问题,相当于把粒度变大了,这样便于数据移动。

哈希解决的是映射问题,使用key的哈希值来计算所在的槽,便于数据分配。

  • 多少个hash槽

一个集群只能有16384个槽,编号 0-16383(0-2^14-1)

这些槽会分配给集群中的所有主节点,分配策略没有要求。可以指定哪些编号的槽分配给哪个主节点。集群会记录节点和槽的对应关系。

解决了节点和槽的关系后,接下来就需要对key求哈希值,然后对16384取余,余数是几key就落入对应的槽里。

slot = CRC16(key) % 16384。以槽为单位移动数据,因为槽的数目是固定的,处理起来比较容易,这样数据移动问题就解决了。

4.1.3.2 哈希槽计算

Redis 集群中内置了 16384 个哈希槽,redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。

当需要在 Redis 集群中放置一个 key-value时,redis 先对 key 使用 crc16 算法算出一个结果,然后把结果对 16384 求余数,这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽,也就是映射到某个节点上。

在这里插入图片描述

如下代码,key之A 、B在Node2, key之C落在Node3上

@Test
public void test(){
    System.out.println(SlotHash.getSlot("A"));
    System.out.println(SlotHash.getSlot("B"));
    System.out.println(SlotHash.getSlot("C"));
    System.out.println(SlotHash.getSlot("Hello"));
}

4.2 开始部署

  1. 关闭防火墙,开启docker服务
  1. 确保存在一个redis镜像(我这里使用redis6.0.9版本)

docker images

如果没有redis镜像

可以 docker pull redis:6.0.9 redis镜像

4.2.1 创建6个docker容器redis实例

docker run -d --name redis-node-1 --net host --privileged=true -v /mydata/redis/redis-node-1:/data redis:6.0.9 --cluster-enabled yes --appendonly yes --port 6381

docker run -d --name redis-node-2 --net host --privileged=true -v /mydata/redis/redis-node-2:/data redis:6.0.9 --cluster-enabled yes --appendonly yes --port 6382

docker run -d --name redis-node-3 --net host --privileged=true -v /mydata/redis/redis-node-3:/data redis:6.0.9 --cluster-enabled yes --appendonly yes --port 6383

docker run -d --name redis-node-4 --net host --privileged=true -v /mydata/redis/redis-node-4:/data redis:6.0.9 --cluster-enabled yes --appendonly yes --port 6384

docker run -d --name redis-node-5 --net host --privileged=true -v /mydata/redis/redis-node-5:/data redis:6.0.9 --cluster-enabled yes --appendonly yes --port 6385

docker run -d --name redis-node-6 --net host --privileged=true -v /mydata/redis/redis-node-6:/data redis:6.0.9 --cluster-enabled yes --appendonly yes --port 6386

最后启动成功后,docker ps 可以看到启动了6个实例

在这里插入图片描述

命令解析:

  • docker run:创建并运行docker容器实例
  • –name redis-node-# :容器名称
  • –net host :使用宿主机的IP和端口(默认)
  • –privileged=true :获取宿主机root用户权限
  • -v /mydata/redis/redis-node-#:/data :容器卷,宿主机地址:docker内部地址
  • reds:6.0.9 :redis镜像和版本号
  • –cluster-enabled yes :开启redis集群
  • –appendonly yes :开启持久化
  • –port 638# :redis端口号

4.2.2 构建主从关系

进入各个redis容器内部确立主从关系

docker exec -it redis-node-1 /bin/bash

这里代码只是做个示范,请根据自己的部署自行修改进入的容器

redis-cli --cluster create 192.168.81.102:6381 192.168.81.102:6382 192.168.81.102:6383 192.168.81.102:6384 192.168.81.102:6385 192.168.81.102:6386 --cluster-replicas 1

这里一样需要根据你自己的IP地址来更改

要求:每一个 IP:端口 地址都必须能通信!

在这里插入图片描述

当出现OK选项时,就代表集群配置完毕

4.2.3 查看阶段状态

进入Redis:6381容器,查看节点状态

cluster info

在这里插入图片描述

cluster nodes

在这里插入图片描述

4.3 主从容错切换迁移案例

4.3.1 数据读写存储

对redis:6381新增两个key

redis-cli -p 6381 -c

这里防止路由失效,最好加上 -c 参数

在这里插入图片描述

set k1 6381node-set1
set k2 6381node-set2

查看集群信息

redis-cli --cluster check 192.168.81.102:6381

在这里插入图片描述

4.3.2 容错切换迁移

名字高大上,其实操作很简单

我们只需要将master节点停掉,然后redis会自动将某一台slave节点上位,这台上位的slave节点就会变成master节点

我这里先将redis:6381容器停掉(因为redis:6381容器在集群中所代表的就是master节点),这里就模拟redis集群中某一节点宕机

docker stop redis-node-1

此时我们可以进入节点2去看看集群节点的状态

docker exec -it redis-node-2 /bin/bash
redis-cli -p 6382 -c
cluster nodes

在这里插入图片描述

这里可以看到

  • 6381节点 master 处于fail的状态
  • 6382节点 myself,master 处于connected
  • 6386节点 master 处于connected

可以看到6386节点上位为了master

4.3.3 还原三主三从状态

重新启动 redis:6381 节点即可

docker start redis-node-1

再次查看集群信息

在这里插入图片描述

可以看到

  • 6381 节点从原来的master,变成了slave
  • 而6386节点依旧时master

这就完成了一次主从切换

4.4主从扩容

目标:

  • 集群内新增6387、6388两个节点

4.4.1 加入集群

首先docker启动两个redis实例

docker run -d --name redis-node-7 --net host --privileged=true -v /mydata/redis/redis-node-7:/data redis:6.0.9 --cluster-enabled yes --appendonly yes --port 6387

docker run -d --name redis-node-8 --net host --privileged=true -v /mydata/redis/redis-node-8:/data redis:6.0.9 --cluster-enabled yes --appendonly yes --port 6388

进入redis:6387容器

docker exec -it redis-node-7 /bin/bsah

将新增的6387节点作为master节点加入原集群

redis-cli --cluster add-node 192.168.81.102:6387 192.168.81.102:6381

为什么后面要跟上集群内的一个master节点呢?

其实就是将 节点 加入到 目标节点所在的集群中

在这里插入图片描述

4.4.2 分配槽号

我们刚加入集群的节点,都是没有槽号的,没有槽号redis就无法进行操作

检查一次集群即可看到

redis-cli --cluster check 192.168.81.102:6381

在这里插入图片描述

看到6387节点没有槽号,所以我们还需要为新加的节点分配槽号

redis-cli --cluster reshard 192.168.81.102:6381

在这里插入图片描述

这里作几个解释,在分配槽号时,redis还会询问你几个事项

  1. How many slots do you want to move (from 1 to 16384)?

    • 这里我们一般是根据槽号总数也就是(from 1 to 16384) 中的16384这个数除以集群中master节点的个数,最后填这个计算出来的值
    • 16384/master节点个数;我这里是4台,所以是 16384/4=4096
    • 结果我填写的值就是 4096
  2. What is the receiving node ID?

    • 这个就是问你给哪个master节点重新分配,我们只需要填写对应节点的ID即可

    • ID就是

      S: c1a241ddce7d05b78c9ada979d63fde3941ae3bd 192.168.81.102:6381
      slots: (0 slots) slave
      replicates 407e0fe0c147a5980a4170898c838cbd8663343d
      M: 507022d2847ed74411650c40239f72caca496aa7 192.168.81.102:6387
      slots: (0 slots) master
      M: 9de1fa66a4fe8a93cd19e641f07ad7be8c5c07d4 192.168.81.102:6382
      slots:[5461-10922] (5462 slots) master
      1 additional replica(s)
      M: 407e0fe0c147a5980a4170898c838cbd8663343d 192.168.81.102:6386
      slots:[0-5460] (5461 slots) master
      1 additional replica(s)
      M: a319210051e861e6556b532301d967a2bf1d0973 192.168.81.102:6383
      slots:[10923-16383] (5461 slots) master
      1 additional replica(s)
      S: 0e10a1470ab9b6096d1be5ca5b44c64b544b6cd0 192.168.81.102:6385
      slots: (0 slots) slave
      replicates a319210051e861e6556b532301d967a2bf1d0973
      S: 51239244d466779d6f3e0e7f85bb09fbfc8142a7 192.168.81.102:6384
      slots: (0 slots) slave
      replicates 9de1fa66a4fe8a93cd19e641f07ad7be8c5c07d4

      这串信息中的前面一段字符,例如M: 507022d2847ed74411650c40239f72caca496aa7 192.168.81.102:6387 slots: (0 slots) master

      那么就是 507022d2847ed74411650c40239f72caca496aa7 这一串ID

  3. Source node #1:

    • 一般填写 all

分配完成后,我们再检查一次集群状态

redis-cli --cluster check 192.168.81.102:6381

在这里插入图片描述

能够看到6387节点已有槽号

为什么6387是3个新的区间,以前的还是连续?

重新分配成本太高,所以前3家各自匀出来一部分,从6381/6382/6383三个旧节点分别匀出1364个坑位给新节点6387

4.4.3 为主节点6387分配从节点6388

命令:

redis-cli --cluster add-node ip:新slave端口 ip:新master端口 --cluster-slave --cluster-master-id 新主机节点ID

自己根据实际情况来更改

我这里就是这样子的

redis-cli --cluster add-node 192.168.81.102:6388 192.168.81.102:6387 --cluster-slave --cluster-master-id 507022d2847ed74411650c40239f72caca496aa7 

再次检查集群

redis-cli --cluster check 192.168.81.102:6381

在这里插入图片描述

4.5 主从缩容

主从缩容就不演示了

目的就是将6387和6388下线

缩容的整体思路和扩容思路就是完全相反的

  1. 先删除从节点6388
  2. 然后将6387主节点的槽号清空
  3. 重新分配集群槽号
    • 再分配槽号时,多出来的槽号可以分配其他主节点
  4. 最后将6387主节点删除

5. ❤️Docker专栏 - 前篇回顾

6. 💕👉 其他好文推荐

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值