MySQL的GTID复制怎么应用

网友投稿 385 2023-11-25

MySQL的GTID复制怎么应用

这篇文章主要介绍“MySQL的GTID复制怎么应用”的相关知识,小编通过实际案例向大家展示操作过程,操作方法简单快捷,实用性强,希望这篇“MySQL的GTID复制怎么应用”文章能帮助大家解决问题。

MySQL的GTID复制怎么应用

从MySQL 5.6.5开始新增了一种基于GTID的复制方式。通过GTID保证了每个在主库上提交的事务在集群中有一个唯一的ID。这种方式强化了数据库的主备一致性,故障恢复以及容错能力。

GTID是什么

GTID (Global Transaction ID) 是对于一个已提交事务的编号,并且是一个全局唯一的编号。 GTID实际上是由UUID+TID 组成的。其中UUID是一个 MySQL实例的唯一标识。TID代表了该实例上已经提交的事务数量,并且随着事务提交单调递增。

下面是一个GTID的具体形式:3E11FA47-71CA-11E1-9E33-C80AA9429562:23,冒号分割前边为uuid,后边为TID。

GTID集合可以包含来自多个MySQL实例的事务,它们之间用逗号分隔。

如果来自同一MySQL实例的事务序号有多个范围区间,各组范围之间用冒号分隔。例如:e6954592-8dba-11e6-af0e-fa163e1cf111:1-5:11-18,e6954592-8dba-11e6-af0e-fa163e1cf3f2:1-27。

GTID改进有哪些

在原来基于二进制日志的复制中,从库需要告知主库要从哪个偏移量进行增量同步,如果指定错误会造成数据的遗漏,从而造成数据的不一致。借助GTID,在发生主备切换的情况下,MySQL的其它从库可以自动在新主库上找到正确的复制位置,这大大简化了复杂复制拓扑下集群的维护,也减少了人为设置复制位置发生误操作的风险。另外,基于GTID的复制可以忽略已经执行过的事务,减少了数据发生不一致的风险。

主库基于gtid set可以准确的知道从库缺少哪些数据,不会多给从库数据,也不会少给,避免网络带宽浪费。

mysql主从结构在一主一从情况下对于GTID来说就没有优势了,而对于2台主以上的结构优势异常明显,可以在数据不丢失的情况下切换新主。

注意:在构建主从复制之前,在一台将成为主的实例上进行一些操作(如数据清理等),通过GTID复制,这些在主从成立之前的操作也会被复制到从服务器上,引起复制失败。也就是说通过GTID复制都是从最先开始的事务日志开始,即使这些操作在复制之前执行。比如在server1上执行一些drop、delete的清理操作,接着在server2上执行change的操作,会使得server2也进行server1的清理操作。

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,确保不被重复执行。

一主一从GTID复制的搭建

主机规划:

master:docker,端口3312

slave:docker,端口3313

master的配置

配置文件my-f内容如下:

$ cat /home/mysql/docker-data/3313/conf/my-f # For advice on how to change settings please see # http://dev.mysql.com/doc/refman/5.7/en/server-configuration-defaults.html [mysqld] # # Remove leading # and set to the amount of RAM for the most important data # cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%. # innodb_buffer_pool_size = 128M # # Remove leading # to turn on a very important data integrity option: logging # changes to the binary log between backups. # log_bin # # Remove leading # to set options mainly useful for reporting servers. # The server defaults are faster for transactions and fast SELECTs. # Adjust sizes as needed, experiment to find the optimal values. # join_buffer_size = 128M # sort_buffer_size = 2M # read_rnd_buffer_size = 2M #datadir=/home/mysql/docker-data/3307/data #socket=/home/mysql/docker-data/3307/mysql.sock character_set_server=utf8 init_connect=SET NAMES utf8 # Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links=0 #log-error=/home/mysql/docker-data/3307/logs/mysqld.log #pid-file=/home/mysql/docker-data/3307/mysqld.pid lower_case_table_names=1 server-id=1403311 log-bin=mysql-bin binlog-format=ROW auto_increment_increment=1 auto_increment_offset=1 # 开启gtid gtid_mode=ON enforce-gtid-consistency=true #rpl_semi_sync_master_enabled=1 #rpl_semi_sync_master_timeout=10000

创建docker实例:

$ docker run --name mysql3312 -p 3312:3306 --privileged=true-ti -e MYSQL_root_PASSWORD=root -e MYSQL_DATABASE=order -e MYSQL_USER=user -e MYSQL_PASSWORD=pass -v /home/mysql/docker-data/3312/conf:/etc/mysql/conf.d -v /home/mysql/docker-data/3312/data/:/var/lib/mysql-v /home/mysql/docker-data/3312/logs/:/var/log/mysql -d mysql:5.7

添加用于复制的用户并授权:

mysql>GRANT REPLICATION SLAVE,FILE,REPLICATION CLIENT ON *.* TOrepluser@% IDENTIFIED BY 123456;Query OK, 0 rows affected, 1 warning (0.01 sec) mysql> FLUSH PRIVILEGES; Query OK, 0 rows affected (0.01 sec)

slave的配置

配置文件my-f内容与master一致,注意修改server-id,保持唯一。

创建docker实例:

$ docker run --name mysql3313 -p 3313:3306 --privileged=true-ti -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=order -e MYSQL_USER=user -e MYSQL_PASSWORD=pass -v /home/mysql/docker-data/3313/conf:/etc/mysql/conf.d -v /home/mysql/docker-data/3313/data/:/var/lib/mysql-v /home/mysql/docker-data/3313/logs/:/var/log/mysql -d mysql:5.7

开启GTID同步:

mysql>change master to master_host=172.23.252.98,master_port=3310,master_user=repluser,master_password=123456,master_auto_position=1;Query OK, 0 rows affected, 2 warnings (0.02 sec) mysql> start slave;Query OK, 0 rows affected (0.02 sec)

查看状态:

mysql> show master status; +------------------+----------+--------------+------------------+----------------------------------------+ | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                      | +------------------+----------+--------------+------------------+----------------------------------------+ | mysql-bin.000008 |      154 |              |                  | cd2eaa0a-7a59-11ec-b3b4-0242ac110002:1 | +------------------+----------+--------------+------------------+----------------------------------------+ 1 row in set (0.00 sec) mysql> show slave status\G; *************************** 1. row ***************************                Slave_IO_State: Waiting for master to send event                   Master_Host: 172.23.252.98                   Master_User: repluser                   Master_Port: 3312                 Connect_Retry: 60               Master_Log_File: mysql-bin.000006           Read_Master_Log_Pos: 419                Relay_Log_File: 5dfbef024732-relay-bin.000003                 Relay_Log_Pos: 632         Relay_Master_Log_File: mysql-bin.000006              Slave_IO_Running: Yes             Slave_SQL_Running: Yes               Replicate_Do_DB:           Replicate_Ignore_DB:            Replicate_Do_Table:        Replicate_Ignore_Table:       Replicate_Wild_Do_Table:   Replicate_Wild_Ignore_Table:                    Last_Errno: 0                    Last_Error:                  Skip_Counter: 0           Exec_Master_Log_Pos: 419               Relay_Log_Space: 846               Until_Condition: None                Until_Log_File:                 Until_Log_Pos: 0            Master_SSL_Allowed: No            Master_SSL_CA_File:            Master_SSL_CA_Path:               Master_SSL_Cert:             Master_SSL_Cipher:                Master_SSL_Key:         Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No                 Last_IO_Errno: 0                 Last_IO_Error:                Last_SQL_Errno: 0                Last_SQL_Error:   Replicate_Ignore_Server_Ids:              Master_Server_Id: 1403311                   Master_UUID: cd2eaa0a-7a59-11ec-b3b4-0242ac110002              Master_Info_File: /var/lib/mysql/master.info                     SQL_Delay: 0           SQL_Remaining_Delay: NULL       Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates            Master_Retry_Count: 86400                   Master_Bind:       Last_IO_Error_Timestamp:      Last_SQL_Error_Timestamp:                Master_SSL_Crl:            Master_SSL_Crlpath:            Retrieved_Gtid_Set: cd2eaa0a-7a59-11ec-b3b4-0242ac110002:1             Executed_Gtid_Set: cd2eaa0a-7a59-11ec-b3b4-0242ac110002:1                 Auto_Position: 1          Replicate_Rewrite_DB:                  Channel_Name:            Master_TLS_Version: 1 row in set (0.00 sec)

在master.order表插入数据:

mysql> insert into t_order values(4,"V");

发现数据已经同步至slave:

mysql> select* from order.t_order; +------+------+ | id   | name | +------+------+ |    4 | V    | +------+------+ 3 rows inset (0.00 sec)

先停止slave,再在master.order表插入数据:

mysql> insert into t_order values(5,"X");

然后再启动slave,发现数据已自动同步:

mysql> stop slave; Query OK, 0 rows affected (0.01 sec) mysql> select * from order.t_order; +------+------+ | id   | name | +------+------+ |    4 | V    | +------+------+ 3 rows in set (0.00 sec) mysql> start slave; Query OK, 0 rows affected (0.02 sec) mysql> select * from order.t_order; +------+------+ | id   | name | +------+------+ |    4 | V    | |    5 | X    | +------+------+ 4 rows in set (0.00 sec)

遇到的问题

在slave服务器show slave status:

Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs;these UUIDs must be different for replication to work.

首先检查master和slave的server_id是否一致,如果一致去修改my-f文件中的server_id字段:

mysql> show variables like server_id;

然后排查master和slave的uuid是否一致:

mysql> show variables like %uuid%;

如果uuid一致去修改data目录下的auto-f文件,拷贝整个data目录,把auto-f文件也拷贝过来了,里面记录了数据库的uuid,每个库的uuid应该是不一样的。

关于“MySQL的GTID复制怎么应用”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识,可以关注行业资讯频道,小编每天都会为大家更新不同的知识点。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:巨杉数据库入选中国数据管理生态报告
下一篇:在国产数据库安全自主可控的路上,科蓝SUNDB砥砺前行
相关文章

 发表评论

暂时没有评论,来抢沙发吧~