首页 文章 精选 留言 我的

精选列表

搜索[精准预约]，共7953篇文章
优秀的个人博客,低调大师

八怪：再谈 MySQL 8 这两个精准的时间戳

MySQL 8.0 的 binlog 中多了 immediate_commit_timestamp 和 original_commit_timestamp 的信息，网上也有很多文章进行解释，最近也刚好遇到相关问题，刚好稍微学习一下。 作者：高鹏（八怪），《MySQL 主从原理》作者，深入透彻理解 MySQL 主从，GTID 相关技术知识。 爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 本文共约 1700 字，预计阅读需要 6 分钟。 相关解释 **immediate_commit_timestamp：**代表是当前数据库提交的时间，从库/主库都分别代表其提交的时间。 **original_commit_timestamp：**代表主库提交的时间，不管有多少级联的从库这个时间永远是主库提交事务时候的时间。当然在主库上其就等于 immediate_commit_timestamp 的时间。 它们的生成时间都是在从 binlog cache 写入到 binlog 文件的时候，生成 GTID event 的时候，也就是 commit 的 flush 阶段，我们简称这个为 提交时间。 但是需要注意的是 MGR 中主库的 original_commit_timestamp 和 immediate_commit_timestamp 生成稍有提前（group_replication_trans_before_commit），并不是这里说的提交时间。 生成流程 2.1 关于 thd->variables.original_commit_timestamp 因为 original_commit_timestamp 来自这个值，一般情况下其值都是 UNDEFINED_COMMIT_TIMESTAMP，但是从库上这个值会在应用 GTID event 的时候更改为主库带过来的 original_commit_timestamp，因为主库 original_commit_timestamp 就是提交时间，因此从库的 thd->variables.original_commit_timestamp 也就设置为了主库的提交时间。 但是有一个例外，就是 5.7 向 8.0 同步的时候，因为没有这个值因此会被设置为 0。如下： # original_commit_timestamp=0 (1970-01-01 08:00:00.000000 CST) # immediate_commit_timestamp=1703237689977004 (2023-12-22 17:34:49.977004 CST) 2.2 生成方式 这个其实比较简单，就是在函数 MYSQL_BIN_LOG::write_transaction 中生成的，大概为： immediate_commit_timestamp = 获取的当前时间 original_commit_timestamp = thd->variables.original_commit_timestamp （前面描述了thd->variables.original_commit_timestamp主库不会设置为特定的值，其为 UNDEFINED_COMMIT_TIMESTAMP） 如果 original_commit_timestamp 等于 UNDEFINED_COMMIT_TIMESTAMP，那么它就是主库，应该将设置 original_commit_timestamp = immediate_commit_timestamp，这样主库的 original_commit_timestamp 和 immediate_commit_timestamp 就相同了 否则 original_commit_timestamp 有特定的值，那么就是从库，因为这个值来自 thd->variables.original_commit_timestamp，前面说了他是应用 GTID event 的值。 2.3 相关警告 当发现从库的提交时间还比主库的提交时间更慢的时候，显然这是不合适的，就会出现这个警告如下： if (original_commit_timestamp > immediate_commit_timestamp && !thd->rli_slave->get_c_rli()->gtid_timestamps_warning_logged) { //如果原始时间 还在于了当前服务器的提交时间，这是常见的警告 LogErr(WARNING_LEVEL, ER_INVALID_REPLICATION_TIMESTAMPS); //则报警 这就是大家经常遇到的警告。 Invalid replication timestamps: original commit timestamp is more recent than the immediate commit timestamp. This may be an issue if delayed replication is active. Make sure that servers have their clocks set to the correct time. No further message will be emitted until after timestamps become valid again." 其运维中的意义 3.1 在延时从库中的应用 如果配置了延迟从库，则使用的是 immediate_commit_timestamp 作为延迟从库应用 event 的计算标准，因为这里 event 来自 relay log，因此 immediate_commit_timestamp 是 IO 线程连接库（A->B->C，C 为延迟从库，则这里为B库提交事务的时间）的事务提交时间，在函数 sql_delay_event 中有如下计算方式： sql_delay_end = ceil((static_cast<Gtid_log_event *>(ev) ->immediate_commit_timestamp) / 1000000.00) + sql_delay; 而对于不支持的延时从库则计算为： sql_delay_end = ev->common_header->when.tv_sec + rli->mi->clock_diff_with_master + sql_delay; 对于 immediate_commit_timestamp 和 ev->common_header->when.tv_sec 是有很大区别的，后者为 binlog header 中 timestamp 的时间，其在整个复制链路中并不会改变，其几乎为命令发起的时间，而不是事务提交的时间。我们以 A->B->C 为列，其中 C 为一个延迟从库。 支持 immediate_commit_timestamp 的情况：C 的延迟计算是以B库提交时刻的时间为计算标准的。也就是其延迟是 B 库提交后多久 C 库应用。 不支持 immediate_commit_timestamp 的情况：C 的延迟计算是以 A 库命令发起的时间为计算标准的。也就是其延迟是 A 库命令发起后多久 C 库应用。 很显然前者的计算方式更为靠谱。在延迟从库在等待的时候其线程的状态为： Waiting until MASTER_DELAY seconds after master executed event 3.2 主库判定事务的提交时刻和语句发起时间 某些时候我们可能需要知道语句什么时候发起执行的，什么时候提交完成的，这个时候我们考虑使用 immediate_commit_timestamp 和 event header 的 timestamp 进行对比。 对于自动提交的 DML 语句，则 GTID event header 的 timestamp 为语句发起的时间，而 GTID event 的 immediate_commit_timestamp 为事务提交的时间，如果差值太大，可能是遇到了锁（MDL LOCK 或 row lock）之类的问题。如下图： 对于非自动提交的事务，则 GTID event 的 immediate_commit_timestamp 为事务提交的时间，但是语句开始执行的时间需要查看具体语句的 event 才可以，不能查看 GTID event header 的 timestamp，这是 commit 命令发起的时间，如下图： 当然类似，还可以获取从库的 binlog 信息来比对主库是什么时候发起语句的，什么时候提交事务的，从库又是什么时候提交事务的。类似如下图，这是我的一个从库，我这里是一个自动提交的 DML 语句： 很明显，主库发起语句时间和主库提交时间以及从库提交时间都有一定的差值。 主库发起语句时间：12:02:09 主库提交事务时间：12:02:13 从库提交事务时间：12:03:59 3.3 更加精确的延迟 这部分你在官方文档有说明，其中主要包含 3 个视图： ps.replication_applier_status_by_worker： SQL 线程或者 WORKER 执行相关 ps.replication_connection_status： IO 线程相关 ps.replication_applier_status_by_coordinator： 协调线程相关 其中大部分和 timestamp 相关的字段的都是自解释的，而在 ps.replication_applier_status_by_coordinator 和 ps.replication_applier_status_by_worker 中有两类字段类似 XXX_BUFFER_TIMESTAMP，XXX_APPLY_TIMESTAMP 比如： LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP： 表示协调线程将事务分发给 WORKER 线程的时间 LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP： 表示应用完事务的时间 具体代码中可以断点在： Relay_log_info::finished_processing Relay_log_info::started_processing 上进行观察，实际上是 Relay_log_info 中多了如下信息： /** Stores information on the last processed transaction or the transaction that is currently being processed. STS: - timestamps of the currently applying/last applied transaction MTS: - coordinator thread: timestamps of the currently scheduling/last scheduled transaction in a worker's queue - worker thread: timestamps of the currently applying/last applied transaction */ Gtid_monitoring_info *gtid_monitoring_info; 每个 WORKER 和协调线程都包含了这样一个事务的监控信息，因此可以在视图中打印出来。 显然我们就可以通过各种从库中执行的 timestamp 的时间和主库提交时间也就是 ORIGINAL_COMMIT_TIMESTAMP 计算出来精确的延迟。 更多技术文章，请访问：https://opensource.actionsky.com/ 关于 SQLE SQLE 是一款全方位的 SQL 质量管理平台，覆盖开发至生产环境的 SQL 审核和管理。支持主流的开源、商业、国产数据库，为开发和运维提供流程自动化能力，提升上线效率，提高数据质量。 SQLE 获取 类型 地址 版本库 https://github.com/actiontech/sqle 文档 https://actiontech.github.io/sqle-docs/ 发布信息 https://github.com/actiontech/sqle/releases 数据审核插件开发文档 https://actiontech.github.io/sqle-docs/docs/dev-manual/plugins/howtouse
2023-12-27
优秀的个人博客,低调大师

阿里云开启多媒体搜索新时代，发布全域精准图像搜索

随着互联网的快速发展及多媒体数据的爆炸式增长，图像搜索已成为企业在搭建搜索引擎时亟需的重要技术。 7月11日，阿里云宣布由阿里巴巴机器智能技术实验室打造图像搜索产品正式商用，开启了多媒体搜索的新时代，将图像搜索这个“贵族技术”变为“平民技术”。目前阿里巴巴机器智能技术实验室已将图像搜索的范围从最初的服装、鞋包、配饰、食品、数码、家居、日用百货、瓶饮等商品类目扩展到汽车、布料、商标、建筑、景观等通用类目，可广泛应用于搜索引擎、电商、纺织业、皮革业、旅游业等生活的方方面面，让图像搜索技术得到更广泛的行业应用。 图像搜索核心技术及优势 图像搜索是以深度学习和大规模机器学习技术为核心，通过图像识别和搜索功能，实现以图搜图的智能图像搜索产品。图像搜索服务在基于图像识别技术基础上，结合不同行业应用和业务场景，帮助用户实现相同或相似图片搜索。目前阿里
2018-07-16
优秀的个人博客,低调大师

现在AI能给出更精准的预测

本文来自AI新媒体量子位（QbitAI） 只需要简单查看器官图片，人工智能就可以预测患者的剩余的生命长度，这是澳大利亚阿德莱德大学的最新研究成果。 这一成果发表在最新的《自然》杂志旗下《科学报告》中，被认为将对严重疾病的早期诊断和医疗干预产生影响。 阿德莱德大学公共卫生以及计算机两个学院的研究人员，使用人工智能技术分析了48例患者的胸部医学影像资料，然后预测哪些患者有可能在五年内死亡，准确率达到69%，这与临床医生的“手动”预测不相上下。 “预测患者未来的生命周期的价值在于，可以让医生对不同患者展开更有针对性的治疗”，阿德莱德公共健康学院的放射科医师和博士生Luke Oakden-Rayner表示。 生物学年龄的准确评估和患者寿命的预测，一直受制于医生无法测量每个器官的健康状况。而阿德莱德大学的最新研究，使用了深度学习技术对医学影像进行理解
2018-01-07
优秀的个人博客,低调大师

IBM 语音识别新方向：仿生蝙蝠耳能用声纳精准“聆听”

蝙蝠使用生物声呐，为夜晚在丛林中飞行导航。他们的超声波脉冲，可以比人造声呐装置更精确地对声音进行定位。为复制、驾驭这种能力，IBM 学院奖获得者 Rolf Müller 教授协同他在弗吉尼亚理工学院（Virginia Tech）的团队，设计了一种人造蝙蝠耳。 Rolf Müller 的研究引起了 IBM 的注意。IBM 专家韩金萍（音译）的神经计算团队，和 IBM Watson 语音专家崔晓东（音译）和他的同事， 看到了 Müller 教授人造“动态外耳”（dynamic peripheral，蝙蝠可转动的外耳使它们的生物声呐更加准确）的潜力 ，并希望借此提高人类语音理解的能力。他们把 Müller 的博士生 Anupam Gupta 纳入团队，一同他们探索人造蝙蝠仿生耳在语音处理的应用。 他们发现，这些仿生耳不仅是很有效的声呐装置，
2017-07-31

资源下载

更多资源
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-08-21 大小: 189MB 下载: 7次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册