学习下mariadb，搭建下主从，mariadb gtid的和mysql的gtid不一样
在MariaDB中，GTID由三部分组成，三部分之间用’-‘分隔，例如0-161002-1:
struct rpl_gtid
{
uint32 domain_id;
uint32 server_id;
uint64 seq_no;
};
第一个是无符号32位整数的domain_id，在多源复制、多主拓扑复制中每个会写入的Master通常需要设置不同的Domain_id。
第二个是无符号32位整数的server_id，集群中每个server需要设置唯一的server id，标识最初写入binlog的server，用来避免循环复制。
第三个是服务号64位整数的seq_no，seq_no在每个写入server产生binlog中是递增的。
1、主库执行备份
[root@fis10serverbak mysqld_exporter]# mysqldump -uroot -p***l --port=33061 -h10.1.5.3 --single-transaction --routines --master-data=2 -B test45bg wf >20221122.sql
master-data=2 #表示会带如下所示的关键字，并且是以注释的方式存在：
-- Position to start replication or point-in-time recovery from
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000065', MASTER_LOG_POS=378099089;
-- GTID to start replication from
-- SET GLOBAL gtid_slave_pos='0-1133306110-5468601';
2、slave执行恢复操作
mysql -uroot -pmysql --port=33061 -h10.1.5.3 <20221122.sql
3、change 命令
CHANGE MASTER TO MASTER_HOST='172:29:7::e02',MASTER_USER='replusr',MASTER_PASSWORD='replusr',MASTER_PORT=3306,MASTER_CONNECT_RETRY=10,MASTER_USE_GTID = slave_pos; #选择slave_pos的方式，这样更安全
4、设置从库的gtid, 设置这个不需要像社区mysql那样先reset master，然后再SET @@GLOBAL.GTID_PURGED;只需要在stop slave状态下即可！
MariaDB [(none)]> SET GLOBAL gtid_slave_pos='0-1133306110-5468601';
确认是否设置成功！
MariaDB [(none)]> SELECT @@GLOBAL.gtid_slave_pos;
+---------------------------------------+
| @@GLOBAL.gtid_slave_pos |
+---------------------------------------+
| 0-1133306110-5468601 |
+---------------------------------------+
5、start slave即可！
MariaDB [(none)]> start slave;
注意
1、
如果有多个主库，需要保证上游多个主库的gtid_domain_id是不一样的！可以如下这样设置，建议配置到配置文件中
MariaDB [(none)]> set global gtid_domain_id=1;
Query OK, 0 rows affected (0.000 sec)
2、如下查询可以判断出，该节点的作为主库执行的事务的gtid为
2-1113306120-2这俩！
MariaDB [(none)]> select @@global.gtid_binlog_pos; #节点执行过的所有的事务的gtid，最后写入到binlog中的GTID，包括作为从库同步主库的gtid，也包括自己作为主库执行的事务的gtid，
+--------------------------------------------------------+
| @@global.gtid_binlog_pos |
+--------------------------------------------------------+
| 0-1133306110-5471555,1-1133306110-13388,
2-1113306120-2 |
+--------------------------------------------------------+
1 row in set (0.000 sec)
MariaDB [(none)]> SELECT @@GLOBAL.gtid_slave_pos; #节点作为从库同步主库的事务的gtid；不包括自己作为主库执行的gtid
+-----------------------------------------+
| @@GLOBAL.gtid_slave_pos |
+-----------------------------------------+
| 0-1133306110-5471555,1-1133306110-13388 |
+-----------------------------------------+
1 row in set (0.000 sec)
4、注意：一定要保证所有的机器gtid_domain_id唯一，server_id唯一！如下是测试过程，
#主库的gtid_domain_id=1
然后去从库也设置gtid_domain_id=1
MariaDB [liuwenhe]> set gtid_domain_id=1;
Query OK, 0 rows affected (0.000 sec)
在从库模拟一个dml操作
MariaDB [liuwenhe]> insert into liuwenhe values (1);
Query OK, 1 row affected (0.001 sec)
你就会发现，刚开始1-1113306120-627 这个就是前面insert的事务
MariaDB [liuwenhe]> select @@global.gtid_binlog_pos;
+------------------------------------------------------+
| @@global.gtid_binlog_pos |
+------------------------------------------------------+
| 0-1133306110-5470703,1-1113306120-627,2-1113306120-2 |
+------------------------------------------------------+
1 row in set (0.000 sec)
持续查，就会发现等上游事务同步过来之后，就会覆盖掉1-1113306120-627，而变成1-1133306110-631了，中
间的server_id=1133306110是主库的！
MariaDB [liuwenhe]> select @@global.gtid_binlog_pos;
+------------------------------------------------------+
| @@global.gtid_binlog_pos |
+------------------------------------------------------+
| 0-1133306110-5470703,1-1113306120-627,2-1113306120-2 |
+------------------------------------------------------+
1 row in set (0.000 sec)
MariaDB [liuwenhe]> select @@global.gtid_binlog_pos;
+------------------------------------------------------+
| @@global.gtid_binlog_pos |
+------------------------------------------------------+
| 0-1133306110-5470707,1-1133306110-631,2-1113306120-2 |
+------------------------------------------------------+
1 row in set (0.000 sec)
MariaDB [liuwenhe]> select @@global.gtid_binlog_pos;
+------------------------------------------------------+
| @@global.gtid_binlog_pos |
+------------------------------------------------------+
| 0-1133306110-5470707,1-1133306110-631,2-1113306120-2 |
+------------------------------------------------------+
1 row in set (0.000 sec)
但是你再insert一条数据，就会发现又变成了从库的server_id，变成1-1113306120-632，
MariaDB [liuwenhe]>insert into liuwenhe values (2);
MariaDB [liuwenhe]> select @@global.gtid_binlog_pos;
+------------------------------------------------------+
| @@global.gtid_binlog_pos |
+------------------------------------------------------+
| 0-1133306110-5470707,1-1113306120-632,2-1113306120-2 |
+------------------------------------------------------+
1 row in set (0.000 sec)
这样不利于排查问题，所以建议保持所有的机器gtid_domain_id唯一，server_id唯一，
编辑推荐：
- mariadb gtid方式搭建从库03-01
- 一条SQL查询语句是如何执行的？03-01
- 好好的系统，为什么要分库分表？03-01
- SQL 不知道咋优化？吹一手 join 语句的优化准没错03-01
- SQL 语句的注意事项03-01
- 为什么阿里巴巴禁止数据库中做多表join？03-01
- 趣说 ｜ 数据库和缓存如何保证一致性？03-01
- DBMotion——MySQL迁移利器03-01
下一篇：
相关推荐
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
雷神推出 MIX PRO II 迷你主机：基于 Ultra 200H，玻璃上盖 + ARGB 灯效
2 月 9 日消息，雷神 (THUNDEROBOT) 现已宣布推出基于英
-
制造商 Musnap 推出彩色墨水屏电纸书 Ocean C：支持手写笔、第三方安卓应用
2 月 10 日消息，制造商 Musnap 现已在海外推出一款 Oce
热文推荐
- 一条SQL查询语句是如何执行的？
一条SQL查询语句是如何执行的？
26-03-01 - 好好的系统，为什么要分库分表？
好好的系统，为什么要分库分表？
26-03-01 - SQL 不知道咋优化？吹一手 join 语句的优化准没错
SQL 不知道咋优化？吹一手 join 语句的优化准没错
26-03-01 - 为什么阿里巴巴禁止数据库中做多表join？
为什么阿里巴巴禁止数据库中做多表join？
26-03-01 - 趣说 ｜ 数据库和缓存如何保证一致性？
趣说 ｜ 数据库和缓存如何保证一致性？
26-03-01 - DBMotion——MySQL迁移利器
DBMotion——MySQL迁移利器
26-03-01 - MySQL优化的5个维度
MySQL优化的5个维度
26-03-01 - 看完这篇还不懂 MySQL 主从复制，可以回家躺平了～
看完这篇还不懂 MySQL 主从复制，可以回家躺平了～
26-03-01 - 换一个角度看 B+ 树
换一个角度看 B+ 树
26-03-01 - 阿里云——云数据库RDS
阿里云——云数据库RDS
26-03-01