Category Archives: percona

percona soft

有效升级 MySQL 表的 ip 字段

By | 2018-08-07

在文章 IPv6 使用及注意事项 中我们提到了应用程序如果要支持 IPv6, 需要关注相关数据库的修改, 不过由于业务设计的不同, 有些程序可能使用 char, varchar 等存储 ip 字符串, 有些程序也可能考虑到索引效率使用 int unsigned 存储 ip 的整形. 不过对于 IPv6 地址, 由于其 128 bit 的长度, 决定了 IP 地址数量为 (2^128 – 1), 这个值对 64 位的主机而言无法存储, 所以建议使用 varchar 类型存储所有的 IPv6 地址. MySQL 5.6 及以上的版本可以使用 hex(inet6_aton(ipv6address)) 的方式将 ipv6 存到 binary 或 varbinary 的字段中, 不过为了统一处理, 下文则主要介绍修改 ip 字段到… Read More »

使用 Percona Server auto manager 管理数据库

By | 2018-04-02

介绍 Percona Server auto manager 是基于 percona-server-5.6.39.83.1 的一个分支版本, 其增加了 memcached 记录和 sql 过滤的功能, 用来降低管理员操作数据库的风险. 不同于 inception 的深度修改, Percona Server auto manager 仅修改客户端的 client/mysql.cc 和 client/mysqldump.c, 不影响 server 端的功能. 说明: memcached 功能用来记录用户输入的用户名及密码, 这点在一次一密登录 mysql 的时候比较有用, 由于 mysql 命令行是将最终的密码哈希结果传给 server, 所以中间件等软件无法得知用户输入的验证信息, 如果一次一密是有状态的则可以通过时间等方式算出验证信息 比如 google totp, 如果是无状态的则中间件代理等工具无法得知验证信息. 当然我们也可以在 client 代码层完成验证, 不过这种方式存在局限性, 不够通用; sql 过滤功能则主要用来限制开发者或管理员对数据库表的修改, 可以使用 –skip-sql-filter 选项忽略此功能, 具体的限制规则见下文.… Read More »

percona UDF 介绍

By | 2017-03-24

简介 在较新的 percona 分之版本中, 其提供了三个自定义的哈希函数, 分别为 fnv_64, fnv1a_64 和 murmur_hash, 这三个函数可以提供更快速度和更小碰撞率的哈希计算, 从这点看可以用来替换 md5, crc32 等函数, 而且由于速度快、碰撞率小的特性, 这些函数也可以作为一致性哈希函数来使用. 如何安装这三个函数详见 udf_percona_toolkit. 函数介绍 大致了解这三个函数后, 再来简单说明这三个函数的相关实现. fnv 哈希算法 FNV哈希算法最早在1991年提出, 是 Fowler-Noll-Vo 的简写,其以三位发明人Glenn Fowler,Landon Curt Noll,Phong Vo的名字来命名的. 另外现今很多流行的中间件或分布式工具都有该函数的申请, 比如 twemproxy 等工具. FNV能快速hash大量数据并保持较小的冲突率,它的高度分散使它适用于hash一些非常相近的字符串,比如URL,hostname,文件名,text,IP地址等. 现有的版本有 FNV-1 和 FNV-1a, FNV-0 已经废弃, FNV-1 和 FNV-1a 两个函数生成的 hash 值有以下两个限制(FNV offset basis 为无符号整数): 无符号整型; hash 值的位数为… Read More »

mysql_upgrade 升级错误出现 table doesn’t exist 错误整理

By | 2016-02-29

从 MySQL 官方的 5.1.48 版本升级到 Percona 5.1.73 版本, 在使用 mysql_upgrade 的时候出现一些错误, 该原因可能为innodb表文件丢失或损坏, 或使用了不正确的方式删除表. 错误信息如下所示: [root@cz ~]# cd /opt/Percona-Server-5.1.73-rel14.12-624.Linux.x86_64/ [root@cz Percona-Server-5.1.73-rel14.12-624.Linux.x86_64]# ./bin/mysql_upgrade -S /export/mysql/node3307/data/s3307 -p –verbose … Repairing table test.蔢^ Error : Table ‘test.蔢’ doesn’t exist status : Operation failed test.蔢^ Error : Table ‘test.蔢’ doesn’t exist status : Operation failed test.蔢^ Error : Table ‘test.蔢’… Read More »

pt-osc chunking handles multi-column indexes poorly

By | 2015-05-21

最近使用工具 pt-osc (pt-online-schema-change) 对一张约200w记录多列组成的唯一索引的表进行更改索引操作, 在第一条 chunk 操作的时候就开始报错(版本 pt 2.2.7 和 pt 2.2.11), 如下所示: [root@cz table_check]# pt-online-schema-change –alter=”drop key idx_guux, add unique key idx_ugux(user_id,goods_id,updatetime,keycode)” A=utf8,h=cz1,P=3306,D=mybase,t=test –ask-pass –execute –nocheck-replication-filters Enter MySQL password: Found 1 slaves: cz2 Will check slave lag on: cz2 Operation, tries, wait: copy_rows, 10, 0.25 create_triggers, 10, 1 drop_triggers, 10, 1 swap_tables, 10, 1… Read More »

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 替换.

top 10 percona toolkit tools(五)

By | 2014-11-04

9. pt-table-checksum http://www.percona.com/doc/percona-toolkit/2.2/pt-table-checksum.html 主从表数据一致校验: 该工具通过分组(chunk)方式以hash, md5, cac32或自定义函数生成每个分组数据的检验串, 分别在master和slave端执行, 如果每个分组的校验串一致, 则认为该分组的数据在master和slave一致。详见: http://arstercz.com/mysql%E4%B8%BB%E4%BB%8E%E6%95%B0%E6%8D%AE%E4%B8%80%E8%87%B4%E6%80%A7%E6%A0%A1%E9%AA%8C/, 这种方式可以相对有效的找出主从中哪个chunk组的数据不一致, 进而再继续细分chunk, 找出具体的行。 不过分组校验不一定能够严格校验主从的不一致, 这依赖校验函数的冲突率有多大, 默认的crc32函数的冲突率还是偏大的, 如果恰好有几个字符串算出的结果一样, 则该工具出现漏报的可能性, 误报的可能性不能完全杜绝。