饿了么MySQL多IDC架构设计

关于饿了么MySQL多IDC架构外面材料比较多,而且目前属于上线运行,运行比较好的业务,这里做一个记录。

分区依据: 把数据库首先分Zone,然后依赖于地区ID分布到不同Zone中,同一个Zone依赖于商户ID分布到不同分版中(shard)。每个Zone在不同IDC中进行互备。

底层数据同步依赖于自研的DRC进行数据同步。

使用上面的结构的好处就是两个IDC基本可以做到同时对外提供服务,不好的地方是,基本是原来的数据量直接翻倍的容量。

根据数据使用上不同,把Zone拆分为: 全局数据GlobalZone(单IDC写入,多IDC可读),多活架构(真正多活)。

全局数据GlobalZone

这种架构相于对简单,单节点写入, 容易控制数据的一致性。

多活架构(shardingZone):

数据分维度治理,每个单元的业务,都在自已的IDC中完成,不依赖于别的IDC。读和写都在本地IDC中完成, 正常情况下本地业务只需要本地机房的数据,对其它机房的数据无依赖,跨IDC数据延迟时无影响。

每个机房有独立一块区间的自增区间, 这块估计也是使用的自增的,1,3,5,… or 2,4,6,… 这种样子。 在业务设计上尽量让单个IDC接入的业务在单位IDC中完成,不依赖于其它IDC。 如果发生更新冲突,依赖于表里的DRC字段,判断谁是最新的数据,用最新数据覆盖旧数据。相当于主从复制处理中的1062错误(这块实现感觉并不严格),也是全程无锁设计,对于润秒时,可能有问题。

对于自增这块的,这块设计上,可以考虑用snowflake类似的算法,生成ID,可以让每个Zone保持某个特殊的数开头,这样会更清晰一点,但也要考虑顺序在里面,这也许是饿了么直接采用主建的原因。

饿了么在MySQL多IDC设计中遵循:

  1. 业务内聚,一个订单位的处理过程在一个机房中完成,减少可能的延迟。
  2. 可用性优先,优先保证系统可用,让用户可以下单吃饭,容忍暂时的数据不一致,事后修复。
  3. 保证正确性, 在确保可用的情况下,需要对数据做保护以避免错误
  4. 业务可感,业务团队修改逻辑,能够识别出业务单元的边界,只处理本单元的数据,打造强大的业务状态机,能发现和纠正错误。(这点我觉的才是核心,任何多idc,永远可用的业务,不能做到业务没感知,如果要求业务没感知的DB跨IDC设计都是扯蛋。)

 

如果你有其它感兴趣的内容,可以入群联系我。一同交流。

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

PHP连接MySQL 8.0报错

知数堂推了两期关于MySQL 8.0的公开课 https://zst.ke.qq.com/ ,很多程序员,也按耐不住了,要升级到MySQL 8.0. PHP是世界上最好的语言。 骚年肯定也不会落后。但升级到MySQL 8.0后,马上面监到两个问题。

  1.  PHP连接上MySQL。 同样的程序 MySQL 5.7没事,换了MySQL8.0 报: Access Denied for user ‘XXXX’
  2.  Server sent charset (255) unknown to the client. Please, report to the developers in … on line X . 不识别字符集

人生艰难,再次打击我们PHP程序员。 好吧! MySQL 8.0 发生重大变革了:

1. 认证方法更新为了: caching_sha2_password
2. 字符集改成了默认: utf8mb4

据说字符集的已经在php-7.20 支持了。 不过升级PHP也不容易。 我们先几个兼容支持方法吧。

关于认证和字符集兼容:

1. 配置文件[mysqld]部分

[mysqld]
default_authentication_plugin=mysql_native_password
character_set_server =utf8

上面这两个配置,把MySQL 8.0 认证更改成老的方法,字符集更改成原来的:utf8.

2. 创建基于native_password的帐号

CREATE USER 'wubx'@'%' IDENTIFIED WITH mysql_native_password BY 'zstzst';
GRANT ALL PRIVILEGES ON *.* TO 'wubx'@'%';

3. 创建DB

CREATE DATABASE IF NOT EXISTS `zst` COLLATE 'utf8_general_ci' ;
show create database zst;

确认字符集是utf8.

 

4. 使用我们新创建的帐号连接zst,应该万事Ok。 如果遇到其它问题,欢入裙交流

 

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

RadonDB架构解析

RadonDB在DTCC大会主会场宣布开源了, 一个期待已久的产品终于走进了开源社区。 感谢青云领导层的对技术贡献的情怀。

做为一个MySQL从业人员,从我对RadonDB关注到使用,将近有半年多时间,这次RadonDB开源,基本也全程参与,在这里开源计划到最终在DTCC展现,也深深感受为开源,公司也需要付出很多很多。

这里了为了能快速的让大家了解RadonDB,我这里对RadonDB架构做一个简单的梳理,本着更容易大家理的态度不夸大,更利于接近于实质, 同时也方便大家深入去学习RadonDB。

RadonDB整体架构

RadonDB官网: http://radondb.io

RadonDB基于Golang开发,由四部分组成:

  •    Radon SQL 路由层 ,Proxy模式  下载地址: https://github.com/radondb/radon
  •    Xenon  MySQL Plus高可用组件 下载地址: https://github.com/radondb/xenon
  •    存储节点 ,官方MySQL或是Percona分支,推荐一主两从,增强半同步
  •    计算节点  ,目前使用的TokuDB做为全量数据存储,推荐优化后的分支: https://github.com/xelabs/tokudb

 

Radon作用:

  •    SQL解析及路由,混合OLTP和OLAP
  •    分布式事务支持
  •    用户验证, 在Radon中验证,不需要MySQL端创建
  •    连接池功能
  •    SQL审计日志记录(默认没开启,开启后会记录全量的请求,用于审计使用)
  •    记录全量SQL的binlog,用于计算节点数据实时复制
  •    原生集群支持,配置在节点间自动同步

Xenon(MySQL Plus)作用:

MySQL的高可用组件,这个也是我一直觉的增加半同步出现后,是MHA的一个最佳替换产品。 还有很多好玩的功能可以去在上面扩展,主要功能如下

  •   MySQL高可用选主
    • 基于Raft(依赖于GTID)选主
    • 数据一致性依赖于增强半同步(semi-sync)
  • 故障切换动作
    • 借助于配置中leader-start-command  & leader-stop-command  调用相应的脚本完成
    • 这一块也可以自已扩展,结合Consul,ZK来玩
  • MySQL故障后切为从节点后,自动拉起并修复制关系,也可以自动重建(需要配置)
  • 集成Xtrabackup备份调度实现

MySQL存储节点:

利用MySQL的增强半同步构建,一主两从。

主要用于存储数据中的某个分片,有点类似于Redis Cluster结构中的一个主从分组。 官方使用三个节点,为了高可用,推荐至少两个节点。 实验环境,也可以使用一个节点(在单节点结构下MySQL Plus不是必须的)

计算节点:

目前利用作者优化过的TokuDB版本存储分库分表后的全量数据,这样复杂的SQL请求可以转到该节点上运行,官方目前该节点配置是三个,也可以是1-2个, 如果复制SQL比较多,这个地方需要增多一点,实现多个从节点上的SQL运算。 官方反馈,这个地方也需在找新的技术替代,如: Greenplum或是ClickHouse,也可能是MariaDB的ColumnDB。

该节点要担任:SQL中无分区Key的查询,join查询等复杂类的操作。 该节点数据主要靠Radon给多写实现。 如果没这部分操作,可以不要计算节点。不过,推荐放置,这样相当于有一个地方有一个全量数据。对数据安全也是一个增强。

同样该节点也可以后续加入,通过https://github.com/xelabs/go-mydumper 全集群某个分片全量迁移,然后在结合Radon记录的GTID信息实现增量同步。

计算节点可以说是RadonDB中的一个亮点,借助于Radon实现了一个全量数据维护,这复杂的查询或是统计的分析都可以到计算机节点实现,这个地方如果将来换成一个OLAP类的数据库,就更回完美。

借用官方的架构图供大家在看一下:

 

RadonDB优点

大致对整个结构有一个了解后,我们再看看几个实质的问题,RadonDB有优秀的地方,大致总结以下几点:

  1.  自动分库分表,透明扩容。

    • 在RadonDB中目前只支持Hash拆分,默认把一个表分成: 4096个slot,实际分配到多个子表中,例如青云产品中配置成32个子表,那么每个子表对应128个Solt(4096/32)。 例如创建一张表:
    • create table zst_user(id int not null, wubx varchar(32))   partition by hash(id)
    • 如果有一个MySQL存储分片,会在这个存储分片上建出来32张实际的表,每个表对应id Hash后的128个Slot
    • 诱明扩容
      • 在RadonDB,可以配置当一个表增长超过多大时,当集群中添加节新的存储节点时,会动态进行数据迁移,默认配置单表超过1G,这个步骤迁移是通过利用go-mydumper导出,记录Radon上该节点的GTID,然后到目标节点导入,再通过Radon上补Binlog方式上后,实现访问路由变更。
  2.  对SQL执行没有限制

    • 带有分区Key的查询,可以路由的相应的存储节点计算
    • 不带分区key的会路由到所有存储节点计算,然后在radon中合并
    • 对于有条件及含聚集函数的查询大多还是在存储节点运算后在Radon上合并返回结果,这块需要进一步分析一下执行情况。
    • 对于join,子查询等复杂类的SQL需要计算节点支持,在计算节点运算后返回给前端。
  3.  自带高可用套件: Xenon (MySQL Plus)

    • 支持MySQL节点上故障快速切换及利用API指令把节点重建(调用的xtrabackup)
    • 在数据一致性,安全性方面,还是依赖于MySQL的增强半同步,所以也推荐三个节点。

RadonDB不足之处:

RadonDB 现在可以说刚出江湖,核心代码1万行左右, 学习Golang的同学不要错过。 加上其它类库引入。 Radon代码11万+, Xenon代码5万行+ 整体来说还是一个轻量级结构。

目前还有一些不足及改进的地方:

1.  Radon 这个Proxy模型中, 目前默认提供单节点读写,支持读IP,业务层需要自已处理读写分离。 这样实质的业务压力还是在Proxy这一层(能不能抗住业务,需要亲测一下),需要考虑多节点同时提供读写能力。(这个其实现在Proxy模型都号称支持多节点同时读写,但对于数据一致性要求强的环境差不多都会出问题)。 这块官方为了金融环境,还是比较保守,实质上多个Radon可以成为无状态对外提共服务,更新冲突,可以让数据库自已来处理。 多个Proxy也相当于更多的连接, 这块实际测试中,可以考虑让多个Radon都对外服务,提高Radon的利用率。

2. Xenon(MySQL Plus)相对独立,没有和Radon有更多的交互, 这个是一个亮点,Xenon后续也可以用到不同的分布式结构下面。但做为产品中的一个组件,还是需要考虑和Radon有更多的交互,如:复制延迟情况, MySQL节点故障后,新选举出来的主,可以同步给Radon,把现有的VIP方案去掉。  这种分离的结构,也给了我们使用者更多灵活的空间,例如结构Consul来玩。感觉有利有弊,有很大的优空间。非常看好Xenon(MySQL Plus),绝对的一个高可用的利器。

3. 某些方面还有待提高,例如计算节点添加, 借助于Radon的Binlog实现,这一块也可以借助于官方的复制实现。需要进一步讨论。 这块可以通过后续DBA的运维手段改善。全量数据维护这块, 也是后续中维护的一个难点,需要提前规划好。

4. 集群中现在成员资源使用绝对不饱合,估计使用在30%以下。 Radon目前单节点提供服务,存储节点,也可只有从节点提供服务。  这块也是金融级高可用的通命,特别是两地三中心架构中,更加浪费。

总的感受

RadonDB  整体非常不错,设计方面,非常独道,属于一个多年开发经验,理解开发中痛点的一个数据库产品MyNewSQL,代码也比较精简,觉的也是学习Golang不错的项目。对于理解数据库架构设计也是一不错的东西。知数堂准备把RadonDB放置到课堂中做为教学内部中的一部分。也欢迎大家一块来交流RadonDB相使使用经验。 欢迎加知数堂-王者侠谷中交流:

 

 

 

滴滴MySQL架构及自动化运维工作

在上周4.14 北京3306π活动中,看到朱进桌分享了滴滴的MySQL架构及一些自动化工作,一方面感吧,滴滴同学面对的DB压力也比较大,另一方面也赞叹滴滴的DBA同学牛。

在这里小记一下:

滴滴的MySQL架构

 

这个结构算是一个数据库四层结构和美团,小米的数据库架构都有点类似,整体结合如下:

  • 第一层是基于LVS的一个FNAT接入, 对后面的dbproxy做负载均衡
  • 第二层是DBproxy ,在滴滴的dbproxy中好象没有分库分表功能,可以理解为是ProxySQL的基于port的分组或是读写分离(细节不多)
  • 第三层 基于MHA做的主从高可用切换。 看样子滴滴的数据库还没升级到GTID :),估计也是数据量太大,不好升级。 不过,还是值得考虑升级到MySQL 5.7.
  • 第四层 MySQL主从这块采用,双主结构,后面接两个从库。这个结构GTID环境中非常好运维。有点失误忘了问作者,他们是不是使用的GTID复制。

 

滴滴数据库平台中主要模块

从上面的主要模块来看,大多是基于开源来构建,来的快。 也正所谓作者讲的,平台小的时僮做自动化不划算,平台做大,再来做自动化,推动实在太难。 采用开源的东西,小做改造就可以快速的实用起来。

滴滴DB自动化整体架构介绍

从整体结构上看, 在自动化平台中实现了: 自动化备份恢复, 自动化表结构变更, SQL审计,SQL统计等在线辅助系统。在自动化这块大量依赖于saltstack实现。

在大规模自动化平台saltstack目前在国内许多公司得到验证都是可行的。 而且效果不错,当年飞信的自动化运维也是大量的使用saltstack封装。

滴滴自动化平台技术栈

看了这个图也深深的感受到现在做个MySQL DBA不容易啊。 除了MySQL需要搞定外, 还需要一堆的周边工具待你发现,同时还要会一门语言能把这些串起来,现在运维及云平台语言,基于是Python和Golang的天下。 作者讲解的东西比较多,整体上觉的滴滴还属于中规中矩,踏实做事。

如果想了解更多3306π是滴滴自动化 PPT信息可以关注 3306pai公众号,回复“bj”获取 3306π北京的PPT打包下载。

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

新一代MySQL高可用:MySQL Plus

在基于MySQL传统复制的时代(MySQL版本低于5.5)MHA在MySQL高可用中可以说是独领风骚。在MySQL 5.6及GTID的出现后,MHA在这方面就显的不给力,和MHA作者交流,作者基本放弃该软件的维护,MHA作者现就职在Facebook,也没在使用MHA,他也认为在GTID环境下MHA存在的价值不大,不过你如果你还在使用传统复制,还是可以考虑使用MHA做主从的高可用(太老了,建议升级)。

下面我们围绕以下几点来讨论一下:

  1. 在MySQL 5.7 后为什么不需要MHA
  2. MySQL Plus 是什么,能解决什么问题
  3. MySQL Plus看他们如何搞定金融支持

MySQL 5.7后为什么不需要MHA

基于MySQL 5.7 GTID复制已经成熟,另外基于MySQL5.7的增强半同步性进一步提升: 所以在使用MySQL 5.7的复制可以使用: MySQL 5.7+GTID+增强半步, 在该结构中, 不存在会丢数据的问题。 所以MHA在这个结构基本失去了存在的意义。

但使用: MySQL 5.7+GTID+增强半步,也意为着新的知识,可能需要DBA同学们也要更新一下知识。而且在MySQL 5.7中引入binlog group commit, 又是对复制的一个加速。 所以说MySQL5.7 在复制完整性及性能上都有较大的提升,建议没升级的同学尽快升级了。

官方对MySQL 5.7的测试传送门: https://www.mysql.com/why-mysql/benchmarks/

MySQL Plus是什么,能解决什么问题

在3306π北京活动中 青云的蒙哲分享了青云RDS中高可用组件: MySQL Plus。 MySQL Plus是基于一套Raft构建的MySQL中自动选主及维护主从的套件,整体结构如下:

在该结构中Xenon之间会进行通信,在该结构中推荐三个节点的MySQL构建复制,听作者讲也支持两个节点的MySQL构建集群。

在MySQL Plus主要解决:

  1.  集群切换的强一致性(从上面架构看,更多的依赖于MySQL增强半同步,MySQL Plus在控制切换时,会做复制完成校验,从而且保证数据一致)
  2. 主从秒级别切换
  3. 无中心化自动选主

MySQL Plus看他们如何搞定金融环境

MySQL Plus 可以简单的理解是一个MySQL 5.7 GTID增强半同步复制的高可用管理组件。 在MySQL半同步配置方面,为了支持金融业务,青云给的配置如下:

  • rpl_semi_sync_master_wait_no_slave=ON
  • rpl_semi_sync_master_timeout=1000000000000000000
  • rpl_semi_sync_master_wait_point=AFTER_SYNC

看到这个配置我才想明白为什么他们建议是三个节点,在rpl_semi_sync_master_timeout配置上可以说不允许退化到异步复制, 另外RadonDB负责人交流,在MySQL Plus架构中主节点上至少要求一个Slave给半同步应答。 所以2个节点对架构的稳定性也是一个保证。 另外在金融环境中,作者推荐所有请求都在主库上完成, 免的存在复制延迟造成交易数据异常。

在金融架构中,青云也提供一套基于MySQL Plus之上构建建的分库分表机制, 基于MySQL的事务强一致性约,在该平台支持OLTP和OLAP更感觉有点NewSQL的感觉。

下面是官方给的一个总结:

重大消息

如果想了解更多3306π是青云MySQL Plus PPT信息可以关注 3306pai公众号,回复“bj”获取 3306π北京的PPT打包下载。

MySQL Plus 官方要开源了,希望通过MySQL Plus给MySQL 5.7 GTID复制提供一个新的高可用方案。

更重大消息: QingCloud RDS : RadonDB也要开源了,大家期待一下吧。 如果感兴趣提前体验或是更多的关注 RadonDB发展,也可以加到QQ群:748415432  和群主及 RadonDB负责人直接对喊话。   技术在于相互沟通,你的建议也需是将来一个非常不错的功能。

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

招商银行为什么使用MySQL

      对于金融行业使用MySQL可以说也比较早,例如腾讯的财富通从开始到现都是基于MySQL构建,但对于传统银行企业使用MySQL我也是一直存在好奇的想法。 这次在3306π北京站有幸听了招商银行王龙的分享也解决了我几个疑问,特Mark一下。

  1. 招商银行在走向开源的道路为什么选择了MySQL,而不是其它数据库?
  2. 招商银行在使用MySQL大概的规模及情况是什么?
  3. 招商银行是如何管理他们的MySQL?
  4. 他们成功的心得是什么?

招商银行为什么选择了MySQL?

在这一点上,听作者讲他们内部也做了大量的调研,例如PostgreSQL,TiDB,MySQL等。 最终选择了MySQL,不是说MySQL最优秀,也不是其它DB不优秀, 更重要的MySQL可以对他们的业务模型的支撑上更方便一点,同时团队的更加容易上手。具体的原因如下:
  1. 明确业务模型,不为可能需要的功能买单. MySQL足以支持现有的业务, 而且基准测试性能不弱。
  2. 本着简单的原则,不选复杂。 更多的人熟悉,更利于团队开发。
  3. 组建分布式DB,更方便快速扩容。
  4. 通过主从复制,读写分离等技术,更方便的实现多地多活技术。
  5. 选择MySQL更利用云服务化和DevOPS开发。

招商银行在MySQL使用上大概的规模

目前招商银行在使用MySQL将近两年, 目前作者讲有单业务集群分片在上百规模。 按这个分片来推算可以说是我听过最大的MySQL分布式系统。 该集群主要用于银行帐单查询相关业务。

招商银行如何管理他们的MySQL

这个直接引入原文中的PPT吧。 真的不能小看招商银行两年时间在MySQL云化平台做的相当出色。
上面可以看出来他们在资源申请上分三个类型,对于资源对齐方面确实做的不错。 想做MySQL平台的同学,仔细看看上面的两个图片。

招商银行在MySQL大规模使用上成功的心得

在这点招商银行总结金融架构13条(请阅读PPT),也很赞。 这里限于篇幅不在逻列。 我更多的关注对方在MySQL上的使用,这里看一个他们的分库分表决策: 分库常见几个基本问题: 在分库分表中作者见解也比较独到。也可以说是经过实际项目磨练出来的经验。 PPT已经发布在3306π的公众号上,关注3306pai公众号,回复“bj” 获取全部PPT。 作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

MGR监控及优化点

mysql group replication官方在监控及优化方面文档较少,为了在教学中方便使用,总结如下:

监控点

可用性监控

本节点是不是online:
select member_state from replication_group_members where member_id=@@server_uuid;

当前节点是不是可以写:
select * from performance_schema.global_variables where variable_name in ('read_only', 'super_read_only');

节点是Online表示属于集群中,正常工作。 节点不可写,表示是Single-master中的非Master节点。

性能监控

复制是不是存在延迟:
对比获得到的GTID和本节点执行的GTID是不是一致:
获取的GTID:
SELECT Received_transaction_set FROM performance_schema.replication_connection_status WHERE Channel_name = 'group_replication_applier';

本节点执行的GTID:
select @@gtid_executed;

远程获取的GTID - 本节点执行的GTID = 延迟的GTID数

本节点执行队列是不是有堆积(大于0表示有延迟):
select count_transactions_in_queue from replication_group_member_stats where member_id=@@server_uuid;

流控(flow control)

在MGR中如果节点落后集群中其它成员太多,就会发起让其它节点等他完成在做的控制,这个叫流控。
当启用: group_replication_flow_control_mode=QUOTA 是表示启用流控。 流控默认通过两个参数控制:
group_replication_flow_control_applier_threshold (默认: 25000)
group_replication_flow_control_certifier_threshold (默认: 25000)

也就说默认延迟在25000个GTID时,会对整个集群Block住写操作。
当然,也可以允许,节点延迟,就如同我们主从结构,从节点延迟,不往上面发请求就可以。
关闭Flow control:
set global group_replication_flow_control_mode='DISABLED';

提示: 关闭流控制,注意查看是不是存在延迟,如果延迟,自已控制阀值不向上面发请求即可。 多IDC结构的MGR,建议关闭流控。

MGR调优参数

因为基本复制结构,所有的数据复制,还是逻辑的重放,所以优化也是复制优化点。
更改:
slave_parallel_type -> LOGICAL_CLOCK

增强sql_thread个数:
slave_parallel_workers -> 2-8

如果CPU瓶颈,网络没问题,减少CPU压缩:
group_replication_compression_threshold = 1000000 -> 2000000
由原来的1M变成2M,再进行压缩(主要针对大事务传述优化)

备注: 需要MGR安装文档及更多交流 入QQ群: 579036588 联系群主。

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

XeLabs TokuDB 5.7.20 Release

恭喜XeLabs TokuDB 5.7.20发布,该版本基本地Percona版本TokuDB进行优化。基于Percona 5.7.20发版。

对TokuDB提升如下

  • Percona Server has implemented TokuDB integration with PERFORMANCE_SCHEMA.
  • 关于添加有默认值的日期类型字段,主从同步的问题(主:InnoDB,从:TokuDB) http://q.fireflyclub.org/?/question/47
  • 加入show engine中XeLabs TokuDB 标识
  • mysql –version 加入XeLabs 标识(本次只在CentOS7的版本标识)

二进制下址地址: https://pan.baidu.com/s/1qYRyH3I

20171219 补:

提供于基于xtrabackup 2.4.9版本的支持在线热备XeLabs TokuDB, AiSQL TokuDB (不支持Percona TokuDB)工具。 下载地址,目前也用百度云盘共享。

二进制下址地址: https://pan.baidu.com/s/1qYRyH3I

更多问题加入QQ群:579036588 联系群主。

CentOS下编译XeLabs TokuDB

1. 介绍

XeLabs TokuDB 官方源码: https://github.com/XeLabs/tokudb
支持: CentOS, Ubuntu
编辑环境要求: gcc > 4.8 cmake > 3.5

2. CentOS 6下编译举例

2.1 基本准备

yum install centos-release-scl

yum install cmake3
yum install devtoolset-3-gcc-c++.x86_64
yum install devtoolset-3-gcc.x86_64
如果是CentOS7就不需要安装devtoolset这个包,系统自带的gcc版本就可以。

启动新版本gcc
source /opt/rh/devtoolset-3/enable

安装cmake3
yum install cmake3
(如果找不到cmake3 请安装epel源)

yum install zlib-devel.x86_64
yum install libaio-devel
yum install ncurses-devel
yum install readline.x86_64 readline-devel.x86_64

2.2 下载tokudb代码

git clone https://github.com/XeLabs/tokudb.git
cd tokudb
git submodule init
git submodule update

编译参考:

vim cc.sh

cmake3 .\
  -DCMAKE_BUILD_TYPE=RelWithDebInfo\
  -DBUILD_CONFIG=mysql_release\
  -DFEATURE_SET=community\
  -DWITH_EMBEDDED_SERVER=OFF\
  -DTOKUDB_VERSION=7.5.6\
  -DBUILD_TESTING=OFF\
  -DWITHOUT_ROCKSDB_STORAGE_ENGINE=1 \
  -DWITH_BOOST=extra/boost/boost_1_59_0.tar.gz\
  -DCMAKE_INSTALL_PREFIX=/usr/local/tokudb 
  • 执行参数配置初始化 sh cc.sh
  • 待执行成功后,提示Configure done
    make
    make install对于CentOS6,CentOS7的同学,如果就是想偿个鲜不想编译的话可以在下面地址下载:
    https://pan.baidu.com/s/1qYRyH3I
  • 因为TokuDB禁用hugepage:
    echo never > /sys/kernel/mm/transparent_hugepage/enabled

后面和正常基于二进制安装MySQL一样。

3. Tips

在sh cc.sh 中出错,需要删除:CMakeCache.txt
rm -rf CMakeCache.txt
有时还需要删除:
rm -rf CMakeFiles/*

如果因为出错提示缺了某个包,安装上去后,再继续。

4. 备注

devtoolset-2 目前已经有gcc的参数不支持,编译通不过(2017/12/08)
devtoolset-3 在CentOS 6上遇到gcc的段错误,如果没有段错误,devtoolset-3是可以用的。(2017/12/08)
devtoolset-4 目前在CentOS 6上测试通过(2017/12/08)
CentOS7 自带gcc可以编译通过(2017/12/08)

编译中如果遇到其它诡异问题,可以加入QQ群:579036588 联系群主获取支持。如果你做了其它版本的发行包,也可以联系群主,一块提供一些发行包。

案例推荐

TokuDB在生产环境的应用场景(zabbix也可以) http://blog.51cto.com/412166174/2050739

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

MySQL每秒57万的写入,带你飞

一、需求

一个朋友接到一个需求,从大数据平台收到一个数据写入在20亿+,需要快速地加载到MySQL中,供第二天业务展示使用。

二、实现再分析

对于单表20亿, 在MySQL运维,说真的这块目前涉及得比较少,也基本没什么经验,但对于InnoDB单表Insert 如果内存大于数据情况下,可以维持在10万-15万行写入。 但很多时间我们接受的项目还是数据超过内存的。 这里使用XeLabs TokuDB做一个测试。

三、XeLabs TokuDB介绍

项目地址: https://github.com/XeLabs/tokudb

相对官方TokuDB的优化:

  • 内置了jemalloc 内存分配
  • 引入更多的内置的TokuDB性能指标
  • 支持Xtrabackup备份
  • 引入ZSTD压缩算法
  • 支持TokuDB的binlog_group_commit特性

四、测试表

TokuDB核心配置:

loose_tokudb_cache_size=4G
loose_tokudb_directio=ON
loose_tokudb_fsync_log_period=1000
tokudb_commit_sync=0

表结构

CREATE TABLE `user_summary` (
  `user_id` bigint(20) unsigned NOT NULL COMMENT '用户id/手机号',
  `weight` varchar(5) DEFAULT NULL COMMENT '和码体重(KG)',
  `level` varchar(20) DEFAULT NULL COMMENT '重量级',
  `beat_rate` varchar(12) DEFAULT NULL COMMENT '击败率',
  `level_num` int(10) DEFAULT NULL COMMENT '同吨位人数',
  UNIQUE KEY `u_user_id` (`user_id`)
) ENGINE=TokuDB DEFAULT CHARSET=utf8

利用load data写入数据

root@localhost [zst]>LOAD DATA INFILE '/u01/work/134-136.txt' \
INTO TABLE user_summary(user_id, weight, level, beat_rate,level_num);
Query OK, 200000000 rows affected (5 min 48.30 sec)
Records: 200000000  Deleted: 0  Skipped: 0  Warnings: 0

计算一下每秒写入速度:

root@localhost [zst]>select 200000000/(5*60+48.30);
+------------------------+
| 200000000/(5*60+48.30) |
+------------------------+
|            574217.6285 |
+------------------------+
1 row in set (0.00 sec)

文件大小:

-rw-r--r-- 1 root  root  8.5G 11月 25 20:05 134-136.txt
-rw-r----- 1 mysql mysql 8.6K 11月 25 20:44 user_summary.frm
-rw-r----- 1 mysql mysql 3.5G 11月 25 20:51 user_summary_main_229_1_1d_B_0.tokudb

实际文件8.5G,写入TokuDB大小3.5G,只是接近于一半多点的压缩量。 对于20亿数据写入,实际测试在58分钟多点就可以完成。可以满足实际需求,另外对于磁盘IO比较好的机器(SSD类盘,云上的云盘),如果内存和数据差不多情况,这量级数据量测试在Innodb里需要添加自增列,可以在3个小多一点完成。 从最佳实战上来看,Innodb和TokuDB都写入同样的数据,InnoDB需要花大概是TokuDB3-4倍时间。文件大小区别,同样20亿数据:

-rw-r----- 1 mysql mysql  35G 11月 25 23:29 user2_main_26a_1_1d_B_0.tokudb
-rw-r----- 1 mysql mysql 176G 11月 26 03:32 user5.ibd

文件大小在5倍大小的区别。

测试结论:

利用TokuDB在某云环境中8核8G内存,500G高速云盘环境,多次测试可以轻松实现57万每秒的写入量。

另外测试几种场景也供大家参考: 如果在TokuDB中使用带自增的主键,主键无值让MySQL内部产生写入速度,下降比较明显,同样写入2亿数据,带有自建主键:

root@localhost [zst]>CREATE TABLE `user3` (
    ->    `user_id` bigint(20) unsigned NOT NULL COMMENT '用户id/手机号',
    ->    `weight` varchar(5) DEFAULT NULL COMMENT '和码体重(KG)',
    ->    `level` varchar(20) DEFAULT NULL COMMENT '重量级',
    ->    `beat_rate` varchar(12) DEFAULT NULL COMMENT '击败率',
    ->    `level_num` int(10) DEFAULT NULL COMMENT '同吨位人数',
    ->    `id` bigint(20) NOT NULL AUTO_INCREMENT,
    ->    PRIMARY KEY (`id`),
    ->    UNIQUE KEY `u_user_id` (`user_id`)
    ->  ) ENGINE=TokuDB;
Query OK, 0 rows affected (0.03 sec)

root@localhost [zst]>LOAD DATA INFILE '/u01/work/134-136.txt' INTO TABLE user3(user_id, weight, level, beat_rate,level_num);
Query OK, 200000000 rows affected (22 min 43.62 sec)
Records: 200000000  Deleted: 0  Skipped: 0  Warnings: 0

同样的数据写入在主键自增无值产生时,不能使用TokuDB的 Bulk loader data特性,相当于转换为了单条的Insert实现,所以效果上慢太多。

关于TokuDB Bulk Loader前提要求,这个表是空表,对于自增列,如自增列有值的情况下,也可以使用。 建议实际使用中,如果自增列有值的情况下,可以考虑去除自增属性,改成唯一索引,这样减少自增的一些处理逻辑,让TokuDB能跑地更快一点。  另外在Bulk Loader处理中为了追求更快速的写入,压缩方面并不是很好。

关于TokuDB Bulk Loader :https://github.com/percona/PerconaFT/wiki/TokuFT-Bulk-Loader

五、测试环境说明

测试使用CentOS7环境,编译的XeLabs TokuDB版本百度云地址:https://pan.baidu.com/s/1qYRyH3I 。

如果这个地址失效,可以加入QQ群:579036588 联系群主获取。

也可以参考 https://github.com/XeLabs/tokudb/wiki/How-to-build  自行编译。

祝各位玩的开心。

 

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.