同一个 binlog，没想到多线程重放竟比单线程慢了四倍多！
Connection Control 是 MySQL 8.0 引入的一个安全功能插件，后移植到 MySQL 5.7.17 和 5.6.35 版本。 其核心功能是：当客户端因账号或密码错误连续多次登录失败时，服务端会对该客户端的后续请求进行延迟处理，且失败次数越多，延迟时间越长。这一机制能显著增加密码被暴力破解的耗时，从而有效遏制此类攻击。 适用场景： 面向公网开放的 MySQL 服务器。 合规性
去年写的一个小工具，用于在线获取 MySQL binlog 的大小、开始时间、结束时间和持续时长。 什么场景下会用上这个工具呢？ 云服务场景，无法登录 MySQL 服务器查看 binlog 的时间戳信息。 主从延迟时，可以使用这个工具来查看 binlog 的大小或者某个时间段 binlog 的写入量。 基于时间点的恢复时，可以根据操作的大致时间来定位对应的 binlog 文件。 不多说，直接看
本文从源码角度对 HikariCP 中的一些常见参数进行分析，希望能帮助大家更加清晰地理解这些参数的具体含义。
在数据库连接池的使用中，连接泄漏是一个常见且严重的问题。本文通过分析一个实际的案例，探讨了连接泄漏的危害、产生原因以及如何在 Druid 和 HikariCP 这两种常见的连接池中定位和解决连接泄漏问题。
背景 在 Java 程序中，下面是一个经常会碰到的错误。 Caused by: com.mysql.cj.exceptions.CJCommunicationsException: Communications link failure The last packet successfully received from the server was 30,027 milliseconds ag
问题 在 MySQL 中，查询全局状态变量的方式一般有两种：SHOW GLOBAL STATUS和performance_schema.global_status。 但不知道大家注意到没有，performance_schema.global_status 返回的状态变量数要远远少于 SHOW GLOBAL STATUS 。 具体来说， 在 MySQL 8.4.2 中，SHOW GLOBAL S
通过可传输表空间的方式导入一个 4GB 大小的表，为什么大部分耗时是在System lock阶段？
哈哈，双十一来了，顺便安利下我的书-《MySQL实战》！目前收到的反馈都还不错，值得 DBA 拥有～ 背景 在 MySQL 的日常管理过程中，大家或多或少会遇到权限认证相关的问题。 例如，本来能够正常执行的操作，可能在新增一个账号或授权后就失败了。 这种现象往往让人误以为是 bug，但很多时候，其实并不是。 下面，将通过两个案例来阐明 MySQL 权限认证中的具体优先原则，并在此基础上，分析以下问
问题 MGR 中，新节点在加入时，为了与组内其它节点的数据保持一致，它会首先经历一个分布式恢复阶段。在这个阶段，新节点会随机选择组内一个节点（Donor）来同步差异数据。 在 MySQL 8.0.17 之前，同步的方式只有一种，即基于 Binlog 的异步复制，这种方式适用于差异数据较少或需要的 Binlog 都存在的场景。 从 MySQL 8.0.17 开始，新增了一种同步方式-克隆插件，克隆插
问题 最近碰到一个 case，一台主机上，部署了多个实例。之前使用的是 MySQL 8.0，启动时没有任何问题。但升级到 MySQL 8.4 后，部分实例在启动时出现了以下错误。 [Warning] [MY-012582] [InnoDB] io_setup() failed with EAGAIN. Will make 5 attempts before giving up. [Warning]
在 MySQL 中，如果我们想查看实例当前正在执行的 SQL，常用的命令是SHOW PROCESSLIST。 但如果 SQL 过长的话，就会被截断。这时，我们一般会用SHOW FULL PROCESSLIST来查看完整的 SQL。 最近碰到一个 case，发现无论是使用 SHOW PROCESSLIST、SHOW FULL PROCESSLIST，还是 performance_schema.pro
最近碰到一个 case，值得分享一下。 现象就是一个 update 操作，在 mysql 客户端中执行提示 warning，但在 java 程序中执行却又报错。 问题重现 mysql> create table test.t1(id int primary key, c1 datetime); Query OK, 0 rows affected (0.01 sec) mysql> i
最近在分析ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)这个报错的常见原因。 在分析的过程中，不可避免会涉及到 MySQL 身份验证的一些实现细节。 加之之前对这一块就有很多疑问，包括： 一个明文密码，是如何生成 mysql.user 表中的 authentication_st
在回答这个问题之前，首先我们看看 MySQL 中有哪些常用的 JDBC 连接池： c3p0 DBCP Druid Tomcat JDBC Pool HikariCP 这些连接池中，这些连接池中，c3p0 是一个老牌的连接池，很多流行框架，在其老版本中，都将 c3p0 作为默认的连接池。 DBCP 和 Tomcat JDBC Pool（Tomcat 的默认连接池）是 Apache 开源的。 Dr
问题 最近有好几个朋友问，如何将 performance_schema.events_statements_xxx 中的 TIMER 字段（主要是TIMER_START和TIMER_END）转换为日期时间。 因为 TIMER 字段的单位是皮秒（picosecond），所以很多童鞋会尝试直接转换，但转换后的结果并不对，看下面这个示例。 mysql> select * from performa
承蒙大家的支持和厚爱，刚上市的《MySQL实战》已经跃居京东自营数据库图书热卖榜第 1 名。感兴趣的童鞋点击 https://item.jd.com/13677965.html 购买，目前，京东自营有活动，只需 5 折。 <br> 主从延迟作为 MySQL 的痛点已经存在很多年了，以至于大家都有一种错觉：有 MySQL 复制的地方就有主从延迟。 对于主从延迟的原因，很多人将之归结为从库
预告: 《MySQL实战》即将出版，敬请关注！ 有线上 MySQL 维护经验的童鞋都知道，主从延迟往往是一个让人头疼不已的问题。 不仅仅是其造成的潜在问题比较严重，而且问题的定位尤其考量 DBA 的综合能力：既要熟悉复制的内部原理，又能解读主机层面的资源使用情况，甚至还要会分析 binlog。 导致主从延迟的一个常见原因是，对于 binlog 中的事务，从库上只有一个 SQL 线程进行重放，而这些
搭建从库，本质上需要的只是一个一致性备份集及这个备份集对应的位置点信息。之前介绍的几个备份工具（MySQL中如何选择合适的备份策略和备份工具）均可满足。这里，我们重点看看如何基于XtraBackup搭建从库。整个过程其实比较简单，无非是备份还原。唯一需要注意的是建立复制时位置点的选择，包括：1.在基于位置点的复制中，CHANGEMASTERTO语句中MASTER_LOG_FILE和MASTER_L
故障检测（FailureDetection）是GroupReplication的一个核心功能模块，通过它可以及时识别集群中的故障节点，并将故障节点从集群中剔除掉。如果不将故障节点及时剔除的话，一方面会影响集群的性能，另一方面还会阻止集群拓扑的变更。下面结合一个具体的案例，分析GroupReplication的故障检测流程。除此之外，本文还会分析以下问题。1.当出现网络分区时，对于少数派节点，会有什
一文搞懂 MySQL Group Replication 的流控机制～
MGR的新主选举算法，在节点版本一致的情况下，其实也挺简单的。首先比较权重，权重越高，选为新主的优先级越高。如果权重一致，则会进一步比较节点的server_uuid。server_uuid越小，选为新主的优先级越高。所以，在节点版本一致的情况下，会选择权重最高，server_uuid最小的节点作为新的主节点。节点的权重由group_replication_member_weight决定，该参数是M
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
