mysql集群技术

Mysql 在服务器中的部署方法

mysql 在服务器中的部署方法在企业中对于Mysql的安装通常用源码编译的方式来进行

官网：MySQL

在Linux下部署mysql

安装依赖性：

下载并解压源码包

源码编译安装mysql

Make

Make install

部署mysql

生成启动脚本

#生成配置文件

#修改环境变量

#数据库初始化建立mysql基本数据

登录

mysql的主从复制

配置mastesr

配置salve

测试

在slave中

延迟复制

在ｓｌａｖｅ端

慢查询日志

慢查询，顾名思义，执行很慢的查询

当执行SQL超过long_query_time参数设定的时间阈值（默认10s）时，就被认为是慢查询，这个 SQL语句就是需要优化的

慢查询被记录在慢查询日志里

慢查询日志默认是不开启的

如果需要优化SQL语句，就可以开启这个功能，它可以让你很容易地知道哪些语句是需要优化的。

添加slave2

mysql的并行复制

原理刨析

三个线程

实际上主从同步的原理就是基于 binlog 进行数据同步的。在主从复制过程中，会基于3 个线程来操作， 一个主库线程，两个从库线程。

二进制日志转储线程（Binlog dump thread）是一个主库线程。当从库线程连接的时候， 主库可以 将二进制日志发送给从库，当主库读取事件（Event）的时候，会在 Binlog 上加锁，读取完成之 后，再将锁释放掉。

从库 I/O 线程会连接到主库，向主库发送请求更新 Binlog。这时从库的 I/O 线程就可以读取到主库 的二进制日志转储线程发送的 Binlog 更新部分，并且拷贝到本地的中继日志 （Relay log）。

从库 SQL 线程会读取从库中的中继日志，并且执行日志中的事件，将从库中的数据与主库保持同 步。

具体操作

1.slaves端中设置了master端的ip，用户，日志，和日志的Position，通过这些信息取得master的认证及 信息

2.master端在设定好binlog启动后会开启binlog dump的线程

3.master端的binlog dump把二进制的更新发送到slave端的

4.slave端开启两个线程，一个是I/O线程，一个是sql线程， i/o线程用于接收master端的二进制日志，此线程会在本地打开relaylog中继日志，并且保存到本地 磁盘 sql线程读取本地relog中继日志进行回放

5.什么时候我们需要多个slave？

当读取的而操作远远高与写操作时。我们采用一主多从架构 数据库外层接入负载均衡层并搭配高可用机制

架构缺陷

主从架构采用的是异步机制 master更新完成后直接发送二进制日志到slave，但是slaves是否真正保存了数据master端不会检测 master端直接保存二进制日志到磁盘 当master端到slave端的网络出现问题时或者master端直接挂掉，二进制日志可能根本没有到达slave master出现问题slave端接管master，这个过程中数据就丢失了 这样的问题出现就无法达到数据的强一致性，零数据丢失

半同步模式

半同步模式原理

1.用户线程写入完成后master中的dump会把日志推送到slave端

2.slave中的io线程接收后保存到relaylog中继日志

3.保存完成后slave向master端返回ack

4.在未接受到slave的ack时master端时不做提交的，一直处于等待当收到ack后提交到存储引擎

5.在5.6版本中用到的时after_commit模式，after_commit模式时先提交在等待ack返回后输出ok

gtid模式

在master端和slave端开启ｇｔｉｄ模式

功能开启

启用半同步模式

master端配置启用半同步模式

#安装半同步插件

#查看插件情况

打开半同步功能

#查看半同步功能状态

在slave端开启半同步功能

测试

在master端写入数据

模拟故障

在slave端

在master写入数据

mysql高可用之组复制 (MGR)

提供了高可用、高扩展、高可靠的 MySQL 集群服务

MySQL 组复制分单主模式和多主模式，传统的mysql复制技术仅解决了数据同步的问题， MGR 对属于同一组的服务器自动进行协调。对于要提交的事务，组成员必须就全局事务序列中给定事务 的顺序达成一致

提交或回滚事务由每个服务器单独完成，但所有服务器都必须做出相同的决定

如果存在网络分区，导致成员无法达成事先定义的分割策略，则在解决此问题之前系统不会继续进行， 这是一种内置的自动裂脑保护机制

MGR由组通信系统( Group Communication System，GCS ) 协议支持 该系统提供故障检测机制、组成员服务以及安全且有序的消息传递

组复制流程

组复制单主和多主模式

组内的所有机器都是 primary 节点，同时可以进行读写操作，并且数据是最终一致的

实现mysql组复制

编辑主配置文件：

在master中

停止mysqld服务然后删除

在slave中复制配置文件

修改slave中的配置

mysql-router（mysql路由）

Mysql route的部署方式

再开一台主机mysql-router

#安装mysql-router

#配置mysql-router

#建立测试用户

mysql> CREATE USER lee@'%' IDENTIFIED BY 'lee';

mysql> GRANT ALL ON lee.* TO lee@'%';

#查看调度效果

watch -1 lsof -i :3306

mysql高可用之MHA

MHA 的特点 自动故障切换过程中，MHA从宕机的主服务器上保存二进制日志，最大程度的保证数据不丢失

使用半同步复制，可以大大降低数据丢失的风险，如果只有一个slave已经收到了最新的二进制日 志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数 据一致性

目前MHA支持一主多从架构，最少三台服务，即一主两从

MHA工作原理

目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群必须最少有3台数据库服务器， 一主二从，即一台充当Master，台充当备用Master，另一台充当从库。

MHA Node 运行在每台 MySQL 服务器上

MHAManager 会定时探测集群中的master 节点

当master 出现故障时，它可以自动将最新数据的slave 提升为新的master

然后将所有其他的slave 重新指向新的master，VIP自动漂移到新的master。

整个故障转移过程对应用程序完全透明。

MHA部署实施

搭建主两从架构

#在master节点中

在两个slave中

安装MHA所需要的软件

unzip MHA-7.zip

在三台MySQL中

yum install /mnt/mha4mysql-node-0.58 0.el7.centos.noarch.rpm -y

配置MHA 的管理环境

.生成配置目录和配置文件

#生成配置文件

在sql中

可远程登陆

如在sql 3 中

检测远程登陆

MHA的故障切换

MHA的故障切换过程 共包括以下的步骤：

1.配置文件检查阶段，这个阶段会检查整个集群配置文件配置

2.宕机的master处理，这个阶段包括虚拟ip摘除操作，主机关机操作

3.复制dead master和最新slave相差的relay log，并保存到MHA Manger具体的目录下

4.识别含有最新更新的slave

5.应用从master保存的二进制日志事件（binlog events）

6.提升一个slave为新的master进行复制

7.使其他的slave连接新的master进行复制

master未出现故障手动切换

填yes

假设故障后重启

后

恢复故障mysql节点

为MHA添加VIP功能

上创脚本

后

修改VIP

vim /usr/local/bin/master_ip_failover

vim /usr/local/bin/master_ip_online_change

启动监控程序

#在master节点添加VIP