一数据库安装：

1 安装数据库

数据包下载地址：
链接：https://pan.baidu.com/s/16CBO11HBf3Pl4eGEGg5vNw
密码：3nzg
下载所需的安装包并进行解压：

安装相关数据包

将其发送至客户端主机

客户端查看并安装：

启动master 数据库并初始化密码和修改密码

其密码默认在/var/log/mysqld.log中生成

初始化密码

启动服务器并安装是否修改成功

从库查看密码位置并进行相关的初始化

查看密码是否修改成功

二配置mysql数据库的主从同步

1 主从同步原理：

Replication 线程：
Mysql的 Replication 是一个异步的复制过程（mysql5.1.7以上版本分为异步复制和半同步两种模式），从一个 Mysql instace(我们称之为 Master)复制到另一个 Mysql instance(我们称之 Slave)。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程(Sql线程和IO线程)在 Slave 端，另外一个线程(IO线程)在 Master 端。
要实现 MySQL 的 Replication ，首先必须打开 Master 端的Binary Log(mysql-bin.xxxxxx)功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。打开 MySQL 的 Binary Log 可以通过在启动 MySQL Server 的过程中使用 “—log-bin” 参数选项，或者在 my.cnf 配置文件中的 mysqld 参数组([mysqld]标识后的参数部分)增加 “log-bin” 参数项。

2 主从同步的两个线程及其功能

（1）sql_thread：负责从中继日志读取内容，然后replay到数据库中；
（2）io_thread：负责连接主服务器，把主服务器的二进制日志复制到自己的中继日志；

3 主从同步的方式

mysql支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其他服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环，这些日志可以记录发送到从服务器的更新，当一个从服务器链接主服务器时，他通知主服务器从服务器在日志中读取的最后一次成功更新的位置，从服务器接受从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。

复制优点：
1 主服务器/从服务器设置增加了健壮性，主服务器出现故障时，你可以切换到从服务器作为备份
2 通过主服务器和从服务器之间切分处理客户查询的负荷，可以更好的提高客户端的响应时间
3 从服务器执行复制，不会影响主服务器的更新和读写操作。

4 mysql的AB 复制

mysql数据库的版本，要么主库比从库版本低，要么相同。

1 基本server-id及log-bin配置

1 主动端配置：

参数解析：
1 log-bin ：启动二进制日志系统
2 server-id: 必须是1-2^32-1 之间的整数
重启服务器

从库端配置

重启服务器

2 权限相关配置：

1 查看主库相关情况，从库链接主库便从此开始，并配置相应的用户和密码及权限

从库边链接数据库操作，并启用从库功能

参数详解：
master_host=主服务器IP
master_user=在主服务器上创建的备份用户名
master_password=备份用户密码
master_log_file=查询master(主服务器)的状态得到的File列的值
master_log_pos=Position列的值。其值必须与主库所对应的值相同
start slave：启动从服务器复制功能

查看其是否连接成功

3 验证主从同步：

查看主库数据库情况并创建数据库python

从库边查看：

主库配置数据表并插入数据：

从库端查看是否成功

主库删除数据

从库查看是否操作成功

相关文件作用：

mysql-bin.index：服务器一旦开启二进制日志，会产生一个与二日志文件同名，但是以.index结尾的文件。它用于跟踪磁盘上存在哪些二进制日志文件。MySQL用它来定位二进制日志文件。
mysqld-relay-bin.index：该文件的功能与mysql-bin.index类似，但是它是针对中继日志，而不是二进制日志。
master.info：保存master的相关信息。不要删除它，否则，slave重启后不能连接master。
relay-log.info：包含slave中当前二进制日志和中继日志的信息。
5 配置GTID 的主从同步：

一、GTID的概述：

GTID=UUID+传输ID
1、全局事物标识：global transaction identifieds。
2、GTID事物是全局唯一性的，且一个事务对应一个GTID。
3、一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。
4、GTID用来代替classic的复制方法，不在使用binlog+pos开启复制。而是使用master_auto_postion=1的方式自动匹配GTID断点进行复制。
5、MySQL-5.6.5开始支持的，MySQL-5.6.10后开始完善。
6、在传统的slave端，binlog是不用开启的，但是在GTID中，slave端的binlog是必须开启的，目的是记录执行过的GTID（强制）

二、GTID的组成部分：

前面是server_uuid：后面是一个序列号
例如：server_uuid：sequence number
7800a22c-95ae-11e4-983d-080027de205a:10
UUID：每个mysql实例的唯一ID，由于会传递到slave，所以也可以理解为源ID。
Sequence number：在每台MySQL服务器上都是从1开始自增长的序列，一个数值对应一个事务

三、GTID比传统复制的优势：

1、更简单的实现failover，不用以前那样在需要找log_file和log_Pos。
2、更简单的搭建主从复制。
3、比传统复制更加安全。
4、GTID是连续没有空洞的，因此主从库出现数据冲突时，可以用添加空事物的方式进行跳过。

四、GTID的工作原理：

1、master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。
2、slave端的i/o 线程将变更的binlog，写入到本地的relay log中。
3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。
4、如果有记录，说明该GTID的事务已经执行，slave会忽略。
5、如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。
6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。
要点：
1、slave在接受master的binlog时，会校验master的GTID是否已经执行过（一个服务器只能执行一次）。
2、为了保证主从数据的一致性，多线程只能同时执行一个GTID。

五配置

1 主库端配置

重启服务

2 从库端配置：

重启服务

关闭原先的主从同步链接并创建基于GTID的主从同步链接

查看是否连接成功

3 查看相关的二进制日志命令

4 测试

主库插入数据

从库查看

查看主库日志情况，通过后端的数字来确定其同步是否完成，如果和主库发送的数据相同，则表明从库同步完成

查看从库的有关同步字段内容

6 配置线程增加（针对的是IO_thread）

（均在slave端配置）：线程增加配置与将数据由文件存储转换为表存储的配置
查看原配置线程情况
当配置了多线程之后，原本的单线程将用于处理与服务器master之间的信息操作，而不是用于同步复制。

配置多线程处理和将同步日志的保存由文件转义到表的配置，将原本对磁盘的操作优化为对内存的操作，性能有所提升

参数详解：
slave_parallel_workers=16
#并行的SQL线程数量，此参数只有设置 1<N的情况下才会才起N个线程进行SQL重做。
#经过测试对比发现，如果主库的连接线程为M，只有M < N的情况下，备库的延迟才可以完全避免。#否则，延迟一样的会存在，但是毕竟SQL重做线程从原来的一个，升级到现在的N个，这个延迟在一定的主库TPS下会很短！
master_info_repository=TABLE
relay_log_info_repository=TABLE
这两个参数会将master.info和relay.info保存在表中，默认是Myisam引擎，官方建议改为Innodb引擎，防止表损坏后自行修复。
relay_log_recovery=ON
#当slave从库宕机后，假如relay-log损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的relay-log，并且重新从master上获取日志，这#样就保证了relay-log的完整性。默认情况下该功能是关闭的，将relay_log_recovery的值设置为 1时，可在slave从库上开启该功能，建议开启。

重启客户端并查看MySQL库中增加了记录同步日志的GTID 的表

查看此表情况

查看线程数是否增加，增加15个：

7 半同步配置：

1 mysql 5.7 与 5.6 半同步比较

mysql 5.6 是当master提交事务之前，会向slave端发送binlog并提交事务，等到slave端返回成功后再返回给客户端，

mysql 5.7 是在master提交事务之前，会向slave端发送binlog 信息，并等待客户端返回成功后提交事务，并返回给客户端。
mysql5.7 的可靠性更高

2 主库端加载master模块：

3 从库端配置：

主库端查看配置情况

其中rpl_semi_sync_master_enabled是控制Master是否开启半同步，开启或不开启,将其设
置为ON或OFF(1or0).
rpl_semi_sync_master_timeout是控制Master等待多长时间被告知Slave已收到，也就是所
谓的超时时间。
rpl_semi_sync_slave_enabled是控制Slave是否开启半同步，开启或不开启，将其设置为ON
或OFF(1or0)。
其master处于开启状态。发现了slave

监控半同步复制的状态变量（几个常用的）：
Rpl_semi_sync_master_clients：查看有多少个开启半同步复制的插件的Slave
Rpl_semi_sync_master_status：查看在Master上半同步复制是否正在运行，其值为ON时，
说明Master已启用半同步且已被告知有Slave收到；其值为OFF时，说明Master没启用半同步
或是没被告知，由于timeout等原因。
Rpl_semi_sync_master_no_tx：查看有多少事务没有用半同步复制的机制进行复制。
Rpl_semi_sync_master_yes_tx：查看有多少事务是通过半同步复制机制成功复制。
Rpl_semi_sync_slave_status：查看Slave上半同步复制是否正常运行，其值为ON时，说明
Slave正通过半同步复制且Slave I/O正在运行；为OFF时，反之。
重启io_thread使用相同步骤配置从节点，完成后需要重启io_thread，不重启当执行时会超
时，超时后则自动降为异步：

8 数据库的级联配置：

同步方式，使用半同步的方式进行
server1---->server2(是server1 的从，也是server3的主)------>server3
架构图：

server1 端配置：

用于使得加载模块的永久性

2 server2

需要加载master模块并激活，并且需要日志log-bin文件，因为其是主库

3 server3 配置

1 加载slave 模块。

2 建立数据库并将server2的相关配置导入

3 重启服务

4 将GTID等相关参数写入配置文件：

5 重启服务加载模块

6 进行连接server2 数据库：

4 查看配置：

server2

server3

5 测试。

此时必须在server1 端进行测试：

8 mysql数据库的读写分离：

环境server1 为server2的主服务器.server3 为调度器，用于向客户端提供一个API接口，用于调用mysql数据库

1 基础准备：

关闭server3的数据库并设置为开机不启动：

server1端配置权限，用于mysql数据库的远程登录：

2 安装第三方软件

解压配置并将其名称改为mysql-proxy

启动服务：

3 创建配置文件和日志文件目录：

创建并配置配置文件：

参数详解：
--proxy-address=host:port ———— 代理服务监听的地址和端口
--admin-address=host:port ———— 管理模块监听的地址和端口
--proxy-backend-addresses=host:port ———— 后端mysql服务器的地址和端口（主服务器）
--proxy-read-only-backend-addresses=host:port ———— 后端只读mysql服务器的地址和端口（从服务器）
--proxy-lua-script=file ———— 完成mysql代理功能的Lua脚本
--daemon ———— 以守护进程模式启动mysql-proxy
--defaults-file=/path/to/conf_file_name ———— 默认使用的配置文件路径
--log-file=/path/to/log_file_name ———— 日志文件名称
--log-level=level ———— 日志级别
--log-use-syslog ———— 基于syslog记录日志
--user=user_name ———— 运行mysql-proxy进程的用户
修改其读写分离规则：

其表示为至少链接1次和至多链接2 次就切换到从库。
授其执行权限权：

安装查看链接的软件：lsof

4 启动并查看服务是否成功

5 远程链接测试：

9 mysql的组复制：

1 组复制限制：

存储引擎必须为Innodb
每个表必须提供主键
只支持ipv4，网络需求较高
一个组最多只能有9台服务器
不支持 Replication event checksums，
不支持 Savepoints
多主模式不支持SERIALIZABLE事务隔离级别
多主模式不能完全支持级联外键约束
多主模式不支持在不同节点上对同一个数据库对象并发执行DDL(在不同节点上对同一行并发进行RW事务，后发起的事务会失败)

2 复制结构图

使用场景：
1 弹性复制
2 高可用分片
3 代替主从复制
4 自动系统

3 文件配置：my.cnf

server 1 端配置

参数详解：
1 transaction_write_set_extraction=XXHASH64
server 必须为每个事物收集写集合，并使用XXHASH64 哈希算法将其编码为散列
2 loose-group_replication_group_name
告知插件，正在加入或创建的组要命名为后端的内容
3 loose-group_relication_start_on_boot=off
指示插件在server启动时不自动启动组复制
4 loose-group——replication_local_address=“”
告知插件本节点使用的IP地址
5 loose-group_replication_bootstrap_group=off
告知插件，当下面这些server需要加入组时，应该链接到这些主机和端口上访问他们。此选项不是列出组中的所有成员，而是当次server需要加入组时需要访问的server列表
6 loose-group_replication_single_primary_mode=FALSE
本次搭建的是mutil_mode
server 2 端配置

server 3 端配置

4 重启服务使其加载配置

5 mysql内部配置

server 1 端配置

1 关闭二进制日志。使其不被记录到日志中
set sql_log_bin=0;
2 创建复制用户与授权
grant replication slave on . to admin@'%' identified by 'ADMIN@root1';
3 刷新授权
flush privileges;
4 开启二进制日志记录功能
set sql_log_bin=1;
5 设置组相关信息
change master to master_user='admin',master_password='ADMIN@root1' for channel 'group_replication_recovery';
6 安装GR 插件
install plugin group_replication soname 'group_replication.so';
7 开启master启动后组复制自动进行
set global group_replication_bootstrap_group=ON;
8 设置发现方式
set global group_replication_ip_whitelist="172.25.254.0/24";
Query OK, 0 rows affected (0.00 sec)
9 启动组：
start group_replication;
10 关闭master启动后组复制自动进行
set global group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)
11 查看是否成功
select * from performance_schema.replication_group_members;
server 2 端配置：

兼容加入组
set global group_replication_allow_local_disjoint_gtids_join=ON;
server 3 端配置：

6 测试

其创建的数据表应该有主键，不能重复。

10 mysql MHA 配置：

server1 为server2 和server3 的master 但server2 可以作为server1 的slave 也可以在server1down之后作为server3的主设备，server3 不具备做主master的权利。
server3 上有调度器

1 介绍：

MHA，即MasterHigh Availability Manager and Toolsfor MySQL，是日本的一位MySQL专家
采用Perl语言编写的一个脚本管理工具，
该工具仅适用于MySQLReplication 环境，目的在于维持Master主库的高可用性。
MHA(Master High Availability)是自动的master故障转移和Slave提升的软件包.
它是基于标准的MySQL复制(异步/半同步).
2 MHA组成部分：
MHA由两部分组成：
MHA Manager(管理节点)
MHA Node(数据节点)
3 MHA部署解读：
MHA Manager可以单独部署在一台独立机器上管理多个master-slave集群,也可以部署在一
台slave上.
MHA Manager探测集群的node节点,当发现master出现故障的时候,它可以自动将具有最新数
据的slave提升为新的master,然后将所有其它的slave导向新的master上.整个故障转移过程
对应用程序是透明的。
MHA node运行在每台MySQL服务器上(master/slave/manager),它通过监控具备解析和
清理logs功能的脚本来加快故障转移的。
4 MHA优缺点介绍：
优点：

故障切换时，可以自行判断哪个从库与主库的数据最接近，就切换到上面，可以减少数
据的丢失，保证数据的一致性
支持 binlog server，可提高 binlog 传送效率，进一步减少数据丢失风险。
可以配置 mysql 5.7 的增强半同步，来保证数据的时时同步
缺点：
自动切换的脚本太简单了，而且比较老化，建议后期逐渐完善。
搭建 MHA 架构，需要开启 linux 系统互信协议，所以对于系统安全性来说，是个不小
的考验。
5 原理介绍：
MHA的目的在于维持MySQL Replication中Master库的高可用性，其最大特点是可以修复多个
Slave之间的差异日志，最终使所有Slave保持数据一致，然后从中选择一个充当新的Master，并将其它Slave指向它。当master出现故障时，可以通过对比slave之间I/O thread 读取主库binlog的position号，选取最接近的slave做为备选主库（备胎）。其它的从库可以通过与备选主库对比生成差异的中继日志。
在备选主库上应用从原来master保存的binlog，同时将备选主库提升master。最后在其它slave上应用相应的差异中继日志并开始从新的master开始复制。
mysql高可用.txt
6 MHA工具包功能介绍：
Manager工具:
#masterha_check_ssh : 检查MHA的SSH配置。
#masterha_check_repl : 检查MySQL复制。
#masterha_manager : 启动MHA。
#masterha_check_status : 检测当前MHA运行状态。
#masterha_master_monitor : 监测master是否宕机。
#masterha_master_switch : 控制故障转移(自动或手动)。
#masterha_conf_host : 添加或删除配置的server信息。
7 . Node工具：
#save_binary_logs : 保存和复制master的二进制日志。
#apply_diff_relay_logs : 识别差异的中继日志事件并应用于其它slave。
#filter_mysqlbinlog : 去除不必要的ROLLBACK事件(MHA已不再使用这个工具)。
#purge_relay_logs : 清除中继日志(不会阻塞SQL线程)。
1 主从同步的搭建

server1上配置文件配置：

server2 上配置：

server3上配置：

server1和server2上开启半同步主从模块

server3上开启从同步模块

重启server1server2server3 加载配置文件

配置主从同步：
server2 端

server3 端

2 MHA软件安装

必须保证ssh均能实现无密码登录

1 安装节点软件：

2 安装控制节点软件：

server1 端进行授权，使得MHA能够操作mysql。

参数详解：
1 hostname：目标实例的主机名或者IP地址，这个参数是强制的，只能配置在app配置文件的[server_xxx]段落标记下
2 port：目标实例的端口，默认是3306，MHA使用mysql server的IP和port连接
3 ssh_user ：ssh方式链接其他主机使用的用户名
4 candidate_master：从不同的从库服务器中，提升一个可靠的机器为新主库，可以通过在配置文件中对应的从库服务器的配置段下添加candidate_master=1来提升这个从库被提升为新主库的优先级
5 no_master：通过在目标服务器的配置段落设置no_master=1，它永远也不会变为新主库，
6 repl_user：在所有slave上执行change master的复制用户名，这个用户最好是在主库上拥有replication slave权限
7 repl_password：repl_user参数指定的用户的密码，默认情况下，是当前复制帐号的密码，如果你运行了online master switch脚本且使用了–orig_master_is_new_slave做在线切换，当前主库作为了从库加入新主库，此时，如果你没有设置repl_password来指定复制帐号的密码，当前主库作为从库加入新主库的时候会在change master的时候失败，因为默认情况下这个密码是空的，MHA做切换的时候，其他所有作为从库加入新主库时，都需要使用这个密码
8 remote_workdir：每一个MHA node（指的是mysql server节点）生成日志文件的工作路径，这个路径是绝对路径，如果该路径目录不存在，则会自动创建，如果没有权限访问这个路径，那么MHA将终止后续过程，另外，你需要关心一下这个路径下的文件系统是否有足够的磁盘空间，默认值是/var/tmp
9 master_binlog_dir：在master上生成binlog的绝对路径，这个参数用在master挂了，但是ssh还可达的时候，从主库的这个路径下读取和复制必须的binlog events，这个参数是必须的，因为master的mysqld挂掉之后，没有办法自动识别master的binlog存放目录。默认情况下，master_binlog_dir的值是/var/lib/mysql,/var/log/mysql，/var/lib/mysql目录是大多数mysql分支默认的binlog输出目录，而 /var/log/mysql是ubuntu包的默认binlog输出目录，这个参数可以设置多个值，用逗号隔开
10 manager_workdir：mha manager生成的相关状态文件的绝对路径，如果没有设置，则默认使用/var/tmp
11 manager_log：mha manager生成的日志据对路径，如果没有设置，mha manager将打印在标准输出，标准错误输出上，如：当mha manager执行故障转移的时候，这些信息就会打印
12 ping_interval：这个参数表示mha manager多久ping（执行select ping sql语句）一次master，连续三个丢失ping连接，mha master就判定mater死了，因此，通过4次ping间隔的最大时间的机制来发现故障，默认是3，表示间隔是3秒
13 master_ip_failover_script：通常在MHA环境下，通常需要分配一个VIP供master用于对外提供读写服务，如果master挂了，HA软件指引备用服务器接管VIP，另外一个通用的方法，是在数据库中创建一个全局的应用程序名称与读写IP地址之间的全局类目映射（ {app1_master1, 192.168.0.1}, {app_master2, 192.168.0.2}, …）来代替VIP地址的使用，在这种情况下，如果你的master挂了，你需要更新这个数据库中的全局类目映射。第二种方法这里个人觉得跟智能DNS解析类似。
14 master_ip_online_change_script：这是一个与master_ip_failover_script 参数很接近的参数，但是这个参数不使用故障转移命令，而是master的在线change命令
15 shutdown_script：你可能想要强制关闭master节点来避免master节点重新启动服务，这对于避免脑裂来说是很重要的，

16 report_script：在故障转移完成或者说因为错误而终止的时候，你可能希望发送一个报告出来，这就是使用report_script 参数的目的
17 init_conf_load_script：这个脚本在你不想在配置文件中设置纯文本的信息的时候使用