master

前面大家介绍了主从、主主复制以及他们的中间件mysql-proxy的使用，这一篇给大家介绍的是keepalived的搭建与使用！ 一、keepalived简介 1.1、keepalived介绍 　　　　Keepalived起初是为LVS设计的， 专门用来监控集群系统中各个服务节点的状态 ，它根据TCP/IP参考模型的第三、第四层、第五层交换机制检测每个服务节点的状态， 如果某个服务器节点出现异常， 　　或者工作出现故障，Keepalived将检测到，并将出现的故障的服务器节点从集群系统中剔除， 这些工作全部是自动完成的，不需要人工干涉，需要人工完成的只是修复出现故障的服务节点。 　　　　后来Keepalived又加入了VRRP的功能，VRRP（Vritrual Router Redundancy Protocol,虚拟路由冗余协议)出现的目的是解决静态路由出现的单点故障问题，通过VRRP可以实现网络不间断稳定运行， 　　因此Keepalvied 一方面具有服务器状态检测和故障隔离功能，另外一方面也有HA cluster功能，下面介绍一下VRRP协议实现的过程。 1.2、VRRP协议与工作原理 　　　　在现实的网络环境中。 主机之间的通信都是通过配置静态路由或者(默认网关)来完成的，而主机之间的路由器一旦发生故障，通信就会失效 ，因此这种通信模式当中，路由器就成了一个单点瓶颈

了解缓存穿透、缓存雪崩、缓存击穿以及解决方案 分布式锁一般有三种实现方式：1. 数据库乐观锁；2. 基于Redis的分布式锁；3. 基于ZooKeeper的分布式锁 1、如何保证Redis高可用和高并发? Redis主从架构，一主多从，可以满足高可用和高并发。出现实例宕机自动进行主备切换，配置读写分离缓解Master读写压力。 2、Redis高可用方案具体怎么实施？ 使用官方推荐的哨兵(sentinel)机制就能实现，当主节点出现故障时，由Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。它有四个主要功能： 集群监控，负责监控redis master和slave进程是否正常工作。 消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员。 故障转移，如果master node挂掉了，会自动转移到slave node上。 配置中心，如果故障转移发生了，通知client客户端新的master地址。 3、你能说说Redis哨兵机制的原理吗？ 通过sentinel模式启动redis后，自动监控master/slave的运行状态，基本原理是：心跳机制+投票裁决。每个sentinel会向其它sentinal、master、slave定时发送消息，以确认对方是否活着，如果发现对方在指定时间内未回应，则暂时认为对方宕机

22.5/22.6 单机上使用git 22.7 建立远程仓库 22.8 克隆远程仓库 22.9 分支管理 一、单机上使用git yum install -y git mkdir /data/gitroot cd /data/gitroot git init //初始化仓库 echo -e “123\naaa\n456\nbbb” > 1.txt //创建一个新文件 git add 1.txt//把1.txt添加到仓库 git commit -m “add new file 1.txt” //add完了必须要commit才算真正把文件提交到git仓库里 再次更改1.txt git status //查看当前仓库中的状态，比如是否有改动的文件 git diff 1.txt //可以对比1.txt本次修改了什么内容，相比较仓库里面的版本 版本回退 多更改几次1.txt，然后add,commit git log//查看所有提交记录 git log --pretty=oneline//一行显示 git reset --hard f7c8e9//回退版本，其中后面跟的字符串是简写 撤销修改 rm -f 1.txt//不小心删除了1.txt git checkout – 1.txt//恢复1.txt 如果1.txt文件修改，add后但没有commit，再想回退到上一次提交的状态，可以使用git

一．体系架构 在Keepalived + Nginx高可用负载均衡架构中，keepalived负责实现High-availability (HA) 功能控制前端机VIP（虚拟网络地址），当有设备发生故障时，热备服务器可以瞬间将VIP自动切换过来，实际运行中体验只有2秒钟切换时间，DNS服务可以负责前端VIP的负载均衡。 nginx负责控制后端web服务器的负载均衡，将客户端的请求按照一定的算法转发给后端Real Server处理，而Real Server将响应直接返回给客户端。 nfs服务器做实时备份，给web服务器提供web界面。 二．简单原理 NGINX_MASTER、NGINX_BACKUP两台服务器均通过keepalived软件把ens33网卡绑上一个虚拟IP（VIP）地址192.168.1.40，此VIP当前由谁承载着服务就绑定在谁的ens32上，当NGINX_MASTER发生故障时，NGINX_BACKUP会通过/etc/keepalived/keepalived.conf文件中设置的心跳时间advert_int 1检查，无法获取NGINX_MASTER正常状态的话，NGINX_BACKUP会瞬间绑定VIP来接替nginx_master的工作，当NGINX_MASTER恢复后keepalived会通过priority参数判断优先权将虚拟VIP地址192.168.1

一，Keepalived高可用软件 　　1，Keepalived介绍 　　1.1 Keepalived软件起初是专门为LVS负载均衡软件设计的，用来管理并监控LVS集群系统中各个服务节点的状态，后来又加入了可以实现高可用的VRRP功能。 　　1.2 Keepalived软件主要是通过VRRP协议实现高可用功能的。 　　2，Keepalived服务三个重要功能 　　　　2.1 管理 LVS负载均衡软件 　　　　2.2 实现对 LVS集群节点健康检查功能（ healthcheck） 　　　　2.3 作为系统网络服务的高可用功能（ failover） 　　3，Keepalived高可用故障切换原理 　　　　3.1 Keepalived高可用服务之间的故障切换转移，是通过VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议）来实现的。 　　　　3.2 在Keepalived服务正常工作时，主Master节点会不断地向备节点发送（多播的方式）心跳消息，用以告诉备Backup节点自己还活着，当主Master节点发生故障时，就无法发送心跳消息，备节点也就因此无法继续检测到来自主Master节点的心跳了，于是调用自身的接管程序，接管主Master节点的IP资源及服务。而当主Master节点恢复时

环境说明： 主机名 操作系统版本 ip docker version kubelet version 备注 master Centos 7.6.1810 172.27.9.131 Docker 18.09.6 V1.14.2 master主机 node01 Centos 7.6.1810 172.27.9.135 Docker 18.09.6 V1.14.2 node节点 node02 Centos 7.6.1810 172.27.9.136 Docker 18.09.6 V1.14.2 node节点 k8s集群部署详见： Centos7.6部署k8s(v1.14.2)集群 k8s学习资料详见： 基本概念、kubectl命令和资料分享 一、 pod简介 1. pod概览 Pod是kubernetes中你可以创建和部署的最小也是最简单位。一个Pod代表着集群中运行的一个进程。 Pod中封装着应用的容器（有的情况下是好几个容器），存储、独立的网络IP，管理容器如何运行的策略选项。Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源 在Kubrenetes集群中Pod有如下两种使用方式： 一个Pod中运行一个容器。“每个Pod中一个容器”的模式是最常见的用法：在这种使用方式中，你可以把Pod想象成是单个容器的封装

通过Kubeadm只需几条命令即起一个单机版kubernetes集群系统，而后快速上手k8s。 在kubeadm中，需手动安装Docker和kubeket服务，Docker运行容器引擎，kubelet是启动Pod的核心组件，每一个节点都安装好kubelet和Docker，那么运行容器和Pod的环境就准备好了，在此基础之上，使用Kubeadm工具自动配置kubelet并启动kubelet服务，将Master所有组件和Node上剩余的kube-proxy组件都运行为Pod，托管在k8s之上。 服务器规划 三台机器：一台master、两个Node： k8s-master：10.3.1.20 k8s-node01：10.3.1.21 k8s-node02：10.3.1.25 OS：Ubuntu16.04 Docker：17.03.2-ce 安装前准备 1、master节点到各Node节点SSH免密登录。 2、时间同步。 3、各Node必须关闭swap：swapoff -a，否则kubelet启动失败。 4、各节点主机名和IP加入/etc/hosts解析 安装Docker 所有k8s节点安装Docker Daemon： apt-get update apt-get install \ apt-transport-https \ ca-certificates \ curl \

系列目录 kubernetes简介 Kubernetes节点架构图： kubernetes组件架构图： 准备基础环境 我们将使用kubeadm部署3个节点的 Kubernetes Cluster，整体结构图： 节点详细信息： 无特殊说明以下操作在所有节点执行： 修改主机名： #master节点: hostnamectl set-hostname k8s-master #node1节点： hostnamectl set-hostname k8s-node1 #node2节点: hostnamectl set-hostname k8s-node2 基本配置： #修改/etc/hosts文件 cat >> /etc/hosts << EOF 192.168.92.56 k8s-master 192.168.92.57 k8s-node1 192.168.92.58 k8s-node2 EOF #关闭防火墙和selinux systemctl stop firewalld && systemctl disable firewalld sed -i 's/^SELINUX=enforcing$/SELINUX=disabled/' /etc/selinux/config && setenforce 0 #关闭swap swapoff -a yes | cp /etc/fstab /etc

MHA高可用群集基本部署 MHA概述 MHA目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton(现就职于Facebook公司)开发。 MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 MHA还提供在线主库切换的功能，能够安全地切换当前运行的主库到一个新的主库中(通过将从库提升为主库),大概0.5-2秒内即可完成。 基本部署实验流程 一、实验前期准备 名称 角色 地址 centos7-2 master 192.168.142.203 centos7-3 slave1 192.168.142.132 centos7-min slave2 192.168.142.172 centos7-4 manger（监控端） 192.168.142.136 二、开始实验 1、所有服务器环境准备 安装epel源（不进行检查） [root@manger ~]# yum -y install epel-release --nogpgcheck 安装环境包 [root@manger ~]# yum -y install \ perl-DBD-MySQL \ perl-Config

MFS分布式文件系统 mfs工作原理 分布式原理 分布式文件系统就是把一些分散在多台计算机上的共享文件夹，集合到一个共享文件夹内，用户要访问这些文件夹的时候，只要打开一个文件夹，就可以的看到所有链接到此文件夹内的共享文件夹。 MFS原理 MFS是一个具有容错性的网络分布式文件系统，它把数据分散存放在多个物理服务器上，而呈现给用户的则是一个统一的资源。 MFS的组成 元数据服务器（Master）：在整个体系中负责管理文件系统，维护元数据，目前不支持高可用。 元数据日志服务器（MetaLogger）：备份Master服务器的变化日志文件，当master服务器损坏，可以从日志服务器中取得文件恢复。 数据存储服务器（Chunk Server）：真正存储数据的服务器，服务器越多，容量就越大，可靠性越高，性能越好。 客户端（Client）： 可以像挂载NFS一样 挂载MFS文件系统 MFS读数据的处理过程 - 客户端向元数据服务器发出读请求 - 元数据服务器把所需数据存放的位置（Chunk Server的IP地址和Chunk编号）告知客户端 - 客户端向已知的Chunk Server请求发送数据 - Chunk Server向客户端发送数据 写入的过程 - 客户端向元数据服务器发送写入请求 - 元数据服务器与Chunk Server进行交互，但元数据服务器只在某些服务器创建新的分块Chunks