MySQL8.3 可以给 GTID 打标签了!
本文介绍了 MySQL 8.3 的一个新特性,给 GTID 打标签~
作者:李富强,爱可生 DBA 团队成员,熟悉 MySQL,TiDB,OceanBase 等数据库。相信持续把对的事情做好一点,会有不一样的收获。
爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。
本文约 900 字,预计阅读需要 3 分钟。
摘要
MySQL 8.3 创新版于 2024 年 1 月 16 号发布,该版本扩展了 MySQL 复制和组复制中使用全局事务标识(GTID)的格式,支持给 GTID 打标签,以支持识别事务组。此增强功能可以为特定事务组的 GTID 分配唯一标识。例如:包含数据操作的事务可以很容易地与管理操作产生的事务区分开来,只需要比较他们的 GTID。
GTID 格式
原始格式
原始 GTID 格式是 source_id:transaction_id
- source_id 标识源服务器,通常用 server_uuid 表示。
- transaction_id 代表事务在源上提交的顺序,例如要提交第一个事务的 transaction_id 为 1,要在同一源服务器上提交的第十个事务的 transaction_id 就是 10。
全局唯一标识符(GTID)是创建并与源服务器上提交的每个事务相关联的唯一标识符。此标识符不仅对其发起的服务器是唯一的,在给定复制拓扑中所有服务器上都是唯一的。
带标签的格式
扩展后的 GTID 格式是 source_id:<tag>:transaction_id,其中 tag 是最长为 8 个字符的任意字符串。通过设置系统变量 gtid_next 的值为 automatic:<tag> 启用,或者设置 gtid_next 为 uuid:<tag>:transaction_id 以将单个事务的 uuid 设置为任意值,并为其分配自定义标签。
操作实验
通过 mysql-shell 工具,快速部署一个 MySQL 8.3 版本的实例(过程略)。
参数 | 参数值 |
---|---|
主机 IP | 10.186.58.39 |
主机名 | node 1 |
端口 | 3333 |
MySQL 版本 | 8.3.0 |
环境查看
#node1 SQL > select @@hostname,@@version,@@port,@@gtid_mode,@@gtid_executed; +------------+-----------+--------+-------------+------------------------------------------+ | @@hostname | @@version | @@port | @@gtid_mode | @@gtid_executed | +------------+-----------+--------+-------------+------------------------------------------+ | node1 | 8.3.0 | 3333 | ON | +------------+-----------+--------+-------------+------------------------------------------+
给 GTID 打标签,以创建一个用户并赋权操作举例(管理操作)。
#创建用户和赋权操作,给 GTID 打的标签为 dba SQL > set gtid_next="AUTOMATIC:dba"; Query OK, 0 rows affected (0.0032 sec) SQL > create user dba@'%' identified with mysql_native_password by 'dba'; Query OK, 0 rows affected (0.0332 sec) SQL > select @@hostname,@@version,@@port,@@gtid_mode,@@gtid_executed; +------------+-----------+--------+-------------+------------------------------------------------+ | @@hostname | @@version | @@port | @@gtid_mode | @@gtid_executed | +------------+-----------+--------+-------------+------------------------------------------------+ | node1 | 8.3.0 | 3333 | ON | a45d9e72-c33b-11ee-a645-02000aba3a27:dba:1 | +------------+-----------+--------+-------------+------------------------------------------------+ SQL > grant all privileges on *.* to dba@'%'; Query OK, 0 rows affected (0.0126 sec) SQL > select @@hostname,@@version,@@port,@@gtid_mode,@@gtid_executed; +------------+-----------+--------+-------------+--------------------------------------------------+ | @@hostname | @@version | @@port | @@gtid_mode | @@gtid_executed | +------------+-----------+--------+-------------+--------------------------------------------------+ | node1 | 8.3.0 | 3333 | ON | a45d9e72-c33b-11ee-a645-02000aba3a27:dba:1-2 | +------------+-----------+--------+-------------+--------------------------------------------------+
小结:a45d9e72-c33b-11ee-a645-02000aba3a27:dba:1 和 a45d9e72-c33b-11ee-a645-02000aba3a27:dba:2 这两个 GTID 是我们创建用户并赋权的操作,可以简单理解为 dba:1-2 这两个事务(打标签事务)。
切换为原始 GTID 生成模式,执行创建库和表操作(业务操作)。
#执行创建库,表操作 SQL > set gtid_next="AUTOMATIC"; Query OK, 0 rows affected (0.0032 sec) SQL > create database lfq; Query OK, 1 row affected (0.0182 sec) SQL > select @@hostname,@@version,@@port,@@gtid_mode,@@gtid_executed; +------------+-----------+--------+-------------+--------------------------------------------------+ | @@hostname | @@version | @@port | @@gtid_mode | @@gtid_executed | +------------+-----------+--------+-------------+--------------------------------------------------+ | node1 | 8.3.0 | 3333 | ON | a45d9e72-c33b-11ee-a645-02000aba3a27:1:dba:1-2 | +------------+-----------+--------+-------------+--------------------------------------------------+ SQL > create table lfq.t1(c1 int primary key ,c2 varchar(10)); Query OK, 0 rows affected (0.0685 sec) SQL > select @@hostname,@@version,@@port,@@gtid_mode,@@gtid_executed; +------------+-----------+--------+-------------+--------------------------------------------------+ | @@hostname | @@version | @@port | @@gtid_mode | @@gtid_executed | +------------+-----------+--------+-------------+--------------------------------------------------+ | node1 | 8.3.0 | 3333 | ON | a45d9e72-c33b-11ee-a645-02000aba3a27:1-2:dba:1-2 | +------------+-----------+--------+-------------+--------------------------------------------------+
小结:a45d9e72-c33b-11ee-a645-02000aba3a27:1:dba:1-2 和 a45d9e72-c33b-11ee-a645-02000aba3a27:2:dba:1-2 这两个 GTID 是我们创建库,表的操作,可以简单理解为 a45d9e72-c33b-11ee-a645-02000aba3a27:1-2 这两个事务(非打标签事务)。
总结
- 通过对 GTID 打标签,可以比较容易地把包含管理操作产生的事务与数据操作的事务区分开来。
- 功能略微简单,期待相关功能的进一步丰富。
更多技术文章,请访问:https://opensource.actionsky.com/
关于 SQLE
SQLE 是一款全方位的 SQL 质量管理平台,覆盖开发至生产环境的 SQL 审核和管理。支持主流的开源、商业、国产数据库,为开发和运维提供流程自动化能力,提升上线效率,提高数据质量。
SQLE 获取

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
数仓的等待视图中,为什么会有Hashjoin-nestloop
本文分享自华为云社区《GaussDB(DWS)等待视图之Hashjoin-nestloop》,作者:Arrow0lf。 1. 业务场景 众所周知,GaussDB(DWS)中有3种常见的join方式:HashJon/MergeJoin/NestLoop 但在有一些场景中,等待视图中等待状态会显示为:HashJoin-nestloop,如下图所示。这种表示什么含义? 2. 基本原理 为了明白该状态的原因,首先思考如下场景:当业务侧两张大表join时,如果由于未做analyze或统计信息不准,导致build hash的一侧选择了大表,且该表在join列上重复值很多,会导致hashjoin时内存膨胀,当内存不足时,hashjon算子会下盘,但是由于join列上存在大量重复值,下盘文件无法有效分裂,此时,如果将整个文件都读取到内存中,会导致内存占用很高,出现内存过载,导致其他业务内存不足报错。 为了解决该场景,在向量化hashjoin时,当使用内表创建的hash表过大导致内存不足时,不再强制进行hashjoin,会通过内外表交换或执行nestloop使查询平稳进行,防止出现内存报错,此时,等待视...
- 下一篇
教你如何用Keepalived和HAproxy配置高可用 Kubernetes 集群
本文分享自华为云社区《使用 Keepalived 和 HAproxy 创建高可用 Kubernetes 集群》,作者:江晚正愁余。 高可用 Kubernetes 集群能够确保应用程序在运行时不会出现服务中断,这也是生产的需求之一。为此,有很多方法可供选择以实现高可用。 本教程演示了如何配置 Keepalived 和 HAproxy 使负载均衡、实现高可用。步骤如下: 准备主机。 配置 Keepalived 和 HAproxy。 使用 KubeKey 创建 Kubernetes 集群,并安装 KubeSphere。 集群架构 示例集群有三个主节点,三个工作节点,两个用于负载均衡的节点,以及一个虚拟 IP 地址。本示例中的虚拟 IP 地址也可称为“浮动 IP 地址”。这意味着在节点故障的情况下,该 IP 地址可在节点之间漂移,从而实现高可用。 请注意,在本示例中,Keepalived 和 HAproxy 没有安装在任何主节点上。但您也可以这样做,并同时实现高可用。然而,配置两个用于负载均衡的特定节点(您可以按需增加更多此类节点)会更加安全。这两个节点上只安装 Keepalived 和 HA...
相关文章
文章评论
共有0条评论来说两句吧...