drbd

NFS HA架构部署(NFS + Pacemaker + Corosync + DRBD) 环境：kvm虚拟机2台 OS：CentOS7.6 Kernel: Linux 3.10.0-957.21.3.el7.x86_64 IP地址     主机名 192.9.200.25 centos7v6a    节点一 192.9.200.26 centos7v6b    节点二 两台服务器上都有一个大小相同的硬盘 /dev/vdb 1、安装DRBD （Distributed Replicated Block Device，分布式复制块设备） 从官方下载源码： # curl -O https: //www.linbit.com/downloads/drbd/9.0/drbd-9.0.18-1.tar.gz\\\ # curl -O https: //www.linbit.com/downloads/drbd/utils/drbd-utils-9.10.0.tar.gz 解压，编译，安装 # tar drbd-utils- 9.10.0. tar . gz # cd drbd-utils- 9.10.0 / # yum -y install flex po4a # ./configure --prefix=/opt/drbd-utils --without-83support -

基于DRBD实现数据库高可用 金融行业对数据的一致性要求较高，比较当前主流的高可用架构，选择了DRBD，通过使用COROSYNC来提供集群信息以及状态监测，PACEMAKER负责故障转移以及资源的启动停止和监控，在PRIMARY出现问题的时候，通过PACEMAKER控制VIP迁移来实现高可用，使用KEEPALIVED来避免HAPROXY服务器的单点故障。 详细解读 和小伙伴们一起来吐槽 来源： oschina 链接： https://my.oschina.net/u/856019/blog/273787

点击上方“ 程序员小灰 ”，选择“置顶公众号” 有趣有内涵的文章第一时间送达！ 本文转载自公众号 民工哥Linux运维 前言 高可用架构对于互联网服务基本是标配，无论是应用服务还是数据库服务都需要做到高可用。对于一个系统而言，可能包含很多模块，比如前端应用，缓存，数据库，搜索，消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用可能更复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此数据库的高可用方案是一直以来的讨论热点，今天就各种的高可用方案，谈一下个人的一些看法，如有错误，还请指正！！ MySQL主从架构 此种架构，一般初创企业比较常用，也便于后面步步的扩展 此架构特点： 1、成本低，布署快速、方便 2、读写分离 3、还能通过及时增加从库来减少读库压力 4、主库单点故障 5、数据一致性问题（同步延迟造成） MySQL+DRDB架构 通过DRBD基于block块的复制模式，快速进行双主故障切换，很大程度上解决主库单点故障问题 此架构特点： 1、高可用软件可使用Heartbeat,全面负责VIP、数据与DRBD服务的管理 2、主故障后可自动快速切换，并且从库仍然能通过VIP与新主库进行数据同步 3、从库也支持读写分离，可使用中间件或程序实现 MySQL+MHA架构 MHA目前在Mysql高可用方案中应该也是比较成熟和常见的方案

18.1 集群介绍 一台机器完成不了的任务我们交给一大群机器去做，集群就好比一个堆叠起来的计算机。 集群根据功能划分两大类：高可用和负载均衡 高可用集群通常为两台服务器，一台工作，另外一台作为冗余，当提供服务的机器宕机，冗余将接替继续提供服务。（保证服务的可用性） 实现高可用的开源软件有：heartbeat、keepalived。 heartbeat在centos6上bug比较多，而且不再更新了，更推荐keepalived。 负载均衡集群，需要有一台服务器作为分发器，它负责把用户的请求分发给后端的服务器处理，在这个集群里，除了分发器外，就是给用户提供服务的服务器了，这些服务器数量至少为2个。 实现负载均衡的开源软件有LVS、keepalived、haproxy、nginx，商业的有F5、Netscaler。LVS是非常出名的一款做负载均衡的软件。商业软件的稳定性和应对高访问量是值得肯定的，开源软件的稳定性等就会取决于你的服务器的性能了。 18.2 keepalived介绍 在这里我们使用keepalived来实现高可用集群，因为heartbeat在centos6上有一些问题，影响实验效果。heartbeat在切换主从的时候有延时，做高可用集群的时候还是推荐使用keepalived。 keepalived通过VRRP（Virtual Router Redundancy Protocl

前言： 数据库系统是一个应用系统的核心部分，要想系统整体可用性得到保证，数据库系统就不能出现任何问题。对于一个企业级的系统来说，数据库系统的可用性尤为重要。数据库系统一旦出现问题无法提供服务，所有系统都可能无法继续工作，而不像软件中部分系统出现问题可能影响的仅仅只是某个功能无法继续服务。所以，一个成功的数据库架构在高可用设计方面也是需要充分考虑的。本章内容将针对如何构建一个高可用的 MySQL 数据库系统来介绍各种解决方案以及方案之间的比较。 17.1 利用 Replication 来实现高可用架构 做维护的读者朋友应该都清楚，任何设备（或服务），只要是单点，就存在着很大的安全隐患。因为一旦这台设备（或服务） crash 之后，在短时间内就很难有备用设备（或服务）来顶替其功能。所以稍微重要一些的服务器或者应用系统，都会存在至少一个备份以供出现异常的时候能够很快的顶替上来提供服务。 对于数据库来说，主备配置是非常常见的设计思路。而对于 MySQL 来说，可以说天生就具备了实现该功能的优势，因为其 Replication 功能在实际应用中被广泛的用来实现主备配置的功能。 我想，在大家所接触的 MySQL 环境中大多数都存在通过 MySQL Replication 来实现两台（或者多台） MySQL Server 之间的数据库复制功能吧。可能有些是为了增强系统扩展性

drbd 来源： oschina 链接： https://my.oschina.net/u/1014681/blog/342236

1.几种获取状态信息的方法 drbd有很多获取信息的方式。在drbd84和之前的版本，大多都使用 cat /proc/drbd 来获取信息，多数情况下，这个文件展示的信息对于管理和维护drbd来说已经足够。 例如以下是drbd84上两个volume的节点状态信息： [root @drbd1 ~] # cat /proc/drbd version : 8.4 .10- 1 ( api : 1 / proto : 86 - 101 ) GIT- hash : a4d5de01fffd7e4cde48a080e2c686f9e8cebf4c build by mockbuild@, 2017 - 09 - 15 14 : 23 : 22 0 : cs :Connected ro :Primary/Secondary ds :UpToDate/UpToDate C r----- ns : 76408 nr : 0 dw : 76408 dr : 3441 al : 22 bm : 0 lo : 0 pe : 0 ua : 0 ap : 0 ep : 1 wo :f oos : 0 1 : cs :Connected ro :Primary/Secondary ds :UpToDate/UpToDate C r----- ns : 4957732 nr : 0 dw : 76324 dr :

作者： 独笔孤行@TaoCloud DRBD（Distributed Replicated Block Device）是一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。可以简单的理解为网络RAID。 DRBD的核心功能通过Linux的内核实现，最接近系统的IO栈，DRBD的位置处于文件系统以下，比文件系统更加靠近操作系统内核及IO栈。 一、准备环境 节点 主机名 IP地址 磁盘 操作系统 节点1 node1 172.16.201.53 sda,sdb centos7.6 节点2 node2 172.16.201.54 sda,sdb centos7.6 关闭防火墙和selinux #2节点都需要配置 systemctl stop firewalld systemctl disable firewalld setenforce 0 sed -i "s/SELINUX=enforcing/SELINUX=disabled/g" /etc/selinux/config 配置epel源 #2节点都需要配置 yum install epel-release 二、安装drbd 如果yum源中有完整的drbd软件，可直接通过yum进行安装，如果yum无法找到部分软件包，可通过编译安装。以下2中方法二选一即可。 1.yum安装drbd yum install drbd

（一）MySQL 架构设计 MySQL 架构一定要结合前台业务来设计、优化，所以不管是哪种架构、根据业务要求组合成符合需求的即是最好的、不能泛泛而谈同时、也必须注意数据的安全（如ipsec,ssh，vpn传输） （二）MySQL常见架构 MySQL常见的架构都是进行业务切分、前端缓存、分库分表。若是过亿的查询量则先从业务上拆分、将 bbs、web、blog 分成几个组、然后再做成一主多从、读写分离的方式 而且、在设计表的时候、一般情况下、备库常充当起备份查询的作用，至于、读写分离、在程序设计之初、读和写是通过不同的IP入口、这是思路一、或者定义类、或者用代理层，比如 MySQL-proxy大多数的场合、一般在应用层做读写分离、然后 MySQL 通过复制来实现、优点比较多，可控性非常好、 （三）游戏常见架构 游戏中的：好友关系、排行榜、计数器、队列、cache 都很适合通过 Redis 来实现，至于 Redis 的事务功能、可以不必放太多的心思去关心。另外、Redis 相对 Memcached 而言、也稳定很多 （四）电商常见架构 电商中：生产环境也都是主从架构、然后用 DRBD + HA 做 Master 备份，主主不推荐、高可用还是推荐 DRBD 方案，DRBD 注意不设置自动启动、重启时候手动启动、脑裂的情况发生非常的少。不过、工作中基本不重启 DRBD、更不会重启服务器了

存储高可用NFS+DRBD+HEARTBEAT快速实施方案 环境： nfs-utils-1.2.3-75.el6_9.x86_64 heartbeat-3.0.4-2.el6.x86_64 drbd84-utils-8.9.8-1.el6.elrepo.x86_64 CentOS release 6.7 (Final) 2.6.32-573.el6.x86_64 x86_64 规划表： 名称 接口 IP 用途 Master eth0 10.0.0.31 管理IP eth1 172.16.1.31 心跳线 Backup eth0 10.0.0.32 管理IP eth1 172.16.1.32 心跳线 VIP eth0 10.0.0.30 提供NFS存储服务IP 以下操作除特殊说明外，均为在两台服务器操作 初始化 关闭selinux,iptables 配置主机名，/etc/hosts，/etc/sysconfig/network，配置网络配置 分区 parted /dev/sdb mklabel gpt parted /dev/sdb mkpart primary 0 1024 parted /dev/sdb mkpart primary 1025 2146 parted /dev/sdb p 主NFS格式化/dev/sdb1，从NFS不需要格式化（特殊说明） mkfs.ext4