keepalived

今天星期天，么事就写个MYSQL的主主架构的博客，原理如下图，不是我画的网上找的。 主机作用 操作系统 mysql版本 对应IP vip数据库 mysqlA(主) centos6.4 mysql 5.5.48 192.168.48.129 192.168.48.126 mysqlB(备) centos6.4 mysql 5.5.48 192.168.48.132 一： 在每个节点安装mysql数据库： 《1》到官网去下载最新的yum仓库，并安装 http://dev.mysql.com/downloads/repo/yum/ yum install mysql-community-server 《2》用第三方yum 1、导入第三方源webtatic rpm -Uvh http://repo.webtatic.com/yum/el6/latest.rpm 2、如果已安装低版本的mysql就删除 yum remove mysql mysql-* 3、安装libmysqlclient15 yum install libmysqlclient15 --enablerepo=webtatic 4、安装mysql5.5 yum install mysql55 mysql55-server --enablerepo=webtatic 《3》安装MariaDB 我这里用的这安装的 1、vi

注：本文基于 MySQL高可用之MHA 配置VIP vip配置可以采用两种方式： 1、通过keepalived的方式管理虚拟ip的浮动； 2、通过脚本方式启动虚拟ip 的方式（即不需要keepalived或者heartbeat类似的软件） 1、keepalived方式管理虚拟ip #在编译安装 Keepalived之前，必须先安装内核开发包kernel-devel以及openssl-devel、popt-devel等支持库 [root@master ~]# yum -y install kernel-devel popt-devel openssl-devel #在两台master上进行安装 [root@master ~]# wget https://www.keepalived.org/software/keepalived-2.1.3.tar.gz [root@master ~]# tar zxf keepalived-2.1.3.tar.gz [root@master ~]# cd keepalived-2.1.3/ [root@master keepalived-2.1.3]# ./configure --prefix=/ && make && make install #修改配置文件 [root@master ~]# vim /etc/keepalived

1、Keepalived软件前期用来管理并监控LVS集群系统中各个服务节点的状态； 2、后期加入了实现高可用的VRRP功能。因此可以为lvs负载均衡提供高可用功能，也可以为其他服务提供高可用。。 实验镜像：Centos 8.1.1911 草图：（待补） 1、两个real server 安装配置 在keepalived Master上测试无问题。 [root@HA1 ~]# curl http: //192.168.94.140 this is real 1 server [root@HA1 ~]# curl http: //192.168.94.141 this is real 2 server [root@HA1 ~]# 2、安装keepalived、ipvsadm yum install ipvsadm keepalived -y 使用keepalived即可完成real server的添加。 配置文件在/etc/keepalived下 [root@HA1 keepalived]# pwd /etc/keepalived [root@HA1 keepalived]# ls keepalived.conf [root@HA1 keepalived]# cp keepalived.conf keepalived.conf.bak [root@HA1 keepalived]#

　互联网公司里面几乎很少有公司不用MySQL，国内互联网巨头都在大规模使用MySQL。如果把MySQL比喻成数据库界的一条巨龙，则性能优化和高可用架构设计实践就是点睛之笔。 　　《MySQL性能优化和高可用架构实践》将详细讲解MySQL5.7高可用和性能优化技术，细致梳理思路，并与真实生产案例相结合，通过原理阐述到实战部署，帮助读者将所学知识点运用到实际工作中。 本书作者目前是在腾讯云担任架构师，之前服务于微软公司，业界大咖联袂推荐。 　　《MySQL性能优化和高可用架构实践》分为13章，详解MySQL5.7数据库体系结构，InnoDB存储引擎，MySQL事务和锁，性能优化，服务器全面优化、性能监控，以及MySQL主从复制、PXC、MHA、MGR、Keepalived+双主复制等高可用集群架构的设计与实践过程，并介绍海量数据分库分表和Mycat中间件的实战操作。 　　《MySQL性能优化和高可用架构实践》既适合有一定基础的MySQL数据库学习者、MySQL数据库开发人员和MySQL数据库管理人员阅读，同时也能作为高等院校和培训学校相关专业师生的参考用书。 mysql性能优化和高可用架构实战— 资源下载地址 链接： https://pan.baidu.com/s/1rTb07Q4rALt5PEkB60aVGQ 提取码：p1yg 京东购买链接： https://item.jd.com

为什么使用keepalived呢？ 在服务器集群情况下，会用到lvs或者nginx做调度，如果调度器是单台设备就会出现单点故障的问题。 也就是说，当单台调度器故障，无法完成调度，造成站点无法提供服务。 所以为了避免这样的情况，一般调度器会使用多台做高可用。而keepalived就是在这方面的典型代表。 keepalived的底层功能是vrrp协议 vrrp叫做虚拟路由冗余协议，在路由器、三层交换机上使用广泛，如思科、华为的路由器产品一般都会支持vrrp协议。 当然思科有自己的类似vrrp协议叫做hsrp，其功能都是一样的。 vrrp由以下几个部分组成 真实路由器：即物理设备； 虚拟路由器：由两台或者多台物理机器组成，具有相同的VRID的物理机器即认为在同一个虚拟路由器组中； VIP：虚拟路由器的ip地址，也是多个物理主机公用的ip地址； VMAC：虚拟mac地址，默认是00-00-5e-00-01-VRID； MASTER：多台物理机器组成逻辑上的一台虚拟路由器，其中只有一台机器是能够转发数据的这台机器就是MASTER。我们称为主设备； BACKUP：其他机器就是BACKUP起备份作用，我们称为备设备； priority：区分master和backup的决定参数就是优先级，默认优先级是100，而且值越大越优先； 通告： 主设备与备设备是通过协商优先级来决定的，而且是周期性检查优先级

Ansible-实战指南-LNMP环境部署，并使用zabbix监控 主机规划 系统初始化：必要的系统初始化 基础组件包括：zabbix监控，mariadb（用于存放zabbix监控信息） 业务组件包括：MySQL、memcached、nginx、PHP、haproxy、keepalived 添加用户账号 说明： 1、 运维人员使用的登录账号； 2、 所有的业务都放在 /app/ 下「yun用户的家目录」，避免业务数据乱放； 3、 该用户也被 ansible 使用，因为几乎所有的生产环境都是禁止 root 远程登录的（因此该 yun 用户也进行了 sudo 提权）。 1 # 使用一个专门的用户，避免直接使用root用户 2 # 添加用户、指定家目录并指定用户密码 3 # sudo提权 4 # 让其它普通用户可以进入该目录查看信息 5 useradd -u 1050 -d /app yun && echo ' 123456 ' | /usr/bin/ passwd -- stdin yun 6 echo " yun ALL=(ALL) NOPASSWD: ALL " >> /etc/ sudoers 7 chmod 755 /app/ 备注：记得在管理机 172.16.1.180 上实现对其他机器的免密登录。 Ansible 配置清单Inventory 1 [yun@ansi

最近工作中的一个问题，耗时一个月之久终于调查完毕且顺利解决，顿时感慨万千。耗时之久和预期解决时间和环境搭建以及日志不合理等等有关，当然这个并非此文的重点。 之所以在很久以后的今天又开始写文，主要是这个问题调查的过程值得铭记。具体情况如下文述。 一、问题发现过程 数据告警服务提示相关分析结果缺失，经初步调查，发现分析服务在调用对应的NLP算法服务时出现大量Failed，遂查看算法日志，确实存在错误信息。 二、问题调查和解决 1.定位问题 1) 反馈给算法相关开发同学：他们认为可能是该算法遇到了长文本数据（超过3000字），由于分析时间超长，导致后续算法请求时出现阻塞而导致failed。 2) 根据开发的反馈，开始定位是否存在这样的长文本数据：通过分析日志和数据库查询确认后，并没有分析长文本数据，且出现异常时的文本数据均为短文本（小于200）。 3) 深入调查：该算法部署了多个节点，出现异常时，多个节点均出现了异常，因此可能是算法本身遇到了某个瓶颈问题。经确认，该算法使用了同一台GPU服务器上的tf-serveing服务。 4) 确认GPU服务器是否发生了异常情况：经确认，该服务器进行过VIP漂移操作。 5) 问题是否可以复现：测试环境中，对GPU服务器进行vip漂移操作，发现错误现象出现，问题可复现。 因此，问题的起因是GPU服务器进行了VIP漂移操作，导致算法出现异常。 2

基于keepalived配置数据库主从实现高可用 使用keepalived来监听端口，实现数据库的高可用。实现效果，其中一台数据库服务器突然出故障或关机时，应该不影响应用正常运行，等待服务器启动之后，数据能够自动同步，保持数据一致性。 主从配置 架构图及原理 主从状态下，必须保证业务数据实际写入Master数据库，Slave数据库只承担读的作用； Master 数据库只要发生变化，立马记录到Binary log日志文件中； Slave数据库启动一个I/O thread连接Master数据库，请求Master变化的二进制日志； Slave I/O获取到的二进制日志，保存到自己的Relay log 日志文件中； Slave 有一个 SQL thread定时检查Realy log是否变化，变化那么就更新数据。 数据库资源 数据库 数据库IP 节点 Gbase1 192.168.0.52 Master Gbase2 192.168.0.53 Slave 配置步骤 主master配置 修改配置文件，添加以下内容（gs.cnf） server-id=1 log-bin=gbase-log #开启binlog日志 binlog_fromat=row 重启数据库 2. 重启数据库并登陆数据库 #创建同步用的账号 set SQL_LOG_BIN=0; CREATE USER 'save'@'%'

【1107】keepalive高可用集群 18.1 集群介绍 18.2 keepalived 介绍 18.3/18.4/18.5 用 keepalived 配置高可用集群 18.1 集群介绍 根据功能划分为两大类：高可用和负载均衡 高可用集群通常为两台服务器，一台工作，另外一台作为冗余，当提供服务的机器宕机，冗余将接替继续提供服务 实现高可用的开源软件有：heartbeat、keepalived 负载均衡集群，需要有一台服务器作为分发器，它负责把用户的请求分发给后端的服务器处理，在这个集群里，除了分发器外，就是给用户提供服务的服务器了，这些服务器数量至少为2 实现负载均衡的开源软件有 LVS、keepalived、haproxy、nginx，商业的有 F5、Netscaler 18.2 keepalived 介绍 在这里我们使用 keepalived 来实现高可用集群，因为 heartbeat 在 centos6 上有一些问题 ，比如通信不顺畅 ，影响实验效果 。 keepalived通过 VRRP（Virtual Router Redundancy Protocl）虚拟路由冗余协议 ， 来实现高可用。 在这个协议里会将多台功能相同的路由器组成一个小组，这个小组里会有1个 master 角色和N（N>=1）个backup角色。 master 会通过组播的形式向各个 backup

高可用简介 kubernetes高可用部署参考： https://kubernetes.io/docs/setup/independent/high-availability/ https://github.com/kubernetes-sigs/kubespray https://github.com/wise2c-devops/breeze https://github.com/cookeem/kubeadm-ha 拓扑选择 配置高可用（HA）Kubernetes集群，有以下两种可选的etcd拓扑： 集群master节点与etcd节点共存，etcd也运行在控制平面节点上 使用外部etcd节点，etcd节点与master在不同节点上运行 堆叠的etcd拓扑 堆叠HA集群是这样的拓扑，其中etcd提供的分布式数据存储集群与由kubeamd管理的运行master组件的集群节点堆叠部署。 每个master节点运行kube-apiserver，kube-scheduler和kube-controller-manager的一个实例。kube-apiserver使用负载平衡器暴露给工作节点。 每个master节点创建一个本地etcd成员，该etcd成员仅与本节点kube-apiserver通信。这同样适用于本地kube-controller-manager 和kube-scheduler实例