在 Master 上, gtid_next
是默认的 AUTOMATIC
,即 GTID 在每次事务提交时自动生成。它从当前已执行的 GTID 集合(即 gtid_executed)中,找一个大于 0 的未使用的最小值作为下个事务 GTID。在实际的更新事务记录之前将 GTID 写入到 Binlog。
在 Slave 上,从 Binlog 先读取到主库的 GTID(即 set gtid_next 记录),而后执行的事务采用该 GTID。
GTID 的好处
master_auto_position=1
GTID 模式复制局限性
-
在一个事务里面混合使用引擎,如 Innodb(支持事务)、MyISAM(不支持事务), 造成多个 GTIDs 和同一个事务相关联出错。
-
CREATE TABLE…..SELECT
不能使用,该语句产生的两个 Event。 在某一情况会使用同一个 GTID(同一个 GTID 在 slave 只能被使用一次):
-
event one:创建表语句 create table
-
event two :插入数据语句 insert
-
CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE
不能在事务内使用 (启用了–enforce-gtid-consistency
参数)。 -
使用 GTID 复制从库跳过错误时,不支持
sql_slave_skip_counter
参数的语法。
GTID 主从复制实战
1.Master 主数据库上的操作
在 my.cnf 文件中配置 GTID 主从复制
[root@mysql-master ~]# cp /etc/my.cnf /etc/my.cnf.bak
[root@mysql-master ~]# >/etc/my.cnf
[root@mysql-master ~]# cat /etc/my.cnf
[mysqld]
datadir = /var/lib/mysql
socket = /var/lib/mysql/mysql.sock
symbolic-links = 0
log-error = /var/log/mysqld.log
pid-file = /var/run/mysqld/mysqld.pid
#GTID:
server_id = 1
gtid_mode = on
enforce_gtid_consistency = on
#binlog
log_bin = mysql-bin
log-slave-updates = 1
binlog_format = row
sync-master-info = 1
sync_binlog = 1
#relay log
skip_slave_start = 1
配置后,重启 MySQL 服务:
[root@mysql-master ~]# systemctl restart mysqld
登录 MySQL,并查看 Master 状态, 发现多了一项 Executed_Gtid_Set
:
mysql> show master status;
±------------------±---------±-------------±-----------------±------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
±------------------±---------±-------------±-----------------±------------------+
| mysql-bin.000001 | 154 | | | |
±------------------±---------±-------------±-----------------±------------------+
1 row in set (0.00 sec)
mysql> show global variables like ‘%uuid%’;
±--------------±-------------------------------------+
| Variable_name | Value |
±--------------±-------------------------------------+
| server_uuid | 317e2aad-1565-11e9-9c2e-005056ac6820 |
±--------------±-------------------------------------+
1 row in set (0.00 sec)
查看确认 GTID 功能打开:
mysql> show global variables like ‘%gtid%’;
±---------------------------------±------+
| Variable_name | Value |
±---------------------------------±------+
| binlog_gtid_simple_recovery | ON |
| enforce_gtid_consistency | ON |
| gtid_executed | |
| gtid_executed_compression_period | 1000 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | |
| session_track_gtids | OFF |
±---------------------------------±------+
8 rows in set (0.00 sec)
查看确认 Binlog 日志功能打开:
mysql> show variables like ‘log_bin’;
±--------------±------+
| Variable_name | Value |
±--------------±------+
| log_bin | ON |
±--------------±------+
1 row in set (0.00 sec)
授权 slave 复制用户,并刷新权限:
mysql> flush privileges;
Query OK, 0 rows affected (0.04 sec)
mysql> show grants for slave@‘172.23.3.66’;
±------------------------------------------------------------------------------+
| Grants for slave@172.23.3.66 |
±------------------------------------------------------------------------------+
| GRANT REPLICATION SLAVE, REPLICATION CLIENT ON . TO ‘slave’@‘172.23.3.66’ |
±------------------------------------------------------------------------------+
1 row in set (0.00 sec)
再次查看 master 状态:
mysql> show master status;
±------------------±---------±-------------±-----------------±-----------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
±------------------±---------±-------------±-----------------±-----------------------------------------+
| mysql-bin.000001 | 622 | | | 317e2aad-1565-11e9-9c2e-005056ac6820:1-2 |
±------------------±---------±-------------±-----------------±-----------------------------------------+
1 row in set (0.00 sec)
这里需要注意一下:
启动配置之前,同样需要对从服务器进行初始化。对从服务器初始化的方法基本和基于日志点是相同的,只不过在启动了 GTID 模式后,在备份中所记录的就不是备份时的二进制日志文件名和偏移量了,而是记录的是备份时最后的 GTID 值。
需要先在主数据库机器上把目标库备份一下,假设这里目标库是 slave_test:
mysql> CREATE DATABASE slave_test CHARACTER SET utf8 COLLATE utf8_general_ci;
Query OK, 1 row affected (0.02 sec)
mysql> use slave_test;
Database changed
mysql> create table user (id int(10) PRIMARY KEY AUTO_INCREMENT,name varchar(50) NOT NULL);
Query OK, 0 rows affected (0.27 sec)
mysql> insert into slave_test.user values(1,“xiaoming”),(2,“xiaohong”),(3,“xiaolv”);
Query OK, 3 rows affected (0.06 sec)
Records: 3 Duplicates: 0 Warnings: 0
mysql> select * from slave_test.user;
±—±---------+
| id | name |
±—±---------+
| 1 | xiaoming |
| 2 | xiaohong |
| 3 | xiaolv |
±—±---------+
3 rows in set (0.00 sec)
把 slave_test 库备份出来:
[root@mysql-master ~]# mysqldump --single-transaction --master-data=2 --triggers --routines --databases slave_test -uroot -p123456 > /root/user.sql
这里有个版本上的问题:
MySQL 5.6 使用 mysqldump
备份时,指定备份的具体库,使用 --database
。
MySQL 5.7 使用 mysqldump
备份时,指定备份的具体库,使用 --databases。
然后把备份的 /root/user.sql
文件拷贝到 slave 从数据库服务器上。
[root@mysql-master ~]# rsync -e “ssh -p20” -avpgolr /root/user.sql
到这里主库的操作结束,包含 GTID 的备份数据已经 copy 到从库,下面来进行从库的操作。
2.从库操作
在 my.cnf 文件中配置 GTID 主从复制
与主服务器配置大概一致,除了 server_id 不一致外,从服务器还可以在配置文件里面添加 read_only=on
,使从服务器只能进行读取操作,此参数对超级用户无效,并且不会影响从服务器的复制。
[root@mysql-slave1 ~]# >/etc/my.cnf
[root@mysql-slave1 ~]# vim /etc/my.cnf
[mysqld]
datadir = /var/lib/mysql
socket = /var/lib/mysql/mysql.sock
symbolic-links = 0
log-error = /var/log/mysqld.log
pid-file = /var/run/mysqld/mysqld.pid
#GTID:
server_id = 2
gtid_mode = on
enforce_gtid_consistency = on
#binlog
log_bin = mysql-bin
log-slave-updates = 1
binlog_format = row
sync-master-info = 1
sync_binlog = 1
#relay log
skip_slave_start = 1
read_only = on
配置完成后,重启mysql服务。
[root@mysql-slave1 ~]# systemctl restart mysql
接着将主数据库目标库的备份数据 user.sql
导入到从数据库里。
[root@mysql-slave1 ~]# ls /root/user.sql
/root/user.sql
[root@mysql-slave1 ~]# mysql -p123456
…
mysql> show databases;
±-------------------+
| Database |
±-------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
±-------------------+
4 rows in set (0.00 sec)
mysql> source /root/user.sql;
mysql> select * from slave.test;
±—±---------+
| id | name |
±—±---------+
| 1 | xiaoming |
| 2 | xiaohong |
| 3 | xiaolv |
±—±---------+
3 rows in set (0.00 sec)
在从数据库里,使用 change master
配置主从复制:
mysql> stop slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> change master to master_host=‘172.23.3.66’,master_user=‘slave1’,master_password=‘123456’,master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.26 sec)
mysql> start slave;
Query OK, 0 rows affected (0.02 sec)
mysql> show slave status \G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.23.3.66
Master_User: slave1
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 1357
Relay_Log_File: mysql-slave1-relay-bin.000002
Relay_Log_Pos: 417
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
…
…
Executed_Gtid_Set: 317e2aad-1565-11e9-9c2e-005056ac6820:1-5
Auto_Position: 1
由此,Master 和 Slave 节点已经配置了主从同步关系。接下来你可以自行在主库插入一条数据观察从库是否同步过来。
使用 GTID 添加从库有两种方式
直接同步主库所有GTID
如果主库一开始就开启了 GTID,那么可以直接获取主库的所有GTID来同步至从库。但是如果主库 Binlog 日志太多,那么相应同步的时间也会变长。这种方式适用于小数据量的同步。
小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级Java工程师,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助,可以添加下面V无偿领取!(备注Java)
Kafka实战笔记
关于这份笔记,为了不影响大家的阅读体验,我只能在文章中展示部分的章节内容和核心截图
- Kafka入门
- 为什么选择Kafka
- Karka的安装、管理和配置
- Kafka的集群
- 第一个Kafka程序
afka的生产者
- Kafka的消费者
- 深入理解Kafka
- 可靠的数据传递
- Spring和Kalka的整合
- Sprinboot和Kafka的整合
- Kafka实战之削峰填谷
- 数据管道和流式处理(了解即可)
- Kafka实战之削峰填谷
了不影响大家的阅读体验,我只能在文章中展示部分的章节内容和核心截图**
[外链图片转存中…(img-GQGJgiNY-1710408789586)]
- Kafka入门
- 为什么选择Kafka
- Karka的安装、管理和配置
[外链图片转存中…(img-SqXFz7HJ-1710408789587)]
- Kafka的集群
- 第一个Kafka程序
- [外链图片转存中…(img-lZfiZMaZ-1710408789587)]
afka的生产者
[外链图片转存中…(img-oBJEnhfG-1710408789587)]
- Kafka的消费者
- 深入理解Kafka
- 可靠的数据传递
[外链图片转存中…(img-TAnk2lO4-1710408789587)]
[外链图片转存中…(img-CDL1S3Cp-1710408789588)]
- Spring和Kalka的整合
- Sprinboot和Kafka的整合
- Kafka实战之削峰填谷
- 数据管道和流式处理(了解即可)
[外链图片转存中…(img-awrP3oZf-1710408789588)]
- Kafka实战之削峰填谷
[外链图片转存中…(img-Exit8GLk-1710408789588)]