docker安装redis提示没有日记写入权限_Docker部署Redis集群----第五节（docker-redis集群主从复制【下】实践篇）...

今天我们继续来讲docker部署redis集群的下篇也是主从复制的最后一篇，本篇文章所讲的内容是建立在上节课
的理论基础之上。
经过上节课的一些知识点的介绍，我们了主要解到了“数据延迟”、“配置不一致”、“如何规避全量复制的复制风暴”
三个问题，所以本章篇幅就给大家用命令的形式来演示这些问题出现的结果。

在讲本节课之前，我们先来熟悉并使用下docker的指令并使用COPY和ADD，还记的我们的第三节篇章的Dockerfile文件的使用吧，不记得了自己去翻下吧，这里我们对之前的Dockerfile做个修改，具体看下实例指令代码：

第三节的Dockerfile基础上进行添加修改 
在EXPOSE 6379 之前加几个Dokcer指令：
......
RUN mkdir -p /config && 
chown -R redis:redis /config
#在容器中创建config目录，并改变config的用户和用户组
COPY ./docker/config/redis-master.conf /config
#把redis-master.conf文件拷贝到当前容器的config目录中
ADD ./docker/config/redis-slave.conf /config
#ADD与COPY一样都是具有拷贝的功能，具体两者的差异自己去查下第二节篇幅的内容吧
VOLUME /usr/docker/redis/config
#把外部的config挂载到容器里，达成文件的共享
WORKDIR /config
#定义容器的工作目录
EXPOSE 6379

我们再看下Dockerfile的文件文件信息：

再看下目录结构：

/usr/docker/redis目录：

/usr/docker/redis/config目录：

希望大家自己动手写，如果需要包的话在评论区给我留言。

然后我们要删除之前的镜像和容器：

[root@instance-rttngj1u docker]# docker stop $(docker ps -a) //停止所有容器
[root@instance-rttngj1u docker]# docker rm $(docker ps -a) //删除所有容器
[root@instance-rttngj1u docker]# docker rmi redis //删除镜像
注意：我们要先删除容器，否则先删除镜像是删不掉的，前面第一节我就给大家讲了，docker的存储是分层存储，
因为这里有镜像才会有容器的概念。所以要先清除容器的进程后才能删除镜像。
//开始构建我们新的redis镜像：
[root@instance-rttngj1u redis]# docker build --no-cache -t redis . //--no-cache:意思是不从缓存里构建我们的镜像  具体的参数可以用docker build --help
[root@instance-rttngj1u redis]# docker images -a //查看下redis镜像是否构建成功。
然后开始构建容器搭建一主三从的redis集群，架构和第三节篇章一样的。这里就不再啰嗦了。

补充：执行构建镜像命令 我们能很清楚地看到Dokcerfile文件执行项：

执行下面的图解命令查看我们的容器：那就恭喜你构建成功。

然后我们再启动主节点Master时看下图：

我们这里自动切换到工作目录config目录下，这样相信大家应该清楚今天所讲的几dockerfile指令了吧。同时我们也不难发现与前面配置的主从集群的工作目录明显不一样了，这就是docker指令的魅力和他的功能之初，其他的命令在后面的章节中再细说。

下面我们开始配置从slave:

分别进入到从节点redis客户端配置主Master主节点
127.0.0.1:6379> SLAVEOF 172.60.0.2 6379

配置好所有主从节点的配置后 在Master节点的客户端输入下面的命令我们可以看到：

我们可以看到每个从节点的offset与我们的主节点maste的master_rep_offset的值是一样的说明我们的从节点同步主节点的数据是一致，当然如果存在网络延迟的话 数据同步就会有所差异，接下来我们就综合前面上一节篇章的内容开始实践。

开始实践我们的主题：

上节课我们也讲到了这个问题存在的非常可能性，因为网络谁都无法控制住的，很简单的一个例子就是本来读的动作再写的动作之后才执行的，结果读出来的数据却未发现刚刚写的数据，这就是非常标准的数据延迟问题。下面我们将通过因为网络的问题导致复制数据延迟的问题。

我们这里是做模拟没事不要在生成环境中随便尝试：因为这种延迟的网络，就像我们在访问国外的网站一样，其数据结果可想而知，所以切记了不要在生产环境上运行测试，不信的话，可以试试，相信你们老板是个好脾气。

进行自己的云服务器Master主节点开启执行以下命令来安装这个扩展：linux控流命令
进入节点命令还记得吗？？？？？不记得抽自己两个巴掌先
进入到从节点redis-slave6
[root@instance-rttngj1u ~]# docker exec -it redis-slave6 bash
[root@90e5a51dda7f config]# yum install iproute
配置延迟5秒
[root@90e5a51dda7f config]# tc  qdisc  add   dev  eth0  root  netem  delay 5000ms
执行命令后会如果你没有操作权限会提示你
RTNETLINK answers: Operation not permitted
这个时候我们就要用到上节课所讲的 参数命令--privileged强制性来加权限
[root@instance-rttngj1u ~]# docker run --privileged -itd --name  redis-slave6   --net mynetwork  -p  6386:6379  --ip 172.60.0.6  redis
再进入到这个redis-slave6的容器内
还记得上节课我们新建的shell脚本吗？

然后我们开始运行这个脚本
[root@ddc54ca0cfed /]# sh redis.sh 
这个时候我稍微静等一会儿
运行完毕后，我们进入到主节点执行info relication命令来查看

由此我们很清楚的看到从节点redis-slave6的offset偏移量明显要低于其他三个节点。

本章节我们实践了主从复制的延迟。针对上节课的解决方案，因为有时候主节点Master可能会因为网络或者其他不可抗拒的因素挂掉，导致无法使用的情况，写入的功能就会失效。所以该怎么解决呢？我们总不能手动去修复吧？这也不现实。

下节篇章，我们就开始新的集群，redis-sentinel哨兵集群来解决主节点挂掉了解决方案。

请大家关注，有问题可以在评论中追加提问。关注我和我的专栏，后面的内容会更加精彩。