Tag Archives: percona

percona UDF 介绍

By | March 24, 2017

简介 在较新的 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 slave 延迟复制

By | June 1, 2015

MySQL slave 延迟复制 延迟复制是一个很简单的概念,区别于传统的异步复制(接近实时), 比如用户误操作, 删除了重要的表, 延迟复制特性保证了用户有机会从延迟的 slave 中恢复误删除的表. 该特性的问题在于需要保证用户有足够的时间从 slave 阻止误操作复制的发生. 要理解该特性如何实现, 我们先简单回顾下 MySQL replication 如何实现, 见下图: 当 master 有一个更新操作(create, drop, delete, insert, update 等), 该更新操作应用到本地的磁盘并写到 binary log 里,之后更新操作异步(接近于实时)的从master 的 binary log 复制到 slave 的 relay log, 最后 slave 的 sql thread 线程读取 relay log, 将更新操作应用到 slave 表中.

pt-osc chunking handles multi-column indexes poorly

By | May 21, 2015

最近使用工具 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 »

TokuDB 使用简单说明

By | April 23, 2015

按照官方的介绍, TokuDB 引擎是可扩展的,支持事务 ACID 特性, 支持多版本控制(MVCC), 这几点等同 InnoDB 的特性, 不过对基于索引的查询做了很好的改进, 还提供了支持在线表更改的支持(不是所有字段都支持, 后面再说明), 在磁盘和缓存方面也做了很好的改进. TokuDB 结合 松散树索引(Fractal Tree indexing) 可以应用于高负载的大量写(write-intensive)的场景里. 现在的限制还比较多, Percona 从 5.6.19-67.0 开始支持 tokudb, 现在还只能运行到 64 位的 Linux 版本中, Debian 6.0 和 Ubuntu 10.0.4 因为 gcc 版本冲突的原因也不支持, 同时也不支持外键(foreign key)功能,如果表有外键,切换到TokuDB引擎后,此约束将被忽略. 其它版本(mariadb, mongodb)的 TokuDB 引擎支持可以从 Tokutek 的github 页面查找: https://github.com/Tokutek

top 10 percona toolkit tools(五)

By | November 4, 2014

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://zhechen.me/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函数的冲突率还是偏大的, 如果恰好有几个字符串算出的结果一样, 则该工具出现漏报的可能性, 误报的可能性不能完全杜绝。

top 10 percona toolkit tools (四)

By | October 19, 2014

7. pt-query-digest http://www.percona.com/doc/percona-toolkit/2.2/pt-query-digest.html 分析query 语句: 该工具可用于统计分析 slow log, processlist, binary log 和 tcpdump 相关的sql 语句信息, 生成详细的报表供管理员查看或排错。我们最长用的可能是分析 slow log 和 tcpdump 文件, 基于以下几种场景: (1) 想详细了解过去一段时间慢查询的整体状况,比如哪类的 sql, 这类 sql 主要的时间分布(us, ms, 还是 s 级别的居多), 主要的行数检查, 数据发送量等; (2) 一些执行时间短的 sql 不会出现在 slow log 或 processlist 列表中,管理员也难以全部抓取相关的sql, 可以使用该工具分析tcpdump监听MySQL端口的日志信息, 得到较为全面的报告列表, 包括的列表同(1)中的信息; (3)该工具早期的版本支持sql重放等工具, 对InnoDB的预热需求是一个不错的手段, 详见 http://zhechen.me/keep-your-slave-warm/, 也支持统计分析tcpdump监听memcached生成的日志文件。

top 10 percona toolkit tools (三)

By | September 14, 2014

5. pt-summary http://www.percona.com/doc/percona-toolkit/2.2/pt-summary.html 搜集系统信息: 非常详细的列出系统相关的信息, 包括硬件信息, CPU, Memory, 分区, 当前运行的进程, 网络连接, 网卡等信息。对于不经常做更新的系统而言, 该工具可以很好的当做系统运行镜像来使用。该工具和pt-mysql-summary类似, 但更侧重于系统信息的搜集。同样以bash shell编写。 输出信息如下: # pt-summary # Percona Toolkit System Summary Report ###################### Date | 2014-09-14 11:36:21 UTC (local TZ: CST +0800) Hostname | cz Uptime | 27 days, 3:20, 1 user, load average: 0.00, 0.00, 0.00 … # Processor ################################################## Processors |… Read More »