mysql(三)基于GDIT主从复制

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/wzj_110/article/details/96015078

一   说明

        mysql数据库从5.6.5开始新增一种基于GDIT的复制方式。GTID (Global Transaction ID) 是对于一个已提交事务的编号,并且是一个全局唯一的编号, GTID 实际上是由 UUID+TID 组成的,其中 UUID 是一个 MySQL 实例的唯一标识,TID 代表了该实例上已经提交的事务数量,并且随着事务提交单调递增。通过GDIT保证每个主库上提交的事务在集群中有一个唯一的ID.这种方式强化了数据库的主备一致性,故障恢复以及容错能力。

      GTID是基于mysql事务实现的!

      事务是一系列操作,组成了一个逻辑工作单元,这个逻辑工作单元中的操作作为一个整体,要么全部成功,要么全部失败。

      主从复制,默认是通过pos复制(postion),就是说在日志文档里,将用户进行的每一项操作都进行编号(pos),每一个event都有一个起始编号(start)一个终止编号(end),我们在配置主从复制时从节点时,要输入master的log_pos值就是这个原因,要求它从哪个pos开始同步数据库里的数据,这也是传统复制技术

        MySQL5.6增加了GTID复制,GTID就是类似于pos的一个作用,不过它是整个mysql复制架构全局通用的,就是说在这整个mysql冗余架构中,它们的日志文件里事件的GTID值是一致的

二   GTID的相关特性

1、Gtid的工作原理

      master更新数据时,会在事务前产生GTID,一同记录到binlog日志中。slave端的i/o 线程将变更的binlog,写入到本地的relay log中。sql线程从relay log中获取GTID,然后对比slave端的binlog是否有记录,如果有记录,说明该GTID的事务已经执行,slave会忽略。如果没有记录,slave就会从relay log中执行该GTID的事务,并记录到binlog,在解析过程中会判断是否有主键,如果没有就用二级索引,如果没有就用全部扫描。

2、基于GTID复制的优点

         一个事务对应一个唯一ID,一个GTID在一个服务器上只会执行一次,GTID是用来代替传统复制的方法,GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置,减少手工干预和降低服务故障时间,当主机挂了之后通过软件从众多的备机中提升一台备机为主机

pos与GTID有什么区别?

  • 两者都是日志文件里事件的一个标志,如果将整个mysql集群看作一个整体,pos就是局部的,GTID就是全局的

三   GTID主从部署

3、修改配置文件(/etc/my.cng)并且重新启动mysql(主库和从库都要配置)

#  my.cnf 配置文件的修改

############主(mysql1)################
log-bin=mysql-bin             # 如果哦下面的也写日志就太大了!
server_id=1                   # 每一个都不一样(为什么?)!
gtid_mode=ON                  # 开启gtid模式
enforce_gtid_consistency=true # 说明:强制gtid一直性,用于保证启动gitd后事务的安全,改成1也可以!

############从(mysql2)#################

server_id=2 #每一个都不一样!
gtid_mode=ON
enforce_gtid_consistency=true

## 主从端都重启服务systemctl restart mysqld

mysql 主从配置中的server-id的作用

自己理解:识别主从的库的唯一标识

进行相关配置

说明:主库

grant replication slave on *.* to repl@'172.25.2.%' identified by 'Wzj@170510';
mysql> show variables like '%log_bin%';
+---------------------------------+--------------------------------+
| Variable_name                   | Value                          |
+---------------------------------+--------------------------------+
| log_bin                         | ON                             |
| log_bin_basename                | /var/lib/mysql/mysql-bin       |
| log_bin_index                   | /var/lib/mysql/mysql-bin.index |
| log_bin_trust_function_creators | OFF                            |
| log_bin_use_v1_row_events       | OFF                            |
| sql_log_bin                     | ON                             |
+---------------------------------+--------------------------------+
6 rows in set (0.01 sec)
-- 从(mysql2)####
-- 在从库端先停掉slave,然后重新创建连接,不要受之前的影响!
stop slave
change master to master_host = '172.25.2.1',master_user = 'repl',master_password = 'Wzj@170510',
master_auto_position =1 ;

start slave; -->看对应的线程!
show master status; -->查看下状态!

(2)出现问题如下 

Slave_IO_Running: Connecting
Slave_SQL_Running: Yes
Auto_Position: 1

原因

#1.网络不通
#2.账户密码错误
#3.防火墙
#4.mysql配置文件问题
#5.连接服务器时语法
#6.主服务器mysql权限
#7.serevr-id是不是一样了!

(3)测试

## mysql(主测试)

insert into usertb values ('user2','456');

## mysql(从测试)

# 主库上进行相关操作,产生事务,观察mysql.gtid_executed表的变化情况

mysql> select * from mysql.gtid_executed;
+--------------------------------------+----------------+--------------+
| source_uuid                          | interval_start | interval_end |
+--------------------------------------+----------------+--------------+
| b2510a7b-a7b8-11e9-8f3b-525400a5e492 |              1 |            1 |
+--------------------------------------+----------------+--------------+
1 row in set (0.00 sec)

mysql> select * from wzj.usertb;
+----------+----------+
| username | password |
+----------+----------+
| user1    | 123      |
| user2    | 456      |
+----------+----------+
2 rows in set (0.00 sec)

 

展开阅读全文

没有更多推荐了,返回首页