在日常运维过程中,我们时常遇到这样的烦恼,两套库配置差不多,性能就是不一样,或者将自建的数据库迁移到云上之后,性能差别非常的大;无奈之举,去比对数据库配置是否相同,人肉对比,不仅效率低下而且容易出错哦。pt拿出了这么一个神器,专门对比mysql配置,有这么几种对比方式:
以下的内容,希望你的环节是在8.011 以上的环境中操作,部分需要在8.018 以上环境操作
语法 innobackupex --user=DBUSER --password=DBUSERPASS /path/to/backup/dir/ innobackupex --user=DBUSER --password=DBUSERPASS --backup --target-dir=/path/to/BACKUP-DIR/
MySQL Shell诊断实用程序能够分析MySQL服务器的性能,并能够生成运行状况、性能和单个查询的诊断报告。注意,这是MySQL Shell在8.0.31提供的新功能,用户必须使用8.0.31之后的版本。
从 MySQL 5.7.6开始,这两个表开始被废弃,并将在后续的版本移除,信息可以在Performance_schema数据库中查询
在上一篇《用于修改配置的存储过程 | 全方位认识 sys 系统库》中,我们介绍了sys 系统库中用于修改配置的存储过程,利用这些存储过程可以代替修改performance_schema配置表的DML语句等操作,本期的内容讲介绍用于查看performance_schema配置信息的存储过程。
比如本人使用的云服务器,其中MySQL预装版本为老版本5.1.x。而最新的mysql版本在性能、功能、安全性等方面都有了很多的改进。 要从最新版本获益,你需要把现有系统升级到5.5+(最新的版本是5.7),我保守一点,升级到5.6.37。
放假的最后一天,的回答最近有一个小朋友问了一个关于 processlist 的问题,基于MYSQL 8 show processlist 到底从哪里来的信息,MYSQL 8 中提供processlist 信息的表与命令之间结果的不同。
现在,很高兴的告诉大家,我们基于 MySQL 官方文档加上我们的验证,整理了一份可以系统学习 performance_schema 的资料分享给大家,为了方便大家阅读,我们整理为了一个系列,一共7篇文章。下面,请跟随我们一起开始performance_schema系统的学习之旅吧。
MySQL中数据字典是数据库重要的组成部分之一,INFORMATION_SCHEMA首次引入于MySQL 5.0,作为一种从正在运行的MySQL服务器检索元数据的标准兼容方式。用于存储数据元数据、统计信息、以及有关MySQL server的访问信息(例如:数据库名或表名,字段的数据类型和访问权限等)。
information_schema和performance_schema的一点知识
MySQL中经常遇到事务中的SQL正在执行或执行完成后未提交,如何找出对应的SQL?
系统环境为CentOS6.5,安装的MySQL版本为5.6.29,现在要将此版本升级为MySQL5.7.29。
随着MYSQL的脚步越来越快,(更新的速度),觉得原来的监控的方式是不是也需要进行进一步的探索,当然现在的监控市场云龙混杂,成型的模式例如 percona pmm, 还有国产的蓝鲸,但这些监控在好,方式在炫酷,但也不能阻挡对数据库底层的监控的知识掌握,否则就只能看图说话,让人心里不踏实。另外很多公司的监控指标还需要灵活对待,不知道底层的监控参数输出,有怎么能开发出自己的监控系统。
mysql提供一套INNODB监控机制,用于周期性(每15钞)输出INNODB运行相关状态(INNODB运行状态、表空间状态、表状态等)到mysqld服务标准错误输出。另外,INNODB标准监控和锁监控,也可以通过命令:show engine innodb status输出到控制台。
业务监控发现交易的平均响应时间比之前慢了近一倍,需要排查一下数据库是不是响应慢了。生产MySQL版本为8.0.18,一主3从半同步复制。
MySQL数据库的性能优化是一个复杂且细致的过程,其中,内存的使用情况对于数据库的性能有着直接的影响。了解并分析MySQL中各个功能模块的内存使用,是进行优化分析的重要步骤。本文将探讨如何查询和分析MySQL的各个功能模块的内存使用情况,以助于进行针对性的优化。
ProxySQL整合MGR提供高可用,是我们知数堂课程中提供一个MySQL高可用的解决方案,架构如下:
关于监控如果上云后,到底还需要自行进行监控吗,是一个问题,是否把所有的数据库监控都放到云上,通过云来获取数据库的信息是一个问题。
修改配置文件my.cnf [root@upgrade-slave ~]# diff /tmp/old.my.cnf /tmp/new.my.cnf 11c11 < table_cache = 2048 --- > table_open_cache = 2048 18d17 < thread_concurrency = 8 22c21 < default_table_type = INNODB --- > default_storage_engine = INNODB 44c43 < myisam_recov
爱可生 DBA 团队成员,主要负责 MySQL 故障处理和性能优化。对技术执着,为客户负责。
MOP 不用多说,指的就是 MySQL、Oracle、PostgreSQL 三种目前最主流的数据库,MOP 系列打算更新 MOP 三种数据库的索引知识、高可用架构及常用 SQL 语句等等,上面已经更新了 MOP 索引相关的文章,今天打算整理一下这三种数据库的常用 SQL 知识,由于文章过长,今天更新中间的一篇之 MySQL 篇。第一篇 Oracle 相关的详见下方链接:MOP 系列|MOP 三种主流数据库常用 SQL(一)。
http://www.searchdoc.cn/rdbms/mysql/dev.mysql.com/doc/refman/5.7/en/index.com.coder114.cn.html
MySQL的Performance Schema是一套内存表,用于跟踪MySQL的性能指标。它实际上使用PERFORMANCE_SCHEMA存储引擎,用户操作performance_schema数据库中的表。用户通过Performance Schema能够观察哪些查询正在运行、I/O等待的状态,及历史性能数据等等信息。Performance Schema仅对本地服务器有效,所有的更改不会复制到其他的服务器。
最近在某云使用了MYSQL RDS 产品,说实话不怎么满意,和他家的其他产品比较我到时更原因使用 PG 的产品和云原生产品,那才是业界良心。为什么说不原因,主要是PS 方面让我们初次使用就感觉,不十分良好,2天了PS 里面部分的表还没有数据展示,沟通找问题,最终问题还是我们自己解决了大部分。
这是关于MYSQL8 获取信息的方式的第六篇,终于到达了慢日志查询的位置,在MYSQL的DBA 的管理员的心目中,pt-query-digest 和 SLOW QUERY LOG 是分析慢查询的唯一的方式。实际上在MYSQL 8 中这样的慢查询的数据获取方式,已经被淘汰了,或者说不合时宜了。
在 MySQL 的实际使用中,常常会遇到一条 SQL 执行非常慢的情况,此前我们总结了一系列博客来排查相关的问题:
MySQL Profile对于分析执行计划的开销来说,还是有一定的帮助,至少在分析一些性能问题的时候有很多的参考依据。 我在5.6, 5.7版本中进行了测试,没发现差别,还是以5.7为例进行演示吧。 mysql> select version(); +-----------+ | version() | +-----------+ | 5.7.10 | +-----------+ 1 row in set (0.00 sec) 传统的使用Profile都是使用show profile这样的命令方式,这
[root@dev_121_21 ~]# mysql–socket=/usr/local/mysql/mysql.sock –default-character-set=utf8
MySQL使用内存上升90%!在运维过程中50%的几率,会碰到这样的问题。算是比较普遍的现象。
最近一段时间和MYSQL的 performance_schema 较劲,之前总结的比较散,没有一个整体的观,仅仅是细枝末叶的东西。本次的对performance_schema 从总体来看,看看未来(MYSQL 8),以后观察MYSQL的性能问题需要什么改变。招招毙命其实是对老的监控方法来用“吸引体”来 attractiveness。
MySQL 的Performance Schema由来已久,但由于内存消耗,性能影响等原因,导致其始终无法进入主流的MySQL默认配置,对MySQL的问题诊断以及处理造成很多不利的影响。 一般而言,Performance Schema会对性能造成影响,比如row mutex的位置。实际上,MySQL经常出现问题的地方,很多时候是在Server层,在这一层,很多Performance Schema的设置并不会导致性能的下降(或者明显下降)。 下文为总结出来的,推荐开启的Performance Schema选
从MYSQL 5.6 开始MYSQL的监控方式已经有了改变,可能给人的印象是越来越和ORACLE 长得一样了,以后是不是也的来一个 AWR 那是不置可否。。那到底怎么近似了,又怎么监控变化了。如果是从MYSQL 5.5 及其以前用过MYSQL的同学来说,performance_schema是从陌生到熟悉的过程,从原来不不敢打开,到现在的MYSQL5.7 基本都打开的状态,performance_schema 越来对于监控和反应系统的状况重要了。
接上期说,在MYSQL 5.7 后performance_schema 以及后来的sys库的重要性越来越高,各种系统的性能以及系统资源的分配信息都会在这里体现。
NFORMATION_SCHEMA提供对数据库元数据的访问 ,有关MySQL服务器的信息,例如数据库或表的名称,列的数据类型或访问权限。
方法一: 全局变量设置,将 slow_query_log 全局变量设置为“ON”状态 mysql> set global slow_query_log='ON'; 设置慢查询日志存放的位置 mysql> set global slow_query_log_file='/usr/local/mysql/data/slow.log'; 查询超过1秒就记录 mysql> set global long_query_time=1;
线上有个数据库主从环境的MySQL版本是5.5.19版本的,由于5.5.19环境的MySQL在运维侧的支持不太好,例如:不能动态修改buffer_pool的值,alter table增加列的操作会长时间锁表等等。所以经过商量,需要对它进行升级,这次我采用的是在线升级的办法。我总结了一下在线升级过程中的总体步骤:
在本系列中前面用了大量篇幅介绍完了 sys 系统库的视图,利用这些视图我们可以方便快捷地查询到performance_schema、information_schema下的内容,但对于performance_schema下的instrument和consumer配置信息属于需要修改的内容,除了直接使用update语句修改配置表之外,是不是也有类似查询视图一样的快捷方式呢?有的,本期的内容开始给大家介绍一些修改、确认配置相关的存储过程。
MySQL作为关系型数据库的典型代表,在国内环境里经历风雨磨砺,不断地精进,已经在开发和运维方面,成型了一套的规范。这些规范让了解和使用MySQL更加得心应手,并对后期的一些问题起到了很好的预防作用。
查询目前哪些表有主键,可以通过information_schema.key_column_usage表来确定哪些列使用了主键约束,这个表中包含如下列,每个列的含义如下: CONSTRAINT_CATALOG :约束所属目录的名称。 该值始终为def。 CONSTRAINT_SCHEMA :约束所属schema(database)名称 CONSTRAINT_NAME :约束名称 TABLE_CATALOG :表所属目录的名称。 该值始终为def。 TABLE_SCHEMA :表所属schema(database)名称 TABLE_NAME :具有约束的表的名称 COLUMN_NAME :具有约束的列的名称。 如果约束是外键,则这是外键的列,而不是外键引用的列。 ORDINAL_POSITION :列在约束内的位置,而不是列在表中的位置。列位置从1开始编号。 POSITION_IN_UNIQUE_CONSTRAINT:NULL对于唯一和主键约束。对于外键约束,此列是正在引用的表的键中的序号位置。 REFERENCED_TABLE_SCHEMA :约束引用的schema(数据库)的名称。 REFERENCED_TABLE_NAME :约束引用的表的名称。 REFERENCED_COLUMN_NAME :约束引用的列的名称。 我们来看看这个表中的记录吧:
全局读锁通常是由flush table with read lock;这类语句添加的。在各种备份工具为了得到一致性备份,已经在具备主从复制架构的环境中做主备切换时常常使用这类语句。另外还有一种情况,可是最难排查的一种情况,就是线上系统权限约束不规范,各种人员使用的数据库账号都有RELOAD权限,都可以对数据库加全局读锁。
在MySQL 8.0 中,Performance Schema 已经成为监控和分析数据库锁状态的首选方法。 在本文中,我们将探讨Performance Schema中与锁相关的表,并通过实例介绍如何使用这些表来发现当前会话的锁、识别哪些锁被阻塞、以及确定谁持有锁。
MYSQL 中有一个重要的特性就是锁,如何认识到锁的概念对于使用MYSQL有着重要的意义,针对与锁的认识,以及发现我们需要通过MYSQL本身的performance_schema 中的表来了解,不熟悉这一个系列的同学可以去从之前的performance_schema 系列里面去了解performance_schema的日常使用。MYSQL的锁可以从 metadata 和 表锁开始。
当数据库跑了较长时间后,存储的数据将越来越多,这时候往往也意味着,一旦数据库服务器出现宕机等相关状况,将给我们的业务带来巨大的影响,甚至可能是具备一定的毁灭性的,因此,即使对数据库进行备份是极其重要的。接下来,我们一起来学习全量备份的实现方式。
在上一篇 《初相识 | performance_schema全方位介绍》 中粗略介绍了如何配置与使用performance_schema,相信大家对performance_schema能够为我们提供什么样的性能数据已经有一个初步的认识,今天将带领大家一起踏上系列第二篇的征程(全系共7个篇章),在这一期里,我们将为大家全面讲解performance_schema配置方式以及各个配置表的作用。下面,请跟随我们一起开始performance_schema系统的学习之旅吧。
Performance Schema简介 Oracle DBA都应该知道 Oracle中提供了大量的视图供DBA们排查问题使用,并且有等待事件帮助大家快速定位问题属于哪一类。MySQL 中也有Performance Schema帮助大家去分析排查问题,并且在5.7中增加了Sys Schema,将Performance Schema和information_schema的信息格式化后,供大家更方便的分析问题。 这里先介绍先Performance Schema的使用方式,便于后面大家更好的去使用Sys Sc
MySQL的锁包括服务器级别的锁,存储引擎级别的锁,及互斥锁。服务器级别的锁包括表锁和元数据锁,存储引擎的锁是行级别的锁,由InnoDB引擎控制。互斥锁是低级别的锁,适用于内部的资源,用于同步低级别代码的操作,确保一次只有一个线程能够访问,例如,日志文件、自增列的计数器,及InnoDB buffer pool的互斥。
MySQL主从复制(MySQL Replication)是指从一个MySQL主服务器(master)将数据拷贝到另一台或多台MySQL从服务器(slaves)的过程。将主数据库的DDL和DML操作通过二进制日志(binlog)传到从服务器(slave)上,然后在从服务器上对这些日志重新执行,从而使得主从服务器的数据保持同步。 MySQL从3.23版本开始提供复制的功能。
领取专属 10元无门槛券
手把手带您无忧上云