MySQL主从部署-gitid模式

Posted Joker Life - SunnyDou

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MySQL主从部署-gitid模式相关的知识,希望对你有一定的参考价值。

简介

GTID工作原理简单介绍

1.master更新数据的时候,会在事务前产生GTID,一同记录到binlog日志中。

2.slave端的io线程将binlog写入到本地relay log中。

3.然后SQL线程从relay log中读取GTID,设置gtid_next的值为该gtid,然后对比slave端的binlog是否有记录

4.如果有记录的话,说明该GTID的事务已经运行,slave会忽略

5.如果没有记录的话,slave就会执行该GTID对应的事务,并记录到binlog中

GTID工作原理深入理解

gtid在master和slave上持久化保存,即使删除了日志,也会记录到previous_gtid中。

1.binlog文件中记录的格式是先记录gtid,然后再记录事务相关的操作。

2.gtid_next 是基于会话的,不同会话的gtid_next不同。

3.如果mysql是5.6版本,那么主从必须开启log_slave_updates参数,此时slave对比自己的binlog查看是否有记录。如果mysql是5.7版本,那么主从不需要开启此参数(级联主从除外),mysql5.7提供了gtid_excuted系统表来记录复制的信息,以此减少从库的压力。

GTID模式的主从配置介绍

主从服务同时开启gtid模式

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

GTID (Global Transaction ID)是全局事务ID,当在主库上提交事务或者被从库应用时,可以定位和追踪每一个事务,对DBA来说意义就很大了,我们可以适当的解放出来,不用手工去可以找偏移量的值了,而是通过CHANGE MASTER TO MASTER_HOST=\'xxx\', MASTER_AUTO_POSITION=1的即可方便的搭建从库,在故障修复中也可以采用MASTER_AUTO_POSITION=‘X’的方式。

可能大多数人第一次听到GTID的时候会感觉有些突兀,但是从架构设计的角度,GTID是一种很好的分布式ID实践方式,通常来说,分布式ID有两个基本要求:

1)全局唯一性

2)趋势递增

这个ID因为是全局唯一,所以在分布式环境中很容易识别,因为趋势递增,所以ID是具有相应的趋势规律,在必要的时候方便进行顺序提取,行业内适用较多的是基于Twitter的ID生成算法snowflake,所以换一个角度来理解GTID,其实是一种优雅的分布式设计。

如何开启GTID?

如何开启GTID呢,我们先来说下基础的内容,然后逐步深入,通常来说,需要在my.cnf中配置如下的几个参数:

  • server_id=1

  • log-bin

  • gtid_mode=ON

  • enforce_gtid_consistency=1

部署

修改配置文件

主节点编辑配置文件,添加参数:

[root@localhost tmp]# vim /etc/my.cnf
[mysqld]
log_bin
server_id=1
gtid_mode=ON
enforce_gtid_consistency=1

[root@localhost tmp]# systemctl restart mysqld    # 重启mysql生效

从节点编辑配置文件,添加参数:

[root@localhost tmp]# vim /etc/my.cnf  # 编辑配置文件
[mysqld]
# log_bin          # 从服务器log_bin可开可不开,不影响复制功能
server_id=2      # 注意id的唯一性
gtid_mode=ON
enforce_gtid_consistency=1

[root@localhost tmp]# systemctl restart mysqld    # 重启mysql生效

配置用户

主节点配置rep用户:

grant replication slave,replication client on *.* to \'rep\'@\'%\'; # mysql5和8的用户创建命令不同,此处注意。

设置从服务器主从关系

从节点上进行操作:

#二进制文件位置由master_auto_position=1参数自动确定
mysql> change master to master_host=\'192.168.137.100\',master_user=\'rep\',master_password=\'test@A123456\',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

mysql> show slave status\\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.137.100
                  Master_User: rep
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: localhost-bin.000003
          Read_Master_Log_Pos: 154
               Relay_Log_File: localhost-relay-bin.000002
                Relay_Log_Pos: 375
        Relay_Master_Log_File: localhost-bin.000003
             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: 154
              Relay_Log_Space: 586
              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: 1
                  Master_UUID: d4194c0e-35e2-11eb-a021-000c291c0d9f
             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: 
            Executed_Gtid_Set: 
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
1 row in set (0.00 sec)

到此MySQL主从模式已经配置完成。

注意:
在从库上执行 show slave status\\G
显示报错:
Last_IO_Error: error connecting to master \'rep@127.0.0.1:3316\' - retry-time: 60 retries: 2 message: Authentication plugin \'caching_sha2_password\' reported error: Authentication requires secure connection.
考虑到我的MySQL8 ,
查看主库:
SELECT plugin FROM user where user = \'rep\';
原来是主库rep的plugin是caching_sha2_password 导致连接不上,修改为mysql_native_password即可解决。
ALTER USER \'rep\'@\'%\' IDENTIFIED WITH mysql_native_password BY \'root\';

本文来自博客园,作者:sunnydoy,转载请注明原文链接:https://www.cnblogs.com/sunnydou/p/15145475.html

以上是关于MySQL主从部署-gitid模式的主要内容,如果未能解决你的问题,请参考以下文章

mysql 主从模式总结

k8s1.19.16部署mysql5.7.35主从架构做数据持久化

MySQL的主从复制+双主模式

MySQL数据库主从热备部署心得

运维实战案例 容器部分 使用Statefulset部署MySQL主从集群

运维实战案例 容器部分 使用Statefulset部署MySQL主从集群