GTID模式

是指把数据从一个Mysql服务器主节点复制到一个或多个Mysql服务器从节点中会把主节点服务器中的所有数据库实例、特定数据库实例或特定表等全部复制到从节点服务器中。

是通过基于日志的复制方式实现数据的同步。

当主服务器上发生数据变更时会将这些变更写入二进制日志Binary

Log中。

从服务器通过连接到主服务器请求从主服务器获取二进制日志并将这些日志应用到自己的数据库中。

提高读性能通过设置从服务器Slave读操作可以被分摊到主服务器Master和从服务器上从而提高整体的读取性能。

主服务器负责处理写操作从服务器负责处理读操作从而降低主服务器的负载提升整个系统的吞吐量。

数据冗余和备份通过主从复制从服务器上的数据是主服务器的冗余副本。

在主服务器发生故障时从服务器仍然可以提供服务并且可以通过将某个从服务器提升为新的主服务器来快速恢复服务。

此外从服务器也可以用于定期的备份操作以确保数据的安全性和可恢复性。

高可用性通过主从复制可以实现数据库的故障转移和高可用性。

当主服务器发生故障时可以手动或自动将某个从服务器提升为新的主服务器继续提供数据库服务从而实现快速的故障恢复。

数据分析和报表生成由于从服务器可以处理读操作可以将其用于数据库的数据分析和报表生成等工作。

这样可以避免对主服务器造成额外的负载同时提供实时的数据分析和报表服务。

数据分发和跨地域部署主从复制可以用于将数据分发到不同的地理位置的从服务器上从而实现跨地域的数据访问和部署。

这对于全球化的应用程序和多地域灾备是非常有用的。

架构的扩展。

业务量越来越大I/O访问频率过高单机无法满足此时做多库的存储降低磁盘I/O访问的频率提高单个机器的I/O性能。

基于二进制日志复制有三种形式

基于SQL语句的复制基于行的复制混合模式复制。

基于GTID复制Mysql版本

GTID模式

identifierGTID是一个事务一一对应并且全局唯一ID一个GTID在一个服务器上只执行一次避免重复执行导致数据混乱或者主从不一致GTID用来代替传统复制方法不再使用MASTER_LOG_FILEMASTER_LOG_POS开启复制。

而是使用MASTER_AUTO_POSTION1的方式开始复制MySQL-5.6.5开始支持的MySQL-5.6.10后开始完善在传统的slave端binlog是不用开启的但是在GTID中slave端的binlog是必须开启的目的是记录执行过的GTID强制。

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

当一个事务在主库端执行并提交时产生GTID一同记录到binlog日志中binlog传输到slave,并存储到slave的relaylog后读取这个GTID的这个值设置gtid_next变量即告诉Slave下一个要执行的GTID值sql线程从relay

log中获取GTID然后对比slave端的binlog是否有该GTID如果有记录说明该GTID的事务已经执行slave会忽略如果没有记录slave就会执行该GTID事务并记录该GTID到自身的binlog在读取执行事务前会先检查其他session持有该GTID确保不被重复执行在解析过程中会判断是否有主键如果没有就用二级索引如果没有就用全部扫描。

Mysql主服务器

#创建一个用于复制的用户,userName和Password自行设置

CREATE

#配置复制serverIP是主服务器IP地址userName和password是刚在主服务器创建的用户file和position是刚查看主服务器状态返回的参数

CHANGE

#查看复制状态输出中的Slave_IO_Running和Slave_SQL_Running的值为Yes表示复制正在正常运行

SHOW

到这里就结束了可以在Mysql主服务器中进行添加、修改、删除操作测试从服务器中的数据是否保持一致。

注意从服务器只允许进行查询不可以进行添加、修改、删除等改变数据的操作否则会导致复制状态失效。