需要购买VPS搭建ss的朋友可以点一下这个链接来购买：HostDare

价格炒鸡便宜哦！

速度测试：

价格的话：

最低 30RMB per/mon
1.5T 流量
100M 带宽
美国洛杉矶节点

博主就用的是这个套餐~

上一节我们主要是在standalone模型上进行练习，而在生产环境中，我们都是使用的是master/agent模型。

下面我们就如何制作模块、puppet的master/agent进行详细的练习

环境准备

虚拟机：

1
2
3
4
5
6

master节点        172.16.1.40/16
agent节点：
    node1节点         172.16.1.100/16
    node2节点         172.16.1.70/16
    node3节点         172.16.1.60/16

软件包：

1
2

master节点        puppet、puppet-server、facter
agent节点         puppet、facter

软件包下载地址：puppet、puppet-server、facter

注意：这里需要科学上网，才能下载软件包 :)

上一章，我们学习了puppet的基本使用方法，下面我们就做一些练习吧。

环境准备

由于我们这次练习是在standalone模式下，所以只需要一台虚拟机即可满足

• 虚拟机环境

1
2
3
4
5
6

$ lsb_release -a
LSB Version:	:core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID:	CentOS
Description:	CentOS Linux release 7.2.1511 (Core)
Release:	7.2.1511
Codename:	Core

• 需要安装的软件包

1
2

facter-2.4.6-1.el7.x86_64.rpm
puppet-3.8.7-1.el7.noarch.rpm

下载软件包链接：puppet、facter

puppet是一个IT基础设施自动化管理工具，它能够帮助系统管理员管理基础设施的整个生命周期：
供应(provisioning)、配置(configuration)、联动(orcherstraion)及报告(reporting)
基于puppet，可实现自动化重复任务、快速部署关键性应用以及在本地或云端完成主动管理变更

puppet主要使用的场景：

1
2

1. 初始化配置：initialize configuration
2. 审计：fixex 、updates、audits

puppet的三层模型：

1
2
3

configuration language      配置语言，能描述资源、依赖关系的语言，进行输出
transaction layer           描述资源的依赖关系
resource abstraction layer  资源层

puppet运行时的两种模型：

1
2

standalone      单机模型；手动应用资源清单
master/agent    主从模型；由agent周期性地向master请求清单并自动应用于本地

Redis 集群是一个提供在多个Redis间节点间共享数据的程序集。
Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据,从而达不到像Redis那样的性能,在高负载的情况下可能会导致不可预料的错误。
Redis集群通过分区来提供一定程度的可用性,在实际环境中当某个节点宕机或者不可达的情况下继续处理命令。

Redis集群的优势：

• 自动分割数据到不同的节点上。
• 整个集群的部分节点失败或者不可达的情况下能够继续处理命令。

Redis集群的数据分片：

1
2
3
4
5
6
7
8
9
10
11
12
13

Redis 集群没有使用一致性hash, 而是引入了哈希槽的概念
Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽
举个例子,比如当前集群有3个节点,那么:
* 节点 A 包含 0 到 5500号哈希槽.
* 节点 B 包含5501 到 11000 号哈希槽.
* 节点 C 包含11001 到 16384号哈希槽.
这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部分槽到D上. 如果我像移除节点A,需要将A中得槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可. 
由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态

Redis集群的主从复制模型：

为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型,每个节点都会有N-1个复制品.

在我们例子中具有A，B，C三个节点的集群,在没有复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用.

然而如果在集群创建的时候（或者过一段时间）我们为每个节点添加一个从节点A1，B1，C1,那么整个集群便有三个master节点和三个slave节点组成，这样在节点B失败后，集群便会选举B1为新的主节点继续服务，整个集群便不会因为槽找不到而不可用了

不过当B和B1 都失败后，集群是不可用的.

Redis 一致性保证

Redis 并不能保证数据的强一致性. 这意味这在实际中集群在特定的条件下可能会丢失写操作.
第一个原因是因为集群是用了异步复制.

写操作过程：

• 客户端向主节点B写入一条命令.
• 主节点B向客户端回复命令状态.
• 主节点将写操作复制给他得从节点 B1, B2 和 B3.

主节点对命令的复制工作发生在返回命令回复之后， 因为如果每次处理命令请求都需要等待复制操作完成的话， 那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。 注意：Redis 集群可能会在将来提供同步写的方法。 Redis 集群另外一种可能会丢失命令的情况是集群出现了网络分区， 并且一个客户端与至少包括一个主节点在内的少数实例被孤立。

举个例子 假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点， 其中 A 、B 、C 为主节点， A1 、B1 、C1 为A，B，C的从节点， 还有一个客户端 Z1 假设集群中发生网络分区，那么集群可能会分为两方，大部分的一方包含节点 A 、C 、A1 、B1 和 C1 ，小部分的一方则包含节点 B 和客户端 Z1 .

Z1仍然能够向主节点B中写入, 如果网络分区发生时间较短,那么集群将会继续正常运作,如果分区的时间足够让大部分的一方将B1选举为新的master，那么Z1写入B中得数据便丢失了.

注意， 在网络分裂出现期间， 客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的， 这一时间限制称为节点超时时间（node timeout）， 是 Redis 集群的一个重要的配置选项：

Redis提供了丰富的命令（command）对数据库和各种数据类型进行操作，这些command可以在Linux终端使用。

官方下载地址：redis
官方文档地址：redis文档

连接操作相关的命令

• QUIT：关闭连接（CONNECTION）
• AUTH：简单密码认证

对value操作的命令

• EXISTS(KEY)：确认一个KEY是否存在
• DEL(KEY)：删除一个KEY
• TYPE(KEY)：返回值的类型
• KEYS(PATTERN)：返回满足给定PATTERN的所有KEY
• RANDOMKEY：随机返回KEY空间的一个KEY
• RENAME(OLDNAME, NEWNAME)：将KEY由OLDNAME重命名为NEWNAME，若NEWNAME存在则删除NEWNAME表示的KEY
• DBSIZE：返回当前数据库中KEY的数目
• EXPIRE：设定一个KEY的活动时间（S）
• TTL：获得一个KEY的活动时间
• SELECT(INDEX)：按索引查询
• MOVE(KEY, DBINDEX)：将当前数据库中的KEY转移到有DBINDEX索引的数据库
• FLUSHDB：删除当前选择数据库中的所有KEY
• FLUSHALL：删除所有数据库中的所有KEY

MHA（Master HA）是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了 automating master failover 功能。
MHA在监控到 master 节点故障时，会提升其中拥有最新数据的 slave 节点成为新的 master 节点，
在此期间，MHA 会通过于其它从节点获取额外信息来避免一致性方面的问题。
MHA还提供了 master 节点的在线切换功能，即按需切换 master/slave 节点。

MHA组件

Manager 节点

1
2
3
4
5
6
7
8

- masterha_check_ssh        MHA 依赖的 SSH 环境检测工具
- masterha_check_repl       MySQL 复制环境检测工具
- masterha_manager          MHA 服务主程序
- masterha_check_status     MHA 运行状态探测工具
- masterha_master_monitor   MySQL master 节点可用性监测工具
- masterha_master_switch    master 节点切换工具
- masterha_conf_host        添加或删除配置的节点
- masterha_stop             关闭 MHA 服务的工具

Node 节点

1
2
3
4

- save_binary_logs          保存和复制 master 的二进制日志
- apply_diff_relay_logs     识别差异的中继日志事件并应用于其它 slave
- filter_mysqlbinlog        去除不必要的 ROLLBACK 事件(MHA 已不再使用这个工具)
- purge_relay_logs          清除中继日志(不会阻塞 SQL 线程)

自定义扩展

1
2
3
4
5
6

- secondary_check_script            通过多条网络路由检测 master 的可用性
- master_ip_failover_script         更新 application 使用的 masterip
- shutdown_script                   强制关闭 master 节点
- report_script                     发送报告
- init_conf_load_script             加载初始配置参数
- master_ip_online_change_script    更新 master 节点 ip 地址

需要购买VPS搭建ss的朋友可以点一下这个链接来购买：HostDare

速度测试在文章最后哦~

MySQL Replication实现了Master节点可读可写，Slave节点只读
这样的逻辑结构，大大降低了主节点的压力。
因为MySQL的主要压力都是读操作，而非写操作。
通过增加Slave节点的数量，负载均衡读操作，大大提高用户体验，提升产品竞争力。

1
2
3
4
5
6
7

主节点故障：
    立即提升从节点为主节点 --> 使用IP地址漂移 --> keepalived实现
 主从同步机制：
    通过从节点连接到主节点，同步主节点的二进制日志，来实现主从同步
    将主节点的二进制内容 同步至从节点的中继日志中
    从节点通过将中继日志 写入到本机的二进制日志中，实现主从同步

对于公司来说，数据库本身可能并不重要，重要的是数据库中存储的数据。
对于备份来说，备份不是我们最终的目的，而是使备份能够实现还原的目的，才是我们最终的追求。
所以，一个可恢复的数据库备份是非常重要的。

为什么备份?

1
2
3
4
5

实现灾难恢复：硬件故障(冗余)、软件故障(BUG)、自然灾害、黑客攻击、误操作、...
测试恢复备份时，可能出现将数据库测试崩溃掉的情况
这里最可能出现的情况是：误操作
所以说，在操作数据库时，一定要慎之又慎

备份时需要注意的事项

• 注意事项

1
2
3
4
5
6
7

能容忍最多丢失多少数据；
恢复数据需要在多长时间内完成；
需要恢复哪些数据；
做恢复演练：
    测试备份的可用性；
    增强恢复操作效率；

• 备份需要考虑的因素

1
2
3
4

锁定资源多长时间？
备份过程的时长？
备份时的服务器负载？
恢复过程的时长？

• 备份什么?

1
2
3
4

数据
二进制日志、InnoDB的事务日志；
代码（存储过程、存储函数、触发器、事件调度器）
服务器的配置文件 --> 配置系统中的配置文件 --> 存放在 Git 、svn 上

注意：二进制日志、InnoDB事务日志 与数据要分别存放在不同的硬盘中

• 备份策略

1
2
3
4

全量+差异 + binlogs
全量+增量 + binlogs 
备份手段：物理、逻辑