Linux的企业-Mysql主从同步，Gtid，半同步

Posted 2020-10-09

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Linux的企业-Mysql主从同步，Gtid，半同步相关的知识，希望对你有一定的参考价值。

一.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 数据库

进入到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上开启半同步

添加半同步插件