leonpenn的博客 *你本如虎，正当添翼*

实验：一、开始实验前，interactive_timeout和wait_timeout的global和session级都是28800smysql> select @@global.interactive_timeout,@@session.interactive_timeout;+------------------------------+--------------------...

背景：阿里云ECS，94G内存，32核CPU，MySQL BP=70G，备份盘没有采用SSD实验：一、基础语句 backupcmd = "innobackupex --defaults-file=%s --galera-info --user=%s --password=%r --socket=%s --kill-long-queries-timeout=300 --kill-l...

关于MySQL的审计功能，有三个主流的选项：1、MySQL Enterprise Audit Plugin：仅供MySQL 企业版使用的插件，收费2、Percona Audit Log Plugin：仅供Percona Server使用的插件，免费3、MariaDB Audit Plugin：支持MariaDB、MySQL、Percona Server，建议使用1.2以上版本

-rw------- 1 mysql mysql 1675 Sep 13 16:19 ca-key.pem-rw-r--r-- 1 mysql mysql 1074 Sep 13 16:19 ca.pem-rw-r--r-- 1 mysql mysql 1078 Sep 13 16:19 client-cert.pem-rw------- 1 mysql mysql

许多同学在做MySQL数据库测试时苦于没有测试数据，除了线上导一小段数据、或者利用sysbench生成测试数据外，官方其实也提供了了一套名为：Employees Sample Database的测试库（该测试库含有6个表，总计4百万数据记录）测试数据库导入文件下载：https://launchpad.net/test-db/下载到的文件一般为：employees_VERSION.tar

https://dev.mysql.com/doc/refman/5.5/en/innodb-recovery.htmlThis section describes InnoDB recovery. Topics include:Point-in-Time RecoveryRecovery from Data Corruption or Disk FailureInnoDB

MySQL5.7.7引入的sys库可以看作是由information_schema引出的一套视图，更便于获取一些性能数据。下面我会记录如何为MySQL5.6加上sys库。 首先从https://github.com/mysql/mysql-sys上克隆项目到本地假设存放在/tmp/mysql-sys下（注意文件权限为root，执行的可以是拥有invoke权限的用户）[root...

MySQL 复制场景中，从库承担着很多的读请求的压力，特殊时刻还能临时充当主库，而复制是否可靠是从库能否承担这些角色的前提。但是，想必大家都会或多或少遇到过复制出错的问题吧？主从不一致？还在一个劲地跳错误点吗？重建复制是不是很痛苦？看完下面的文章，教你正确配置MySQL复制。一、先来一个常规演示：搭建一个基于行的一主一从复制=================

背景：产品需求经常变更的情况下，造成了线上数据库的表结构需要不停地进行变更，若直接 alter table（包括create index等）会导致锁表，后续对相关表的读写操作都会进入到 "Waiting for table metadata lock" 锁等待队列中，严重影响高负荷业务系统的运行。注：关于5.5引入的metadata锁，即使是select操作也会产生metadata锁（保护查询过程...

MySQL在启动的时候，会进行前滚（利用redo log实现）和回滚（利用undo log和bin log实现）事物，来保证与前一次数据库服务关闭前的数据版本的最终一致性。Crash Recovery的过程，可查阅参考文档一。我们知道，不同的落盘机制影响着redo、undo、binlog以及数据本身的刷新策略。1、Redo loginnodb_log_buffer_size控制着r...

 照理说现在都8102年了，sql_slave_skip_counter应该不再是一个热门的讨论点了，但作为一个经典的容易误导的知识点，不去纸上谈兵，用实验总结一下还是很有必要的。以下实验是在MySQL 5.6的基于行的一主一从复制下展开。主库如下建表，并插入两行记录：mysql> CREATE TABLE `rpl_test1` (`id` int(11) NOT NUL...

innodb_buffer_pool_size：mysql> show variables like "%innodb%buffer%";+------------------------------+---------+| Variable_name | Value |+------------------------------+---------+

MySQL的用户权限管理一般都是通过User+Host的形式来区分不同的用户权限，当用户数一多，逐一去修改权限就变得较为繁琐。实际运用中，很多用户需要的权限极为相似。此时，利用MySQL官方提供的Proxy User功能来实现“组权限”就变得颇有意义了。

今天监控报警，从库的Slave_SQL_Running未启动，在处理完故障后，提取一些主要的步骤整理了一下，在自己的测试机上重现了一下当时的故障情况，供大家参考。当时第一反应过来的处理方法，就是change master 重置同步binlog的位置仔细查看error log，发现却是另外一个问题：2017-06-30T01:28:10.388335Z 0 [Warnin

在数据库中，以事务为单位去执行一组蕴含特定功能的SQL，可以比较安全地实现用户的操作需求。所谓的“安全地实现”，比较书面的说法就是事务的ACID特性。Atomicity原子性：all or nothing，由Redo & Undo实现。Consistency一致性：事务执行前后完整性约束没有被破坏，由Undo实现。拓展阅读：一致性非锁定读：http://blog.c

线上服务器在重启过后，由于innodb buffer pool被清空，往往在最开始一段时间的性能会很差，当用户量特别大的高峰时期更是如此。MySQL 5.6 将 InnoDB版本升级到1.2.X后，提供了一共5个新的参数用于配置预热功能，将innodb buffer pool中的热块缓存到磁盘文件ib_buffer_pool中，待重启时再加载到内存中。本文是对生产环境下，部分使用5.5及更早版

后面要简单写一个MySQL自动部署脚本，今天再次梳理下安装流程。同时也给刚入门的同学一个参考，写的比较详细，图文并茂。希望能一举两得。安装环境：CentOS 6.2，最小化安装确保后期做脚本时有较好的兼容性MySQL 5.5源码包（/usr/toolkits/mysql_install_tools/mysql-5.5.54.tar.gz）一、规划安装目录、用户、组

InnoDB 存储引擎默认隔离级别为可重复读（Repeatable Read），该隔离级别下加行锁采用的是next-key locking 策略。InnoDB支持行锁（锁定字段含有索引的情况下，否则走表锁），但锁定方式并非简单的锁定指定行上的索引，而是分为3种锁定算法：1）记录锁（Record Locks）：锁定指定行的索引项2）Gap Locks：锁定某一个范围内的索引，但不包括记录

为了最大程度避免数据写入时io瓶颈带来的性能问题，MySQL采用了这样一种缓存机制：当query修改数据库内数据时，InnoDB先将该数据从磁盘读取到内存中，修改内存中的数据拷贝，并记录持久化在硬盘上的事务日志，而不是每次都直接将修改过的数据记录到硬盘内，等事务日志持久化完成之后，内存中的脏数据可以慢慢刷回磁盘，称之为Write-Ahead Logging。事务日志采用的是追加写入，顺序io会带来

关于InnoDB的并发控制InnoDB 存储引擎默认隔离级别为可重复读（Repeatable Read），该隔离级别下加行锁采用的是next-key locking 策略。关于 next-key locking 策略InnoDB支持行锁（锁定字段含有索引的情况下，否则走表锁），但锁定方式并非简单的锁定指定行上的索引，而是分为3种锁定算法：1）记录锁（Record L

背景主库的worker线程在写binlog的时候是并发工作的，而主库的dump线程和从库的IO线程都是单线程推拉binlog、特别是默认SQL线程是拿着relay log中的event逐一单线程回放的（5.6版本开启slave_parallel_workers支持特定情况下的并行复制，5.7版本之后全面支持并行复制后在复制层面已极大改善了延时问题）。因此即使不考虑网络延迟，主流MySQL版本在...

 先看下节点间的半同步复制时序图（注：半同步复制相关图示均源自王松磊@Ucloud）5.7版本之后新增ack线程（单线程工作）用于接受应答，分摊dump线程的压力（老版本需要兼顾发送binlog和接受应答，这两个操作又是串行的）。 rpl_semi_sync_master_wait_point：AFTER_COMMIT；5.7版本开始默认为 AFTER_SYNC两者区别在于...

set global sql_slave_skip_counter=N;跳过N个binlog event。特别地，当第N个event存在于某个事务，则该event所在的整个事务也将被跳过。