Linux的企业-Mysql主从同步，Gtid，半同步，相关参数（1）

一.Mysql主从同步

MySQL 支持单向、异步复制,复制过程当中一个服务器充当主服务器,而一个或多个其它服务器充
当从服务器。主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环。这
些日志能够记录发送到从服务器的更新。当一个从服务器链接主服务器时,它通知主服务器从服
务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新,而后封
锁并等待主服务器通知新的更新。
请注意当你进行复制时,全部对复制中的表的更新必须在主服务器上进行。不然,你必需要当心,
以免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。
单向复制有利于健壮性、速度和系统管理:
1. 主服务器/从服务器设置增长了健壮性。主服务器出现问题时,你能够切换到从服务器做为备份
2. 经过在主服务器和从服务器之间切分处理客户查询的负荷,能够获得更好的客户响应时间。
SELECT 查询能够发送到从服务器以下降主服务器的查询处理负荷。但修改
数据的语句仍然应发送到主服务器,以便主服务器和从服务器保持同步。若是非更新查询为主,该
负载均衡策略颇有效,但通常是更新查询。
3. 使用复制的另外一个好处是可使用一个从服务器执行备份,而不会干扰主服务器。在备份过程
中主服务器能够继续处理更新。
MySQL 提供了数据库的同步功能,这对咱们实现数据库的冗灾、备份、恢复、负载均衡等都是
有极大帮助的。

二.配置环境

server2 主 172.25.29.2

server3 从 172.25.29.3

1.配置server2

log-bin=mysql-bin  启动二进制日志系统
binlog-do-db=test #二进制须要同步的数据库名,若是须要同步多个库,例如要再同步 westos
库,再添加一行“binlog-do-db=westos”,以此类推
server-id=1
#必须为 1 到 232–1 之间的一个正整数值
binlog-ignore-db=mysql #禁止同步 mysql 数据库

注：

设置参数—expire_logs_days=#(days)，此参数的含义是设置日志的过时天数，过来指定的天数后日志将会被自动删除，这样将有利于减小DBA管理日志的工做量。

进入到mysql中建立受权用户，查看master信息

2.配置server3

配置文件只需写上id号便可

重启服务，将server2设置为主，注意log_file文件和log_pso文件位置，在server2上看

启动从数据库主机，查看状态

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

若是都是 yes,表示从库的 I/O,Slave_SQL 线程都正确开启.代表数据库正在同步

查看同步的数据，显示正常

三.Gtid的设置

全局事务标识：global transaction identifiers。GTID是一个事务一一对应，而且全局惟一ID。一个GTID在一个服务器上只执行一次，避免重复执行致使数据混乱或者主从不一致。
GTID用来代替传统复制方法，再也不使用MASTER_LOG_FILE+MASTER_LOG_POS开启复制。而是使用MASTER_AUTO_POSTION=1的方式开始复制。MySQL-5.6.5开始支持的，MySQL-5.6.10后开始完善。在传统的slave端，binlog是不用开启的，可是在GTID中slave端的binlog是必须开启的，目的是记录执行过的GTID（强制）。

优点：

更简单的实现failover，不用之前那样在须要找log_file和log_pos。更简单的搭建主从复制。比传统的复制更加安全。GTID是连续的没有空洞的，保证数据的一致性，零丢失。

工做原理：

（1）当一个事务在主库端执行并提交时，产生GTID，一同记录到binlog日志中。
（2）binlog传输到slave,并存储到slave的relaylog后，读取这个GTID的这个值设置gtid_next变量，即告诉Slave，下一个要执行的GTID值。
（3）sql线程从relay log中获取GTID，而后对比slave端的binlog是否有该GTID。
（4）若是有记录，说明该GTID的事务已经执行，slave会忽略。
（5）若是没有记录，slave就会执行该GTID事务，并记录该GTID到自身的binlog，
   在读取执行事务前会先检查其余session持有该GTID，确保不被重复执行。
（6）在解析过程当中会判断是否有主键，若是没有就用二级索引，若是没有就用所有扫描。

1.安装高版本5.7.19的mysql

   低版本不支持gtid

   删除以前的低版本的mysql文件

   安装完成后先配置好主从配置

   配置好server2,server3

完成主从复制的配置

2.配置Gtid

配置server1 vim /etc/my.cnf

配置server2 vim /etc/my.cnf

登录server3上的mysql建立server2主节点

启动从服务，查看从状态

3.测试

在server2上建立数据

在server3上查看server2上的数据

查看从机的gtid更新表，已经有更新记录

4.开启多线程并发复制

slave-parallel-type

slave-parallel-workers

重启后查看show processlist进程，显示16

number of workers 为16

四.半同步 半同步主要是保证数据完整性防止数据丢失

1.半同步复制概念

       在说明半同步复制以前咱们先来了解一下，什么是同步复制？同步复制：同步复制能够定义为数据在同一时刻被提交到一台或多台机器，一般这是经过众所周知的“两阶段提交”作到的。虽然这确实给你在多系统中保持一致性，但也因为增长了额外的消息交换而形成性能降低。使用MyISAM或者InnoDB存储引擎的MySQL自己并不支持同步复制，然而有些技术，例如分布式复制块设备（简称DRBD），能够在下层的文件系统提供同步复制，容许第二个MySQL服务器在主服务器丢失的状况下接管（使用第二服务器的复本）。了解了同步复制咱们正下面来讲一下，什么是半同步复制？

       MYSQL 5.5开始，支持半自动复制。以前版本的MySQL Replication都是异步（asynchronous）的，主库在执行完一些事务后，是不会管备库的进度的。若是备库不幸落后，而更不幸的是主库此时又出现Crash（例如宕机），这时备库中的数据就是不完整的。简而言之，在主库发生故障的时候，咱们没法使用备库来继续提供数据一致的服务了。Semisynchronous Replication(半同步复制)则必定程度上保证提交的事务已经传给了至少一个备库。Semi synchronous中，仅仅保证事务的已经传递到备库上，可是并不确保已经在备库上执行完成了。

       此外，还有一种状况会致使主备数据不一致。在某个session中，主库上提交一个事务后，会等待事务传递给至少一个备库，若是在这个等待过程当中主库Crash，那么也可能备库和主库不一致，这是很致命的。若是主备网络故障或者备库挂了，主库在事务提交后等待10秒（rpl_semi_sync_master_timeout的默认值）后，就会继续。这时，主库就会变回原来的异步状态。

MySQL在加载并开启Semi-sync插件后，每个事务需等待备库接收日志后才返回给客户端。若是作的是小事务，两台主机的延迟又较小，则Semi-sync能够实如今性能很小损失的状况下的零数据丢失。

异步与半同步异同

       默认状况下MySQL的复制是异步的，Master上全部的更新操做写入Binlog以后并不确保全部的更新都被复制到Slave之上。异步操做虽然效率高，可是在Master/Slave出现问题的时候，存在很高数据不一样步的风险，甚至可能丢失数据。

       MySQL5.5引入半同步复制功能的目的是为了保证在master出问题的时候，至少有一台Slave的数据是完整的。在超时的状况下也能够临时转入异步复制，保障业务的正常使用，直到一台salve追遇上以后，继续切换到半同步模式。

2.在主机server2上开启半同步

添加半同步插件

查看半同步状态为OFF

       开启半同步

3.在主机server3上开启半同步

4.在主机server3上重启mysql的IO接口正常

5.测试半同步

主机半同步状态开启

主机建立数据很快同步到从机server3上

查看从机半同步状态开启

关闭server3的IO接口

在主机server2上插入数据

等待10s半同步后，server3无响应，server2转为异步传输

主机已经有了数据

查看从机无刚才主机server2上插入的数据

再次启动IO接口，数据传同步过来

查看从机的半同步状态

6.半同步的永久设置

在server2配置文件中添加半同步选项开启

vim /etc.my.cnf

在server3上也开启，并开启只读模式

server2

10000ms为半同步的等待时间，超时后变为异步模式

server3的半同步也已经设置为自动开启

            只读模式自动开启

7.expire_logs_days表示保留时间

8.慢查询

慢查询已经开启

选择一个sleep模块，时间设置为默认的10秒

查看慢查询状态为有一个慢查询

经过慢查询日志