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在更新的时候也可能碰到这类问题.