Monthly Archives: November 2014

MySQL replication prefetch功能介绍

By | 2014-11-28

https://github.com/yoshinorim/replication-booster-for-mysql https://code.launchpad.net/mysql-replication-listener 主从延迟的瓶颈可能有以下几个原因: 1. master为多线程更新, slave 的sql_thread则为单线程更新, 这意味着master大量的更新必然会引起主从延迟的持续增大; 2. slave不对外服务的原因, buffer还未有记录相关的信息, 这造成了sql_thread在重放sql的时候要先通过磁盘IO找到相应的记录再加载到buffer进行更新, 即意味着磁盘IO造成了主从延迟的瓶颈;

MySQL 5.6主从故障处理说明

By | 2014-11-26

MySQL 5.6主从故障处理说明 5.6增加GTID特性作为主从复制的新协议, 如果开启需要指定 gtid_mode 为 on, 如果不开启主从复制采用传统的复制协议, 故障处理同5.1, 5.5. 以下讨论采用gtid协议后的故障处理; GTID配置 http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-howto.html 与传统的复制相比, GTID去掉了文件及位置的参数信息, 改用 MASTER_AUTO_POSITION 替换.

MySQL 5.6参数说明

By | 2014-11-25

MySQL 5.6参数说明 core_file Server崩溃的时候将相关信息写到core文件里, 系统产生core文件需调大ulimit -c 参数, 文件名默认以.pid结尾. explicit_defaults_for_timestamp 在MySQL中,timestamp类型不同于其它标准数据类型的处理,默认情况下, timestamp列指定为允许NULL属性的话,给该列NULL值即给该列current timestamp值; 第一个为timestamp类型的列可以指定DEFAULT CURRENT_TIMESTAMP或 ON UPDATE CURRENT_TIMESTAMP 属性进行自动更新; 不是第一个的timestamp类型列, 如果没有指定NULL货DEFAULT属性,则DEFAULT ‘0000-00-00 00:00:00’赋于其值。 explicit_defaults_for_timestamp选项改变这种不标准的处理行为, timestamp列没有指定NOT NULL或允许NULL, 赋于该列NULL,而不是current timestamp; 除非DEFAULT CURRENT_TIMESTAMP or ON UPDATE CURRENT_TIMESTAMP显示指定, 否则timestamp列不会自动更新; 显示指定NOT NULL属性且没有给与DEFAULT信息会被认为没有默认值, 插入的时候,如果开启SQL mode,则返回错误, 没有开启则默认值为’0000-00-00 00:00:00’并且产生一个警告。

max_allowed_packet and binary log corruption问题说明

By | 2014-11-19

max_allowed_packet参数指定了Server可以读取或创建的最大网络包的大小,在5.6.5版本之前默认为1MB, 5.6.6及之后的版本默认为4MB, 该参数最大可指定1GB大小, 在主从环境中关于该参数的限制有下面2点: 1. master端写binlog中的事件不能大于max_allowed_packet参数指定的大小; 2. 在所有slave 节点上的max_allowed_packet参数的值应该和master一样; 正常情况下, slave 得到 max_allowed_packet 相关的错误信息, 通常加大max_allowed_packet(上限1GB) 就可以处理该问题, 不过在异常情况下, 错误信息可能提示存在大于1G的包, 这是不可能的错误, 大部门原因是由于binlog文件中断引起, 举例如下:

应用程序更新Illegal mix of collations错误说明

By | 2014-11-12

完整错误信息如: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (gbk_chinese_ci,IMPLICIT) for operation ‘=’ (1267) INSERT INTO …. name = value … 错误信息描述了操作符 = 两边的数据编码不一致而引起的冲突, 常见的原因有表的字符集可能为latin1, 而应用程序等的字符集为gbk, 当然基于这样的原因,应用程序等select出来的结果集也可能为乱码状态. 确保应用和DB端的编码统一是很重要的事情, 尤其是一些开发者初期不注意编码和排序规则, 后期扩展则出现各种掣肘的问题, 比如Server端的character_%编码和表的编码不一致, 使用Server端的变量创建的表相关的trigger或procedure在更新的时候也可能碰到这类问题.

表记录清理注意事项

By | 2014-11-12

常规表清理见 pt-archiver 工具: pt-archiver 1 如果表更新频繁, 不要直接使用delete … where id <= ? and update_time < ? 这类范围或结果集过大的SQL, 避免delete操作时间过长吃满thread资源影响服务; 2 如果满足条件的记录很多, delete 操作会是耗时操作,同样会引起1中的问题, 应用或脚本应该找出结果集范围对应的主键或唯一键信息, 通过分组方式一组一组的删除相应的id列表; 3 给予delete操作低优先级, 减少影响表的正常更新, 如 delete low_priority from table …; 4 如果结果集太大, 分组间隔可以增加sleep信息避免频繁更新引起的io或负载问题; 5 不要单条记录清除, 如果记录多, 与DB的交互会过于频繁; 脚本清理记录举例如下: (1) 按条件取出主键id的信息, 存入数组@list中; select id from user where count <= ? and update_time <… Read More »

SQL::Audit审核MySQL query说明

By | 2014-11-05

SQL 审核说明 1.概述 SQL::Audit模块审核是以MySQL audit插件为基础, 通过分析SQL记录的来源(audit.log或socket)和使用情况(存储引擎, 索引使用,字符集等)以期避免开发对生产环境主机的影响。 审核部分主要包括:操作日志记录、 统计分析、 SQL改写、 SQL索引分析、 SQL安全、 邮件发送。 见: https://github.com/mcafee/mysql-audit https://github.com/arstercz/cz-sql-audit 2.审核流程 sql_audit脚本读取audit插件的日志信息, 通过SQL::Audit完成检查和分析, 异常的信息通过邮件发送到开发组. 同类的sql在Memcached中缓存一天时间, 避免重复分析.