MySQL 8复制性能的增强

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介: 版权声明:本文为博主chszs的原创文章,未经博主允许不得转载。 https://blog.csdn.net/chszs/article/details/79431533 MySQL 8复制性能的增强2018.3.3版权声明:本文为博主chszs的原创文章,未经博主允许不得转载。
版权声明:本文为博主chszs的原创文章,未经博主允许不得转载。 https://blog.csdn.net/chszs/article/details/79431533

MySQL 8复制性能的增强

  • 2018.3.3
  • 版权声明:本文为博主chszs的原创文章,未经博主允许不得转载。

MySQL从5.7版发布后没多久,其8.0版本的开发就提上了日程。MySQL在编号方面跳跃了几个版本,6.0被直接丢弃,7.0被保留用于MySQL的集群版本,因为Oracle官方认为,MySQL 5.6版就相当于6.0版,5.7版就相当于7.0版,因此作为5.7版的下一个版本,直接命名为8.0版也就可以理解了。8.0版这个新版本有许多改变(和bug修复),其中最令人兴奋的是复制性能的增强。本文将概述复制性能增强的特性,包括新增的复制时间戳、性能模式表报告的其他信息,以及通过更新复制线程之间的关系以降低复制延迟的效率,从而降低复制延迟。

新的复制时间戳

管理复制过程中最常见的任务是确保实际上正在发生的复制的顺利进行,并且从设备与主设备之间没有错误。使用的主要语句是“SHOW SLAVE STATUS”,它提供了有关从线程的基本参数的状态信息。因此,必须在每个从设备上执行它。以下是一个输出示例:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: localhost
                  Master_User: root
                  Master_Port: 13000
                Connect_Retry: 60
              Master_Log_File: master-bin.000002
          Read_Master_Log_Pos: 1307
               Relay_Log_File: slave-relay-bin.000003
                Relay_Log_Pos: 1508
        Relay_Master_Log_File: master-bin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
           /   *   /   *   /   *   /
              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:
                ETC...

其中一个输出度量是Seconds_Behind_Master。虽然这完全适用于简单的主从设置,但此度量标准不适合更复杂的复制场景。Seconds_Behind_Master度量有四个主要缺点:

  1. 它只报告从设备和最高层主设备之间的延迟。例如,在链式复制设置中,Seconds_Behind_Master只报告相对于原始主设备的延迟,而不提供任何关于从设备与其最近的中间层注设备之间的延迟的信息。
  2. 它与原始主设备的时区相关。因此,跨时区的服务器的复制会导致测量的延迟被两台服务器之间的时区差异所抵消。
  3. 根据语句的执行开始时间,以每个事件为基础测量延迟。从事务处理实际发生在主事务处理的时间起,更具有洞察力的措施将是每笔事务处理。
  4. 用于度量复制延迟的时间戳只能提供精确到最近的秒数。

MySQL 8引入了两个新的时间戳,这些时间戳Seconds_Behind_Master在规避上述问题时补充了度量标准。这些时间戳与每个事务的全局事务标识符(GTID)相关联(与每个事件相对),写入二进制日志。GTID是创建的唯一标识符,并与源(主)服务器上提交的每个事务相关联。此标识符不仅是其源自的服务器,而且是给定复制设置中的所有服务器的唯一标识符。与事务处理相关联,所有事务处理和所有GTID之间存在1对1的映射关系。

这两个新的时间戳是:

  • 原始提交时间戳(OCT,Original Commit Timestamp):将事务写入原始主服务器的二进制日志时的微秒数(起始时间为1970-01-01T00:00:00Z)
  • 即时提交时间戳(ICT,Immediate Commit Timestamp):事务处理写入即时主机的二进制日志花销的微秒数

mysqlbinlog以两种格式显示新的时间戳:

  1. 微秒数
  2. 在用户时区的TIMESTAMP格式(为了更好的可读性)

从设备的二进制日志中的这段代码显示了两个时间戳:

#170404 10:48:05 server id 1  end_log_pos 233 CRC32 0x016ce647     GTID    
last_committed=0    sequence_number=1    
original_committed_timestamp=1491299285661130    
immediate_commit_timestamp=1491299285843771
# original_commit_timestamp=1491299285661130 (2018-01-04 10:48:05.661130 WEST)
# immediate_commit_timestamp=1491299285843771 (2018-01-04 10:48:05.843771 WEST)
/*!80001 SET @@session.original_commit_timestamp=1491299285661130*//*!*/;
SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'/*!*/;
# at 288

性能模式表报告的新信息

MySQL 8.0对性能模式进行了一些更改,从而获得更好的性能信息和更多的指标信息:

  1. 可以检测服务器错误
  2. 现在支持索引
  3. 可以向现有的性能模式复制状态表添加新的字段

下面详细地探讨这些内容。

检测服务器错误

MySQL 8引入了五个新的汇总表来帮助处理服务器错误,包括:

  • events_errors_summary_by_account_by_error
  • events_errors_summary_by_host_by_error
  • events_errors_summary_by_thread_by_error
  • events_errors_summary_by_user_by_error
  • events_errors_summary_global_by_error

在所有上述表中,错误统计数据都会被错误汇总。此外,除了events_errors_summary_global_by_error之外,每个表都存储与特定用户、主机、帐户或线程相关的错误;events_errors_summary_global_by_error包含整个服务器的错误。

表结构

每个表都包含以下字段:

+-------------------+---------------------+------+-----+---------------------+
| Field             | Type                | Null | Key | Default             |
+-------------------+---------------------+------+-----+---------------------+
| ERROR_NUMBER      | int(11)             | YES  |     | NULL                |
| ERROR_NAME        | varchar(64)         | YES  |     | NULL                |
| SQL_STATE         | varchar(5)          | YES  |     | NULL                |
| SUM_ERROR_RAISED  | bigint(20) unsigned | NO   |     | NULL                |
| SUM_ERROR_HANDLED | bigint(20) unsigned | NO   |     | NULL                |
| FIRST_SEEN        | timestamp           | YES  |     | 0000-00-00 00:00:00 |
| LAST_SEEN         | timestamp           | YES  |     | 0000-00-00 00:00:00 |
+-------------------+---------------------+------+-----+---------------------+

注意:

  • FIRST_SEEN/LAST_SEEN列字段表示第一次和最后一次看到的特定错误。
  • SUM_ERROR_RAISED列字段列出了引发特定错误的次数。
相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
1月前
|
SQL 关系型数据库 MySQL
MySQL 8.0:filesort 性能退化的问题分析
用户将 RDS MySQL 实例从 5.6 升级到 8.0 后,发现相同 SQL 的执行时间增长了十几倍。本文就该问题逐步展开排查,并最终定位根因。
|
1天前
|
存储 关系型数据库 MySQL
提高MySQL查询性能的方法有很多
提高MySQL查询性能的方法有很多
14 6
|
1天前
|
存储 关系型数据库 MySQL
提高MySQL的查询性能
提高MySQL的查询性能
10 4
|
7天前
|
存储 关系型数据库 MySQL
MySQL索引失效及避免策略:优化查询性能的关键
MySQL索引失效及避免策略:优化查询性能的关键
32 3
|
7天前
|
缓存 关系型数据库 MySQL
MySQL数据库优化:提升性能和扩展性的关键技巧
MySQL数据库优化:提升性能和扩展性的关键技巧
18 2
|
7天前
|
监控 关系型数据库 MySQL
如何优化MySQL数据库的索引以提升性能?
如何优化MySQL数据库的索引以提升性能?
17 0
|
2月前
|
SQL 关系型数据库 MySQL
说一下MySQL主从复制的原理?
【8月更文挑战第24天】说一下MySQL主从复制的原理?
52 0
|
2月前
|
SQL 关系型数据库 MySQL
【MySQL 慢查询秘籍】慢SQL无处遁形!实战指南:一步步教你揪出数据库性能杀手!
【8月更文挑战第24天】本文以教程形式深入探讨了MySQL慢SQL查询的分析与优化方法。首先介绍了如何配置MySQL以记录执行时间过长的SQL语句。接着,利用内置工具`mysqlslowlog`及第三方工具`pt-query-digest`对慢查询日志进行了详细分析。通过一个具体示例展示了可能导致性能瓶颈的查询,并提出了相应的优化策略,包括添加索引、缩小查询范围、使用`EXPLAIN`分析执行计划等。掌握这些技巧对于提升MySQL数据库性能具有重要意义。
62 1
|
2月前
|
缓存 关系型数据库 MySQL
在Linux中,如何优化MySQL性能,包括索引优化和查询分析?
在Linux中,如何优化MySQL性能,包括索引优化和查询分析?
|
2月前
|
SQL 存储 关系型数据库
"MySQL增列必锁表?揭秘InnoDB在线DDL,让你的数据库操作飞一般,性能无忧!"
【8月更文挑战第11天】在数据库领域,MySQL凭借其稳定高效的表现深受开发者喜爱。对于是否会在给数据表添加列时锁表的问题,MySQL的行为受版本、存储引擎等因素影响。从5.6版起,InnoDB支持在线DDL,可在改动表结构时保持表的可访问性,避免长时间锁表。而MyISAM等则需锁表完成操作。例如,在使用InnoDB的表上运行`ALTER TABLE users ADD COLUMN email VARCHAR(255);`时,通常不会完全锁表。虽然在线DDL提高了灵活性,但复杂操作或大表变更仍可能暂时影响性能。因此,进行结构变更前应评估其影响并择机执行。
53 6
下一篇
无影云桌面