1、MySQL官方社区版本下载: MySQL 8.0 下载: https://dev.mysql.com/downloads/mysql/ MySQL 5.0,5.1,5.5,5.6,5.7,8.0下载: https://downloads.mysql.com/archives/commun
在MySQL多源复制架构中,一个从库可以创建多个命名的复制通道(channels),复制通道代表主库向从库传送事务数据的路径,每个复制通道有自己独立的IO线程,1个或多个SQL线程。 多源复制常用于多主多从复制的复杂架构,多源复制并不提供多主上数据写入冲突的检测,如果在多主上对同一条记录进行更新,
Copyright © 2020-2023 www.mytecdb.com All Rights Reserved.
Copyright © 2020-2023 www.mytecdb.com All Rights Reserved.
Copyright © 2020-2023 www.mytecdb.com All Rights Reserved.
Percona 公司发布的 MySQL 分支版本(Percona Server for MySQL)在互联网公司具有广泛的用户,其发布的 MySQL 版本在社区版基础上增加了许多实用功能,比如线程池,InnoDB 存储引擎增强,审计功能,运维管理功能增强等等,另外 Percona 公司还提供了功能完
mysqldump是MySQL自带的逻辑备份工具,能够实现包括库级别、表级别、字段级别、表结构、where条件过滤等不同粒度的数据备份,备份出来的文件通常是文本形式保存的SQL语句,当然也可以是CSV,XML格式,这些文本文件能够很方便地再次导入到MySQL或者其他类型的数据库。 由于是逻辑备份,
xtrabackup是percona公司开发的一款开源免费的MySQL热备份工具,备份期间,不会锁库,不影响正常的业务写入,并且不会对MySQL性能产生大的影响。 xtrabackup属于物理备份,备份、恢复速度快,适合数据量大,整库备份的场景。 对于InnoDB、XtraDB和MyRock
本文通过一组测试,来看一下MySQL主从库服务器时钟的差异对MySQL复制延迟的影响。 一、测试环境 操作系统:CentOS 7.3,4核,16G MySQL: 5.7.19 1主2从 二、测试场景 主库时钟比从库早1分钟,5分钟,1小时,1天 主库时钟比从库晚1分钟,5
slave_compressed_protocol 参数用于控制MySQL主从复制是否使用压缩协议,基于ROW格式的binlog,其数据量一直是一个比较大的问题,开启binlog复制压缩对于缓解binlog数据量大导致的网络带宽问题有一定的帮助,那么开启slave_compressed_protoc
MySQL InnoDB表支持行格式压缩,压缩后的表能够显著减少磁盘空间占用,但是压缩功能也会造成一定的性能损耗,比如加重CPU的负载,降低数据库吞吐量。本文通过测试案例,来具体了解MySQL InnoDB行格式压缩的效果以及对性能的影响。 MySQL版本:5.7.19 测试工具:sysbe
1. 参数说明 back_log 参数可以理解为 MySQL 缓存的尚未处理的连接数量,当 MySQL 在短时间内收到非常多的请求时,一时间处于不过来时,这个参数就会起到非常重要的作用。 MySQL 主线程在会花费一些时间来检查连接并且为连接创建新的线程,当短时间内收到大量连接请求时,back_
InnoDB是MySQL默认的存储引擎,支持事务,具有高性能和高可靠性。 一、InnoDB核心优势 支持事务,DML操作遵循ACID模型,具备崩溃恢复能力,保证用户数据安全、完整。 支持行级锁和一致性读,提高了多用户并发性能。 表数据在磁盘上以主键聚簇索引方式存储,这种数据组织方式,
看到一篇关于 MySQL InnoDB 表碎片的文章,觉得不错,转载如下,原文地址: https://www.cnblogs.com/wy123/archive/2020/03/22/12535644.html 网络上有很多 MySQL 表碎片整理的问题,大多数是通过 demo 一个表然后参
本文主要介绍了 MySQL InnoDB 支持的四种事务隔离级别,围绕隔离级别,解释了脏读,不可重复读,以及幻读的概念。 1. MySQL 支持的四种隔离级别 隔离性 isolation (I) 是事务 ACID 四种属性中的一种,它定义了如何将事务与事务之间隔离开来,隔离性是应用程序设计的关键
一、问题背景 环境: MySQL:Percona Server for MySQL 5.7.19 JDBC:mysql connector-J 5.1.45 Java代码通过JDBC执行SQL报错 如下: java.sql.SQLException: Unknown type '1
一、背景 MySQL 1主2从,半同步复制,主库有较高的写入量,此时在主库重复安装半同步插件,可能导致主库hang住,无响应,只能通过重启数据库来恢复。 二、故障复现 环境: MySQL版本:Percona Server for MySQL 5.7.19 操作系统:Red Hat En
一、背景 生产环境遇到一个 MySQL 写入报错的问题,业务写入数据时报主键冲突。经过调查,这套 MySQL 集群版本为 Percona 5.7.19,在报主键冲突前,做过主从切换,报主键冲突的SQL语句为 replace into,表的主键是自增列,调查该表的 auto_increment,发现
MySQL 做的时间长了,就有可能多次遇到相同的 Bug,这里记录一下,以便下次再遇到,能够参考。 1. 背景 业务执行 SQL 导致 MySQL 进程 Crash,做故障切换后,新的主库又 Crash 了。查看 MySQL 错误日志,发现多次 Crash 时的堆栈相同,如下: Thread
MySQL Crash 的原因有很多,比如硬件问题,磁盘坏块导致页损坏,内存问题导致内存访问错误,等等,软件问题,MySQL 自身的 Bug。通常 MySQL Crash 问题需要根据错误日志、Core 文件、业务 SQL,表结构等多种信息结合起来排查问题,即使有诸多信息,有些 Crash 问题仍然