rudy gao

--mysql 5.7 已经把memcache 与 innodb 结合在了一起The InnoDB memcached plugin provides an integrated memcached daemon that can automatically store and retrieve data from InnoDB tables, turning the MySQL server

在主从复制中，难免会遇到一些sql语句错误的问题。这个时候我们需要手动来重新设置中继日志的起始点了，有些麻烦。今天在看“2012华东架构师大会”视频的时候，发现淘宝丁奇的ppt里有这个参数,看名字就知道是让从库跳过一些错误了。以前没有注意过这个参数，这里了解一下这个参数的用法。----------------------------------------环境说明：mysq

MySQL在5.5.3版本引入了metadata lock他的本意是解决之前版本事务隔离特性的几个bug,但是引入的问题也不小.先说说MySQL的事务吧.Oracle的事务指的是需要分配回滚段的SQL语句,也就是说select并不是oracle事务的一部分.比如运行一个查询,然后在另外一个会话查询v$transaction,并不会有任何相关的信息.直到事务中出现insert,u

日常工作中，对于MySQL主从复制检查，一方面我们要保证复制的整体结构是否正常，另一方面需要检查主从数据是否保持一致。对于前者我们可以 通过监控复制线程是否工作正常以及主从延时是否在容忍范围内，对于后者则可以通过分别校验主从表中数据的md5码是否一致，来保证数据一致，可以使用Maatkit工具包中的mk-table-checksum工具去检查。在这里，我只想讨论下关于如何检查主从延时的问题。

使用replicate_do_db和replicate_ignore_db时有一个隐患，跨库更新时会出错如设置 replicate_do_db=testuse mysql;update test.table1 set ......第二句将不会被执行如设置 replicate_ignore_db=mysqluse mysql;update test.tab

在使用order by关键字的时候，如果待排序的内容不能由所使用的索引直接完成排序的话，那么mysql有可能就要进行文件排序。【这个 filesort 并不是说通过磁盘文件进行排序，而只是告诉我们进行了一个排序操作而已】。当然，using filesort不一定引起mysql的性能问题。但是如果查询次数非常多，那么每次在mysql中进行排序，还是会有影响的。此时，可以进行的优化

在多个master中复制的问题，主要是自增主键问题。 可以用auto_increment_increment和auto_increment_offset参数解决（1）auto_increment_increment：控制增长的间隔 （2）auto_increment_offset：控制AUTO_INCREMENT的开始值比如：有5台机器都作为master，则可以配置为：

以前mysql搭建新备库都是在现在业务较小的备库上停止同步或停止数据库，然后拷贝数据库到新备库，配置好新备库后，再开启同步或数据库。然而，这次没有空闲备库用来搭新备库。需要从一个业务繁忙的数据库中搭建一个新备库，对系统延时要求比较高，所以同步和数据库都不能停。所以我们用了percona的 xtrabackup备份工具。因为这个备份要作为备库，所以用了–slave-info参数，备份完成后会

MyISAM在读操作占主导的情况下是很高效的。可一旦出现大量的读写并发，同InnoDB相比，MyISAM的效率就会直线下降，而 且，MyISAM和InnoDB的数据存储方式也有显著不同：通常，在MyISAM里，新数据会被附加到数据文件的结尾，可如果时常做一些 UPDATE，DELETE操作之后，数据文件就不再是连续的，形象一点来说，就是数据文件里出现了很多洞洞，此时再插入新数据时，按缺省设置会先看

InnoDB Buffer Pool ActivityInnoDB Checkpoint AgeInnoDB I/OInnoDB Insert BufferInnoDB Internal Hash Memory UsageInnoDB LogInnoDB Row Lock TimeInnoDB Row OperationsInnoDB Semaphores Wait

在之前的版本里，如果一台高负荷的机器重启后，内存中大量的热数据被清空，此时就会重新从磁盘加载到Buffer_Pool缓冲池里，这样当高峰期间，性能就会变得很差，连接数就会很高。在MySQL5.6里，一个新特性避免的这种问题的出现。你只需在my.cnf里，加入如下：innodb_buffer_pool_dump_at_shutdown = 1解释：在关闭时把热数据du

MySQLDump在使用之前一定要想到的事情如果mysqldump执行的过程中需要flush tables,而正在此时,有一个慢SQL正在运行,这时mysqldump会被阻塞（waiting for table flush）,并且其他连接对这个表的所有操作（甚至查询）都被阻塞.系统Hung了.这个问题在XtraBackup备份的时候同样存在.如果是人工执行,一定要开启另

前言在实际生产环境中有时会发现大量的sql语句处于waiting for table.. 状态中，有时候看起来会让人觉得困惑，本文将讲解此状态产生的原因及解决办法。正文本文中用到了lock table来模拟实际情况， 首先介绍一个lock tables需要注意的事项，如果在一个session中使用了lock tables，那么在此session中将只能访问获取到lock

简介Xtrabackup是由 Percona 开发的一个开源软件，可实现对 InnoDB 的数据备份，支持在线热备份（备份时不影响数据读写）。备份时，Xtrabackup 会将 Master 的 binlog 信息记录在 xtrabackup_slave_info 文件中，通过此信息可以方便的搭建主从复制。XtraBackup 有两个工具：xtrabackup 和 innoback

--mysql允许在session或者global级别动态设置binlog_format的值，做在更新很多行时，可以设置 binlog_format = 'STATEMENT' 以加快数据应用到备库上 A session that makes many small changes to the database might want to use row-based logging. A se

技术的争论假如现在需要对user表的username字段和last_update_time字段建立组合索引，有如下两种方案方案A:index(username,last_update_time)方案B:index(last_update_time,username)到底哪种好呢？select something from users where user

MySQL · 性能优化· Group Commit优化背景关于Group Commit网上的资料其实已经足够多了，我这里只简单的介绍一下。众所周知，在MySQL5.6之前的版本，由于引入了Binlog/InnoDB的XA，Binlog的写入和InnoDB commit完全串行化执行，大概的执行序列如下： InnoDB prepare （持有prepare_c

--在mysql5.6之后查看分区采用show plugins;--不论创建何种类型的分区,如果表中存在主键或唯一索引时,分区列必须是唯一索引的一个组成部分mysql> create table t1(id int not null,id2 int not null,unique key(id)) partition by hash(id2) partitions 4; ERROR

从MySQL迁移到MongoDB，在导入旧数据的过程中，遇到了些许波折，犯了不少错误，但同时也学到了不少知识，遂记录下来。公司为这个项目专门配备了几台高性能务器，清一色的双路四核超线程CPU，外加32G内存，运维人员安装好MongoDB后，就轮到我了，我习惯于在使用新服务器前先看看相关日志，了解一下基本情况，当我浏览MongoDB日志时，发现一些警告信息：WARNING: You ar

--安装yum包 yum -y install bzr libtool --对压缩包进行解--注意不要在mysql的官网下载，因为其只支持mysql不支持pghttps://github.com/akopytov/sysbench/tree/0.4tar zxf sysbench-0.4.12-1.1.tgz mv sysbench-0.4.12-1.1 sysbenchunz

--MySQL 5.5新增一个存储引擎：命名PERFORMANCE_SCHEMA ,主要用于收集数据库服务器性能参数performance_schema提供以下功能：提供进程等待的详细信息，包括锁、互斥变量、文件信息；保存历史的事件汇总信息，为提供MySQL服务器性能做出详细的判断；对于新增和删除监控事件点都非常容易，并可以随意改变mysql服务器的监控周期，例如（CYCLE、MICR

--mysql中默认锁超时为50sselect * from information_schema.SESSION_VARIABLES sv where sv.VARIABLE_NAME like '%timeout%';mysql> show variables like '%timeout%';+-----------------------------+----------+| Va

MySQL的主从搭建大家有很多种方式，传统的mysqldump方式是很多人的选择之一。但对于较大的数据库则该方式并非理想的选择。使用Xtrabackup可以快速轻松的构建或修复mysql主从架构。本文描述了基于现有的从库来快速搭建主从，即作为原主库的一个新从库。该方式的好处是对主库无需备份期间导致的相关性能压力。搭建过程中使用了快速流备份方式来加速主从构建以及描述了加速流式备份的几个参数，供大家参

【问题背景】1、  针对MySQL文件比较大，需要压缩的数据库。 如500G数据库，xtrabackup备份后文件为500G，备份完成后再压缩打包，相当于文件读写3次。2、  对于磁盘IO不好的从库，整个过程会持续好几个小时，有时把IO直接搞到100%, 导致从库延时很大。3、  xtrabackup的xbstream流备份，直接备份后，通过管道直接压缩，这样把原约3次的I

两台数据库都报slave同步失败了，先说明一下环境，架构：lvs+keepalived+amoeba+mysql，主主复制，单台写入，主1:192.168.0.223（写）主2:192.168.0.230好吧，先show slave status \G看一下同步失败的具体报错吧登录主2库查看：mysql> show slave status \G *************

“binlog_cache_size"：在事务过程中容纳二进制日志SQL语句的缓存大小。二进制日志缓存是服务器支持事务存储引擎并且服务器启用了二进制日志(—log-bin选项)的前提下为每个客户端分配的内存，注意，是每个Client都可以分配设置大小的binlogcache空间。如果读者朋友的系统中经常会出现多语句事务的华，可以尝试增加该值的大小，以获得更有的性能。当然，我们可以通过MySQL的以

Mysql支持两种XA： 外部XA应用程序是协调者（coordinator），参数事务的服务器节点就是资源管理器（resource manager），目前存在两个问题：问题1：当参数分布式事务的协调者退出后，即使参与分布式事务的节点都已经PREPARE成功。从理论上说，这时这些分布式事务是悬挂事务，协调者恢复后可以进行最后的第二阶段提交。但是这在MySQL数据库中是

在mysql 5.5和5.5以前innodb的logfile最大设置为4GB,在5.6以后的版本中logfile最大的可以设为512GB.innodb的logfile就是事务日志，用来在mysql crash后的恢复.所以设置合理的大小对于mysql的性能非常重要在5.5的版本中，default设置为5M.在新建的mysql服务器中，需要尽快修改该参数.  logfile大小对

Mysql InnoDB行锁实现方式 InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！ 在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的

背景：之前面试被问到这么一个问题，数据库两个transaction，当transaction1在update某一行的时候，transaction2在select的时候会不会block。我以前用MySQL做过测试，印象是可以，但是面试官提出质疑，今天我用MySQL验证这个问题的仔细研究了一下MySQL的后台实现，后来再网上发现了下面这篇文章非常就转过来，不过文中有些地方逻辑上好像不太对，我没

前言：        同事的业务场景是，按照cid、author分组，再按照id倒叙，取出前2条记录出来。        oracle里面可以通过row_number() OVER (PARTITION BY cid,author ORDER BY id DESC) 表示根据cid,author分组，在分组内部根据id排序，而此函数计算的值就表示每组内部排序后的顺序编号（组内连

MySQL 本身通过 show slave status 提供了 Seconds_Behind_Master ，用于衡量主备之间的复制延迟，但是今天碰到了一个场景，发现 Seconds_Behind_Master 为 0 ， 备库的 show slave status 显示 IO/SQL 线程都是正常的 ， MySQL 的主库上的变更却长时间无法同步到备库上。如果没有人为干预，直到一个小时以后， 

要使用该功能，mysql的版本必须在5.0.37版本以上。否则只能使用explain 的方式来检查。profiling 功能可以了解到cpu io 等更详细的信息。show profile 的格式如下：SHOW PROFILE [type [, type] ... ]    [FOR QUERY n]    [LIMIT row_count [OFFSET offs

如果说插入缓冲是为了提高写性能的话，那么两次写是为了提高可靠性，牺牲了一点点写性能。 部分写失效想象这么一个场景，当数据库正在从内存向磁盘写一个数据页时，数据库宕机，从而导致这个页只写了部分数据，这就是部分写失效，它会导致数据丢失。这时是无法通过重做日志恢复的，因为重做日志记录的是对页的物理修改，如果页本身已经损坏，重做日志也无能为力。 两次写机制从

InnoDB的主线程的代码，在每秒执行的任务中：存在固定的只刷新100个脏页到磁盘、合并20个插入缓冲。在写密集的App中，每秒中可以能产生大于100个的脏页，或是产生大于20个插入缓冲，此时的master thread似乎会忙不过来，或者说它总是做得很慢。即使磁盘能在1秒内处理多于100个页的写入和20个插入缓冲的合并，由于hard coding（硬编码）master thread也只会选择刷新

--mysql中的int分为有符号与无符号类型对于int类型,其无符号类型最大为4294967295(大约42亿),如果数据量增大,则其不够用,注意--在建立int类型数据时,建议不要使用zeriofill参数,其会造成数据混乱mysql> create table t3(id1 int unsigned,id2 int(6) zerofill);mysql

MySQL 服务器硬件和操作系统调节:1. 拥有足够的物理内存来把整个InnoDB文件加载到内存中——在内存中访问文件时的速度要比在硬盘中访问时快的多。2. 不惜一切代价避免使用Swap交换分区 – 交换时是从硬盘读取的，它的速度很慢。3. 使用电池供电的RAM（注：RAM即随机存储器）。4. 使用高级的RAID（注：Redundant Arrays of Inexpensiv

一、Nagios简介　　Nagios是一款开源的电脑系统和网络监视工具，能有效监控Windows、Linux和Unix的主机状态，交换机路由器等网络设置，打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员，在状态恢复后发出正常的邮件或短信通知。　　Nagios原名为NetSaint，由Ethan Galstad开发并维护至今。NAGIOS是一个缩写形

如果某一项中设置的是varchar(50)那么对英文当然是50那么对中文呢utf-8的中文占3个字节那么,这个varchar(50)是不是只能存16个汉字了? 不是这样的，mysql低版本之前是这样的，但是5.0以后就不是了mysql varchar(50)  不管中文 还是英文 都是存50个的，但是一个表中所有varchar字段的总长度跟编码有关，如果是utf-8

起因：在innodb表上做count(*)统计实在是太慢了，因此想办法看能不能再快点。现象：先来看几个测试案例，如下一、 sbtest 表上的测试show create table sbtest\G*************************** 1. row ***************************Table: sbtestCreate Table: CRE