Tidb

2021 年的TiDB Hackathon在狂欢中完结了，然而其余味却是久久难以消散。作为 TiDB十年老粉的选手，真的是非常有幸可能加入如此优良的流动，但遗憾的是咱们的TiCheck并没有取得一个很好的问题，当青姐发表20强的时候，我看看整整三遍名单，考虑了很久，果然还是咱们太弱了嘛。 第一天看完大家预选赛的问难，虽说是能感触到在座各位大佬的弱小，然而仍旧抱有一丝丝的空想本人的我的项目可能怀才不遇，直到最初后果进去的时候，咱们也是继承某些低劣的传统，各种找借口来刺激本人，比方，评委们都是一群干开发和大老板们，他们能懂个锤子的数据库运维，他们懂咱们做运维的苦楚嘛？ 好了，回来谈一谈咱们这个项- Automated checklist, 又叫TiCheck, 最早这个我的项目源自咱们一个实在场景下的运维生存，大家都晓得，数据库是一个十分重要的零碎，尤其在一些非常重视平安和稳固的情景中，比方金融银行这些，那么数据库的治理和运维就非常的简单和好受，举几个列子： 大量的日常操作必须都进行脚本化，一套数据库得整一两百个脚本，还得现写现审核，每当上头有个新的操作需要，你就得写一个脚本，最次要的是数据库脚本这个货色，很难去找到现有的间接用，每个DBA都有本人的小私库。 TiDB 有Grafana, Dashboard而后加上数据库SQL查问，共有三种办法获取数据库的不同信息，然而，当你的网络和权限受限的时候，你很难说去三个中央来查看数据库是否失常，同时每次查看集群信息，得从三个中央跳来跳去的，如果能有个对立的中央来查看这些，会不会十分难受？ 日常巡检，就是每天下来查看数据库是否失常，有无异样和隐患，TiDB有多稳，不须要多说了吧，再加上一堆监控和告警，能出什么问题呢？然而为了数据安全，你就必须每天下来巡逻一边，把所有巡检指标过一遍，并且进行巡检记录，这个少则十几分钟，多则几小时的操作，在安稳运行的每一天都是折磨，你巴不得明天某个指标来点小问题，让本人显得有一丝价值。 历史记录的问题，数据库日常巡检之后，这些记录保留与否，如何保留，多久清理一次等等问题，同时如果想要查看历史巡检的状况，只能一份一份的看，如果想要看一段时间巡检的统计和剖析，还得手动操作一波，而这个又是领导们经常想要的。 说到领导，领导常常会关怀数据库状态是否失常，用的怎么样，这个时候，你得写一份领导看的懂的报告，加一些易懂的图图表表，如果你把那些Grafana和SQL查问后果拿过来，我只能说很难。最重要的是，当领导要看的时候，你得在最短的工夫内拿出报告，不然有得好果子吃。 在这个我的项目中干了许久之后，咱们慢慢发现，咱们成为了一个又一个的操作机器，日复一日的脚本生成，日常巡检（点点点），文档生成。没多少技术含量不说，每天还显得异样繁忙，到底在繁忙些什么呢？ 在写了无数个脚本之后，我的某个共事率先发难了，咱们当初讲的是一个什么？开源！共享！为什么就是没有人共享一下数据库脚本，做一个脚本仓库，大家把本人的脚本上传上去，也能够从下面下载各种各样的脚本，这难道不难受？ 的确，但第二个共事感觉，不如做一个巡检平台，最好一键巡检完，生成报告，省得每天花一堆工夫做巡检写报告，跟个机器人似的，最好是那有那种可视化的展现模式，这样不便看，也不便应酬老板们。 所以，为什么不两个合在一起呢？刚好就这次Hackathon，咱们能够开发一个日常巡检平台，欸~，就是冲，说不定还能白嫖十万块钱。 这个平台能够干什么呢？ 首先，它必定能够一键跑一次日常巡检，对于巡检指标，能够本人增加不同的脚本和阈值来设定，进行自定义设置。并且你能够设置一个周期工作，比如说每天6点跑一次指定巡检。 而后有可视化平台，不便运维人员执行巡检工作，查看巡检指标状态，包含历史巡检记录和巡检剖析，最近一周，一个月，一年呈现较多的异样指标等 能够随便导出历史巡检记录，老板来了齐全不慌，当然，你也能够通过这个平台来治理你的巡检历史文件，导出，批改和清理等。 最重要的来了，巡检的每个指标都是一个脚本，通过脚本，你能够将Dashboard, Prometheus 和 SQL 语句的后果对立输入到巡检指标中，再也不必开多个平台去查看集群状态。而且咱们建设了近程脚本仓库，下面有大量现成的脚本共用户下载应用，你也能够书写本人的脚本奉献下来！ 当然这个平台还能够集成很多其余的性能，这些性能也是咱们将来布局的，但因为Hackathon工夫无限没有实现的： 每日定时主动巡检实现后，能够对接用户的告警零碎，对相应异样指标输入到告警零碎之中，或者将报告通过短信的形式发送到相干运维人员，防止人员须要每天到机房查看。 通过历史巡检数据能够对集群状态进行深度剖析，提前挖掘集群可能存在问题，例如每日巡检到存储空间增长状况，来预测将来多少天会呈现存储空间有余的状况。 退出根因剖析性能（这个其实是我原本和另一个搭档报名Hackathon较量加入的我的项目，但因为他太忙了，就弃赛了），当发现巡检指标异样的时候，可能疾速定位到集群问题的根本原因，不便运维人员的保护，防止长时间的集群排查。 Hackathon 只是一个开始，各种各样的花式idea在其中涌出，关上一扇扇新的大门，巡检平台这个我的项目，尽管没有获得较好的问题，然而咱们不心愿巡检平台刚刚开始就完结了，因为咱们置信，会有许多人 遇到咱们这相似的运维问题，那么主动巡检平台就会有他存在的价值。 所以大家如果对于巡检平台有什么更好的想法，能够分割咱们，对其进行优化，或是集成到其余平台一起应用。 Github: DigitalChinaOpenSource/TiCheck: TiDB automated checklist for hackathon 2021. (github.com)

背景上一篇《记一次简略的Oracle离线数据迁徙至TiDB过程》说到在应用Lightning导入csv文件到TiDB的时候发现了一个bug，是这样一个过程。 Oracle源库中表名都是大写，通过前文所述的办法导入到TiDB后表名也是放弃全大写，数据同步过程十分顺利。第二天我把整套操作流程教给一位老手敌人，他就挑了一张表用来做试验，后果死活都不行。各种剖析和重试都没有成果，就在快要懵逼的时候想到了这个大小写问题，把csv拉进去一看是个全小写的文件名，我尝试着把表名改成大写再导入一次，这次终于胜利了。原来，是这位小伙子用sqluldr2导出表数据的时候把文件名写死了，而且是个小写。。。 这里提一下TiDB表名大小写敏感相干的参数lower-case-table-names，这个参数只能被设置成2，也就是存储表名的时候辨别大小写，比照的时候对立转为小写。因而，TiDB中的表名倡议应用全小写来命名。 这个个性根本和MySQL是统一的，只是MySQL反对更多的场景，具体能够参考https://dev.mysql.com/doc/ref... 那么，说好的TiDB表名不辨别大小写呢，怎么用了Lightning就生效了？ Bug重现下面说的还是有点形象，咱们通过如下的步骤重现一下。 这里我筹备的TiDB测试版本是v5.2.2，和后面发现bug的版本统一，Lightning也应用配套的版本。我拿最新的master分支也能复现这个问题。 先创立一张测试表，表名全副用大写： use test;create table LIGHTNING_BUG (f1 varchar(50),f2 varchar(50),f3 varchar(50));再筹备一个待导入的csv文件，文件名是test.lightning_bug.csv： 111|aaa|%%%222|bbb|###Lightning的残缺配置文件： [lightning]level = "info"file = "tidb-lightning.log"index-concurrency = 2table-concurrency = 5io-concurrency = 5[tikv-importer]backend = "local"sorted-kv-dir = "/tmp/tidb/lightning_dir"[mydumper]data-source-dir = "/tmp/tidb/data"no-schema = truefilter = ['*.*'][mydumper.csv]# 字段分隔符，反对一个或多个字符，默认值为 ','。separator = '|'# 援用定界符，设置为空示意字符串未加引号。delimiter = ''# 行尾定界字符，反对一个或多个字符。设置为空（默认值）示意 "\n"（换行）和 "\r\n" （回车+换行），均示意行尾。terminator = ""# CSV 文件是否蕴含表头。# 如果 header = true，将跳过首行。header = false# CSV 文件是否蕴含 NULL。# 如果 not-null = true，CSV 所有列都不能解析为 NULL。not-null = false# 如果 not-null = false（即 CSV 能够蕴含 NULL），# 为以下值的字段将会被解析为 NULL。null = '\N'# 是否对字段内“\“进行本义backslash-escape = true# 如果有行以分隔符结尾，删除尾部分隔符。trim-last-separator = false[tidb]host = "x.x.x.x"port = 4000user = "root"password = ""status-port = 10080pd-addr = "x.x.x.x:2379"[checkpoint]enable = false[post-restore]checksum = falseanalyze = false运行如下命令开始执行导入工作： ...

背景最近在反对一个从Oracle转TiDB的我的项目，为不便利用端兼容性测试须要把Oracle测试环境的库表构造和数据同步到TiDB中，因为数据量并不大，所以怎么不便怎么来，这里应用CSV导出导入的形式来实现。 整个过程能够分为三个步骤： 库表构造转换源数据导出导入指标库库表构造转换家喻户晓TiDB是兼容MySQL协定的，所以Oracle的表构造定义在TIDB不肯定能齐全应用，这时候就须要做一些转换，比方字段类型、关键字、零碎函数等等。如果表比拟少的话，手动转一下也不是不行，但本次测试的Oracle其中一个用户下就有将近900张表，手动去转换显然不可能。 这里我应用的工具是TransferDB，它能够反对异构数据Oracle到MySQL/TiDB的构造转换，我的项目主页https://github.com/wentaojin/...。 这个工具由PingCAP某位大佬开发，尽管没有正式对外公布，但的确挺好用的。TransferDB是TiDB运维常用工具集（TiDBA）中的一部分，其余的还蕴含收集统计信息、Mok 解析 key、基于 region key、数据 range、数据估算生成打散语句、查看表数据以及索引 region leader 散布、版本升级，比对 3.0 以及 4.0 配置文件以及 tidb 零碎变量等，能够说是十分实用了，它的我的项目主页是https://github.com/wentaojin/...应用过Lightning的敌人对这个工具的应用肯定不会生疏，从配置文件到运行程序简直能够说是一模一样，我的项目自带的操作手册也写的十分具体。 它蕴含以下几点外围性能：schema转换、表构造查看、迁徙老本评估、数据迁徙（全量或增量）、CSV导出等，其中有些性能目前还是试验个性，我这里只用到了它的外围个性schema转换。 它的配置文件参数十分丰盛，正文很清晰应用起来非常简单，对于schema转换场景来说，只须要批改[source]和[target]局部的连贯信息就行，具体的配置清单能够看这里：https://github.com/wentaojin/transferdb/blob/main/conf/config.toml 配置文件批改好当前，执行上面两条命令就能够实现转换： # 这个过程是在指标库中生成一个迁徙元信息库，用来存储转换规则、断点信息等等，相似于DM中的dm_meta库./transferdb --config config.toml --mode prepare # 这个过程是实现schema转换，输入sql文件./transferdb --config config.toml --mode reverse执行成当前会生成2个SQL文件，一个叫 reverse_${sourcedb}.sql，它是在TiDB中能够执行的sql，另一个是 compatibility_${sourcedb}.sql，它是TiDB不兼容的sql，比方Foreign Key、Constraint等等，这部分SQL须要人工去评估下应用别的计划来实现。 接着，把reverse_${sourcedb}.sql导入到TiDB即可，罕用的两种形式： mysql -h -u -P < reverse.sqlsource reverse.sql源数据导出Oracle数据导出到CSV文件我应用sqluldr2来实现，这是一款在Oracle应用十分宽泛的数据导出工具，它的特点就是玲珑、轻便、速度快、跨平台、反对自定义SQL。 网上的材料比拟多，这里就不具体介绍怎么去应用了，作者（前阿里数据库大佬）也写了一份超级具体的文档，大家搜寻sqluldr2超具体应用教程-loracle数据导出工具及办法即可。 sqluldr2尽管很弱小，但它却不反对批量导出这点很让人蛊惑，没方法只能另辟蹊径来实现了。 我先把须要导出的表清单放到一个txt文件中： ./sqluldr2linux64.bin user=user/pwd@192.168.1.1:1521/orcl query='select table_name from all_tables where owner='test';' file=/tmp/tidb/sqluldr_tables.sql再写一个批处理脚本把所有表进行导出： #!/bin/bashcat /tmp/tidb/sqluldr_tables.sql | while read linedo echo $line /tmp/tidb/sqluldr2linux64.bin user=user/pwd@192.168.1.1:1521/orcl query={$line} charset=UTF8 field=0x7c0x260x7c record=0x3d0x37 null=null file=/tmp/tidb/data/orcltest.{$line}.csvdone这里有几点须要留神： ...

前言其实，咱们始终都很想，基于TiDB做一些很cool，很hacker的事件。比方咱们团队小伙伴发了一篇对于TiDB for Pg兼容Gitlab的一篇文章，具体文章能够参考链接： TiDB4PG之兼容Gitlab - 知乎 (zhihu.com) 这篇文章我就来简略聊聊实现兼容到Gitlab的艰辛过程。 咱们采纳了一个绝对较笨的形式，将Gitlab的源码通过编译启动的形式，连贯到最开始的TiDB for PG，这样必定是报错，不行的，毕竟很多货色没有兼容。为了能疾速实现兼容，咱们决定采取抓包的形式，将Gitlab连贯到TiDB For Pg的所执行的SQL语句找进去，进行粗略的分类整理，去看看有哪些SQL语句，去定制化的兼容开发。在兼容实现这些SQL语句时，难点之一，就有DML语句中的Returning关键字。 原理在TiDB-Server外面，执行一个SQL语句的流程，大抵能够分为解析、编译、优化、执行、返回后果这几个阶段。而实现一个关键字，同样的须要在这几个阶段做一些文章。而对于Returning关键字而言，咱们能够从DML语句中绝对简略的DELETE语句动手，所以接下来的革新过程，最终后果就是实现了DELETE RETURNING 句式。 革新实现过程Parser从SQL在TiDB中的流转过程，迈入后续代码的第一步，就是将客户端传来的SQL语句解析为一个可能被后续代码意识的构造，也就是AST树。而这一过程，次要就是在Parser这个模块儿中实现。 在TiDB v5.0以前，Parser这个包是有一个专门的代码仓库的，通过go mod的形式导入到TiDB，而在5.0之后，TiDB将Parser包挪到TiDB源码当中。TiDB for PG 的源码也是基于TiDB v4.0.14革新的，这次我想尝试一下，在TiDB 最新的源码中实现RETURNING关键字，一个是为了hackathon的较量作筹备，另一个也是为了之后TiDB for PG向着TiDB新版本聚拢试试水。 Paser模块次要靠Lexer & Yacc这两个模块独特形成。在解析的过程中，Lexer组件会将SQL文本转换为一个又一个token传给parser，而parser中最为重要的parser.go文件，则是goyacc工具依据parser.y文件生成的，依据文件中语法的定义，来决定lexer中传过来的token可能与什么语法规定进行匹配，最终输入AST构造树，也就是parser/ast 中定义的各类stmt，而咱们要实现的就是dml.go中的DeleteStmt。 // DeleteStmt is a statement to delete rows from table.// See https://dev.mysql.com/doc/refman/5.7/en/delete.htmltype DeleteStmt struct { dmlNode // TableRefs is used in both single table and multiple table delete statement. TableRefs *TableRefsClause // Tables is only used in multiple table delete statement. Tables *DeleteTableList Where ExprNode Order *OrderByClause Limit *Limit Priority mysql.PriorityEnum IgnoreErr bool Quick bool IsMultiTable bool BeforeFrom bool // TableHints represents the table level Optimizer Hint for join type. TableHints []*TableOptimizerHint With *WithClause // 咱们明天的主题，Returning 关键字 Returning *ReturningClause}type ReturningClause struct { node Fields *FieldList}func (n *ReturningClause) Restore(ctx *format.RestoreCtx) error { ctx.WriteKeyWord("Returning ") for i, item := range n.Fields.Fields { if i != 0 { ctx.WritePlain(",") } if err := item.Restore(ctx); err != nil { return errors.Annotatef(err, "An error occurred while restore ReturningClause.Fields[%d]", i) } } return nil}func (n *ReturningClause) Accept(v Visitor) (Node, bool) { newNode, skipChildren := v.Enter(n) if skipChildren { return v.Leave(newNode) } n = newNode.(*ReturningClause) if n.Fields != nil { node, ok := n.Fields.Accept(v) if !ok { return n, false } n.Fields = node.(*FieldList) } return v.Leave(n)}原谅篇幅无限，不能把所有代码贴出来。这里值得提一嘴的就是Accept()办法。在ast包中，简直所有的stmt构造都实现了ast.Node接口，这个接口中的Accept()办法，次要作用就是解决AST，通过Visitor模式遍历所有的节点，并且对AST构造做一个转换。而为了能失常将RETURNING关键字转换成DeleteStmt，咱们还须要在parser中去将RETURNING 关键字注册为token。 ...

对于TiDB数据脱敏数据库安全始终都是用户非常关注的点，尤其在一些外围零碎与非凡畛域之中，当把握了肯定规模的敏感数据后，就须要时刻防止数据的泄露和失落，所以对于数据库的治理和应用都有着杂繁琐的流程和简单的权限，这其中就有一个重要的平安技术 — 数据脱敏。 数据脱敏数据脱敏是指对于数据库中存储的一些敏感信息进行规定的革新，爱护敏感数据不会被随便的读取和泄露。像身份证，手机号，银行卡号等敏感信息，都会进行数据脱敏，所以咱们比拟常见的就是数据掩码，用*字符号来代替两头的数据。比方电话号码 123456789 通过脱敏变为 1236789. 在现在，咱们常常都能看到各种数据泄露，用户数据被卖等相干新闻，数据安全和网络安全也是咱们越来越器重的一面。国家当初也是一直的出台各种政策，要求相干企业做好数据的爱护与脱敏，尤其是一些海内企业，对于数据的治理会更加严格。 而作为一名数据库工程师，靠着数据库近的人，更是须要去理解和器重数据脱敏这项技术。 脱敏形式对于数据脱敏的形式大略有两种，动态脱敏和动静脱敏。 动态脱敏对于动态脱敏其实十分好了解，就是在已知数据的构造和须要脱敏的内容后，通过一些脱敏算法对于这些数据进行肯定的解决，转换成其余的数据模式。 动态脱敏往往须要将数据先从数据库中提取进去，而后放到曾经实现脱敏算法的工具中进行批量的转换，最初将脱敏后的数据放到其余须要的中央。那么这种形式不须要与利用或者是数据库建设间接的分割，单纯的数据处理。 动静脱敏动静脱敏则是实时的剖析查问的数据是否存在须要脱敏的内容，如果存在则将数据通过不同的脱敏算法进行脱敏后返回到利用端。 所以当初动静脱敏的实现往往都是建设一个代理层，放在利用和数据库之间，拦挡查问的SQL或者是返回的数据后果集，进行检索和判断，是否存在敏感信息，敏感信息的类型如何，如果存在，就应用相应的脱敏算法对于SQL进行革新，或者间接将后果集进行革新后返回。两种办法都存在。 数据脱敏平台当初世面上的数据脱敏平台还是挺多的，其实咱们也有一款本人的数据动静脱敏平台产品 - TDMP，最近也是用 TiDB 集群进行了功能测试，平台反对的性能在 TiDB 上都能失常应用。 当然这也是在咱们的预料之中，不得不说因为 TiDB 对于 MySQL 的齐全兼容，让很多对接 MySQL 的工具都能在 TiDB 下来间接应用。 技术实现TDMP 脱敏的整体实现思路简略介绍： TDMP-DM应用作为反向代理技术，部署在运维工具、利用及数据库之间。当用户执行的查问语句进来时，会通过执行的用户权限和执行语句进行查看，是否存在敏感信息的查问，执行用户是否有权查看敏感信息。如果触发的脱敏条件，则会从两种形式中抉择一种进行脱敏，一是间接改写SQL语句，二是将查问的后果集进行批改。具体抉择那种形式和那种脱敏算法，则要通过用户的配置，查问后果的大小，性能的评估等来决定。最初将脱敏后的数据返回给用户或者利用端。咋的一看，整个实现思路还挺简略，然而理论去实现 SQL 的测验，脱敏算法和抉择优化时，整个实现难度还是比拟高的，尤其是在 SQL 检测这一边，干多了运维的都懂，大千世界，什么样的 SQL 都有，想要去写一个通用的检测算法，比拟麻烦点。 在脱敏外围这块的实现其实有点相似与数据库 SQL 解析层的解决，也就是 TiDB Server 的模式： 对于用户查问的 SQL 进行 Parse 解析，解析成一个咱们自定义的树结构体，和形象语法树十分的像。基于规定的审核，判断一个查问是否要进行脱敏，或者须要进行那些脱敏操作，咱们会建设一个规定列表（包含用户权限，用户配置的规定和自带的一系列检测），遍历这个规定列表，判断每一个是否须要在该次查问中应用到，如果能够用到则须要进行记录。基于物理的优化，其实做一个数据库中间件去进行数据脱敏，对于数据库的查问性能会有很大的影响，因为这一类的操作是要具体到数据中去批改的，所以在真正的去执行某一个脱敏的形式时，除开用户的配置，咱们也会进行肯定的优化，通过判断本次查问的数据大小和查问复杂程度等来优化。整个过程是不是十分的像 TiDB Server 对于SQL 的解决：SQL - > Parser -> RBO -> CBO -> Executor 对于TDMP这个平台的详细信息能够看下官网介绍 这里就不做过多的介绍了 对于TiDB的一些想法脱敏函数下面介绍过脱敏实现的简略思路，其实和 TiDB Server 中 SQL 的执行过程十分类似。所以当初有一个想法，就是间接在 TiDB Server 中增加一个简略的脱敏性能，能够是一个脱敏函数。 ...

作者：胡呈清 爱可生 DBA 团队成员，善于故障剖析、性能优化，集体博客：https://www.jianshu.com/u/a95...，欢送探讨。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 如果要应用 Zabbix 监控应用 TiDB，需应用 HTTP agent ，被动调用 TiDB 监控接口获取监控数据，而后配置数据预处理：抉择应用 Prometheus pattern 或者 Prometheus to JSON 办法，然而这两个性能是在 Zabbix4.2 中退出的，Zabbix4.0.x 没有这个性能（即便是最新的 zabbix4.0.35）： 所以在没法降级到 Zabbix5.4 时，咱们能够在大于 4.2 的版本上手工创立监控模板，以下演示环境为 Zabbix5.0.5。 TiDB 监控接口在开始前，须要先理解 TiDB 的监控接口：https://docs.pingcap.com/zh/t... 示例： curl http://127.0.0.1:10080/metrics > /tmp/tidb_metics 参考TiDB 官网上的告警规定（https://docs.pingcap.com/zh/t...）中的第一条告警规定： increase(tidb_session_schema_lease_error_total{type="outdated"}[15m]) > 0 这个是 prometheus 的语法，咱们只须要晓得 tidb_session_schema_lease_error_total 是 metrics name 就行，而后咱们去监控数据中找到这个 metric（TiDB的不同版本metric可能不一样，示例中的 metric 在4.0.10中就没有，在5.1中有）： [root@localhost tmp]# grep tidb_session_schema_lease_error_total /tmp/tidb_metics # HELP tidb_session_schema_lease_error_total Counter of schema lease error # TYPE tidb_session_schema_lease_error_total counter tidb_session_schema_lease_error_total{type="outdated"} 2其数据格式为： ...

TiDB数据库传统的单机数据库在挪动互联网、云计算、大数据和人工智能等场景下体现的力不从心，为了解决数据平台的扩展性的问题，TiDB 分布式数据库应运而生。TiDB 是当今开源 NewSQL 数据库畛域的代表产品之一。 TiDB采纳分布式数据库架构，因而服务器数量比拟多。在部署TiDB集群时，咱们应用TiUP工具来装置整个TiDB集群环境。 从 TiDB 4.0 版本开始，TiUP 作为新的工具，承当着包管理器的角色，治理着 TiDB 生态下泛滥的组件，如 TiDB、PD、TiKV 等。用户想要运行 TiDB 生态中任何组件时，只须要执行 TiUP 一行命令即可，相比以前，极大地升高了治理难度。 默认状况下TiUP工具会联网进行工具包的下载和装置，但生产环境往往都是内网环境，无奈连贯外网进行下载。这种状况下，咱们能够抉择离线的部署办法。本文以 TiDB 5.0 的版本为根底，具体介绍应用TiUP工具离线部署 TiDB 集群的过程。 第一步、联网下载TiUP包管理器应用能够联网的主机，下载并装置 TiUP 包管理器工具。命令如下： curl --proto ‘=https’ --tlsv1.2 -sSfhttps://tiup-mirrors.pingcap.... | sh 第二步、申明全局环境变量申明全局环境变量，命令如下： source /root/.bash_profile执行过程如下： 第三步、通过TiUP工具下载所有工具的离线安装包应用 tiup list tidb 命令能够看到所有tidb的版本，咱们能够在其中抉择须要下载的版本。命令如下： tiup list tidb而后通过tiup mirror clone tidb-community-server-${version}-linux-amd64 ${version} --os=linux --arch=amd64 命令进行装置。其中${version}须要替换成对应的TiDB版本，命令如下： tiup mirror clone tidb-community-server-v5.2.1-linux-amd64 v5.2.1–os=linux --arch=amd64咱们将前两个命令组合在一起，就失去了下载最新版本安装包的命令，命令如下： version=tiup list tidb|sort -r |head -n 2|tail -n 1|awk '{print $1};' && \援用tiup mirror clone tidb-community-server-${version}-linux-amd64${version} --os=linux --arch=amd64执行过程如下须要留神的是，在下载过程中，可能会因为网络问题导致某个工具包下载失败，此时TiUP工具会再次尝试下载，如果最终无奈下载实现，TiUP工具会完结并退出。咱们仍旧能够反复TiUP命令来重复尝试下载。开始下载过程时，会生成tidb-community-server-v5.2.1-linux-amd64的目录。 ...

TiUP工具简介从 TiDB 4.0 版本开始，TiUP 作为新的工具，承当着包管理器的角色，治理着 TiDB 生态下泛滥的组件，如 TiDB、PD、TiKV 等。用户想要运行 TiDB 生态中任何组件时，只须要执行 TiUP 一行命令即可，相比以前，极大地升高了治理难度。 应用TiUP工具能够很轻松的对TiDB集群进行日常运维工作，如果咱们想启停TiDB集群中的某一台服务器，能够应用文章中的操作流程。 进行TiDB集群节点首先应用 "tiup cluster display <clustername> "命令查看TiDB集群信息，ID列显示的 IP:PORT 能够作为节点名称应用，执行过程如下： 接下来，能够参考进行集群命令 "tiup cluster stop -h"的帮忙信息，来失去进行某一台服务器的命令语法，从帮忙中能够看到应用 -N 选项就是咱们须要的性能，执行过程如下： 理解了命令后，接下来进行"192.168.2.81:2379"这台PD节点服务器，命令为："tiup cluster stop sandata -N 192.168.2.81:2379"，执行过程如下：进行命令执行胜利后，再次应用 "tiup cluster display sandata" 查看集群的状态，能够看到 192.168.2.81:2379 节点曾经是 Down 的状态，执行过程如下： 下一步咱们应用同样命令"tiup cluster stop sandata -N 192.168.2.81:20160"，来进行 192.168.2.84:20160 这台 TiKV 节点服务器，执行过程如下：命令胜利后，192.168.2.84:20160 这台 TiKV 节点变为Disconnected状态，执行过程如下：期待一段时间后，TiKV 节点状态就会变成 Down 的状态，在这种状态不影响TiDB的失常应用，执行过程如下。 至此，咱们实现了进行TiDB集群节点服务器的工作。 启动TiDB集群节点下一步，咱们把停掉的节点，逐个复原启动状态。首先应用 "tiup cluster start sandata -N 192.168.2.84:20160" 命令来启动 TiKV 节点，执行过程如下：再应用"tiup cluster start sandata -N 192.168.2.84:2379" 命令来启动 PD 节点，执行过程如下：最初，应用 "tiup cluster display sandata" 命令查看TiDB集群状态，均为UP状态，执行过程如下： ...

下载安装包wget http://download.pingcap.org/tidb-latest-linux-amd64.tar.gz解压文件tar -zxvf tidb-latest-linux-amd64.tar.gz启动服务cd /opt/tidb-v5.0.1-linux-amd64/bin#启动PD./pd-server --data-dir=pd --log-file=pd.log &#启动tikv./tikv-server --pd="127.0.0.1:2379" --data-dir=tikv --log-file=tikv.log &#启动./tidb-server --store=tikv --path="127.0.0.1:2379" --log-file=tidb.log &登录 简略应用

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 长期以来，在 MySQL 的开发标准里个别都会这么写： 禁止大事务！话题转到 TiDB ，仍然应该是：禁止大事务！ TiDB 因为事务自身分布式个性，加之后盾 RAFT 复制导致的写放大，十分不举荐应用大事务。 TiDB 在4.0 之前的版本对事务要求有些过于粗疏，比方：单个事务蕴含的 SQL 语句不超过5000条单条 KV entry 不超过6MBKV entry 的总条数不超过30wKV entry 的总大小不超过100MB下面的几点限度会导致一些 DML 语句写入碰壁，比方上面这三类经典无过滤条件语句：insert ... select ... where 1update ... where 1delete from ... where 1非常容易呈现事务过大的谬误： ERROR 8004 (HY000): transaction too large, len:300001。 个别有如下办法来躲避这个问题：针对Insert、delete 语句开启无平安保障的dml batch 个性：TiDB_batch_insert、TiDB_batch_delete。分块拆分整条update 语句。在4.0 之后的版本里，除了单个kv entry 大小仍然限度为最大6MB，其余几个限度全副被勾销。 只须要在配置文件里加上如下选项就可涵盖大部分事务：performance.txn-total-size-limit: 10737418240（范畴 1G 到10G） 那是不是4.0 版本后就能够随便写事务了？ 当然不是！ 因为TiDB 的写放大，也会连带导致内存占用成倍增长，对其余业务会有很大影响，所以TiDB对最大事务反对硬性限度其为10G。比方用DM 来同步MySQL数据到TiDB，大事务会导致内存加大，写入提早剧增，进而影响其余的写性能。 ...

1、 下载tidb工具包留神下载的版本，我抉择现装到tidb节点 [root@tidb ~]# wget https://download.pingcap.org/tidb-toolkit-v5.0.2-linux-amd64.tar.gz2、 创立备份目录留神：请在执行备份命令的节点及所有KV节点创立备份目录，本地节点会寄存备份产生的锁文件， tidb是多正本构造，所以每一个存放数据的kv节点都会产生备份。 [root@kv1 /]# mkdir /bakcup[root@kv1 /]# chmod 777 /bakcup/3、 全库备份留神：PD节点IP和目录依据本人理论状况填写 [root@tidb bin]# ./br backup full --pd "10.0.0.201:2379" --storage "local:///backup" --ratelimit 120 --log-file backupfull.log4、 单库备份留神：再次执行备份时请更换目录因为不更换目录本地br工具节点的备份目录里有两个备份产时生的文件会间接造成报错，如果将目录里的文件删除复原时将无奈进行之前备份的复原。 这里咱们备份曾经有的sandata数据库 [root@tidb bin]# ./br backup db --pd "10.0.0.201:2379" --db sandata --storage "local:///backup" --ratelimit 120 --log-file sandatafull.log5、 单表备份备份sandata数据库里曾经存在的test表 [root@tidb bin]# ./br backup table --pd "10.0.0.201:2379" --db sandata --table test --storage "local:///backup" --ratelimit 120 --log-file testfull.log6、 参考文档https://docs.pingcap.com/zh/t...

作者：孙健 爱可生研发工程师，负责高可用组建和 SQL 审核相干开发。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文次要介绍如何借助 TiDB SQL 解析自定义生成 SQL 指纹，采纳了一种有别于 pt-fingerprint(https://www.percona.com/doc/p... 的形式。 什么是 SQL指纹SQL 指纹指将一条 SQL 中的字面值替换成其余固定符号。能够用来做 SQL 脱敏或者 SQL 归类。例如： select * from t1 where id = 100；转换成： select * from t1 where id = ?；pt-fingerprint 的实现从 pt-fingerprint 的代码实现看，它次要是通过正则匹配 SQL 字符串来替换对应字符。代码有 2 千多行，齐全通过字符串解析会使得代码及其简单而难以浏览，益处是无需关怀 SQL 语义。 基于 TiDB SQL parser 的实现TiDB SQL parser 的性能是把 SQL 语句依照 SQL 语法规定进行解析，将文本转换成形象语法树，另外 TiDB SQL parser 反对将语法树转换成 SQL 文本，因而能够通过批改语法树结构达到批改SQL文本的目标。 1. 通过 TiDB SQL 解析器将 SQL 解析成语法树解析出的语法树大抵如下，其中"..." 代表之前存在多级。 ...

本文次要介绍TinySQL的proj2的具体思路以及实现形式 文件tinysql/parser/parser.y:3806 JoinTable: /* Use %prec to evaluate production TableRef before cross join */ TableRef CrossOpt TableRef %prec tableRefPriority { $$ = &ast.Join{Left: $1.(ast.ResultSetNode), Right: $3.(ast.ResultSetNode), Tp: ast.CrossJoin} } /* Your code here. */在上述文件地位追加写入JoinTable的语法定义，测试不通过的case为 select * from t1 join t2 left join t3 on t2.id = t3.id报错提醒为 FAIL: parser_test.go:300: testParserSuite.TestDMLStmtparser_test.go:426: s.RunTest(c, table)parser_test.go:283: c.Assert(err, IsNil, comment)... value *errors.withStack = line 1 column 29 near "left join t3 on t2.id = t3.id" ("line 1 column 29 near \"left join t3 on t2.id = t3.id\" ")... source select * from t1 join t2 left join t3 on t2.id = t3.id能够看到谬误起始地位为left join局部，因而须要观测Join语句的定义地位，一个一个项拆解看看须要如何补充。原始定义为TableRef CrossOpt TableRef %prec tableRefPriority ，拆解进去包含了TableRef / CrossOpt / %prec / tableRefPriority这四项 ...

「咱们曾经用起来了」，是咱们最喜爱听到的话，简简单单几个字的背地代表着沉甸甸的信赖和托付。咱们将通过「置信凋谢的力量」系列深度案例分享，从业务的角度，看看一个数据库为各行业用户带来的业务价值。本篇文章将介绍 TiDB 在扩大浙商银行数据架构体系能力幅员的实际。 数据驱动决策，让金融服务更高效。浙商银行股份有限公司（简称“浙商银行”）是 12 家全国性股份制商业银行之一，致力于打造平台化服务银行，为客户提供凋谢、高效、灵便、共享、极致的综合金融服务。在英国《银行家》(The Banker) 杂志“ 2020 年寰球银行 1000 强”榜单中，按一级资本和总资产计，均位列第 97 位。截至 2020 年 6 月末，浙商银行在全国 19 个省（直辖市）及香港特别行政区设立了 260 家分支机构，实现了对长三角、环渤海、珠三角以及局部中西部地区的无效笼罩。 业务挑战随着浙商银行业务的倒退和数据量的激增，国外商业数据库的数据处理和存储能力短板逐步裸露，原有的数据架构体系不能满足新业务场景的需要。在行业政策提倡下，借鉴金融同业的应用教训，浙商银行将眼光转向互联网宽泛应用的分布式数据库产品，启动专项选型工作。 浙商银行的指标是寻找一款可能承载海量数据的 OLTP 型数据库，反对残缺的分布式事务，提供金融级的高性能、高并发、继续高可用能力；在架构上能够弹性程度扩大，平滑地应答各类业务流量；同时具备弱小的生态体系，反对连贯各类数据利用生态。通过多轮竞品比照测试与利用兼容验证后，TiDB 数据库在扩展性、海量数据规模下的查问性能、事务完整性等考查项问题当先，浙商银行抉择 TiDB 分布式数据库扩大数据架构体系的能力幅员。 TiDB 解决之道面向远期两地三核心的建设思考，浙商银行在杭州区域内双数据中心部署 TiDB 分布式数据库集群，应用数据五正本形式，将来可进一步扩大。目前已上线和投产三项利用：电信欺骗事件危险链查问（简称：电信反欺诈）、外汇交易治理和高管驾驶舱，并将逐渐延长到全行 ODS、互联网 C 端查问交易场景等业务畛域。 电信欺骗危险事件查问零碎电信欺骗危险事件查问零碎保留全国范畴的电信反欺诈数据，包含交易的账户和交易金额等具体数据。零碎反对对可疑的交易进行查问和监测，剖析交易金额、笔数、类型、工夫、频率和收付款方等特色，发现异常交易，须要及时采取交易暂停等措施或者通报公安机关。 电信反欺诈零碎的单表数据规模曾经超过 20 亿条，日新增数据百万条，原有的 OLAP 数据库从数据规模到业务查问性能上都无奈达到业务预期。TiDB 具备弹性伸缩的能力，只需简略减少节点，整个零碎的性能和吞吐能力都能够失去线性晋升，反对海量结构化数据的存储和查问，SQL 查问的返回工夫从几十秒缩短到几十毫秒。利用 TiDB Lightning 数据导入工具，可实现单次下发数据文件内上百万条数据记录的疾速导入，满足业务的操作窗口需要。 外汇交易治理基于外汇监管的要求，外汇交易管理系统须要实现外汇交易数据的采集、导入、存储、统计分析和数据挖掘等性能，相干数据要求长期保留，预计将来几年内数据规模将达到十亿级别。原先采纳的 Oracle 数据库，须要应用分区表的计划，导致运维治理和开发成本的回升。TiDB 的分布式个性能满足数据规模的扩大须要，弹性扩容能力能够实现数据的主动再平衡，对于业务齐全通明，不须要运维人员染指。同时，TiDB 的高可用机制提供异地多活的高可用能力，复原过程不须要人工操作，集群可能主动地实现容灾和保障强统一的数据恢复，让运维人员没有后顾之忧。 高管驾驶舱高管驾驶舱是为行内管理层提供实时经营指标的剖析零碎，通过突破数据隔离，实时反映各类业务的运行状态，将采集的数据形象化、直观化、具体化，实现指标剖析及决策场景落地。浙商银行利用数据同步工具实时地将上游 DB2 等异构数据库中的数据变动写入 TiDB，同时将 TiDB 中的实时变更数据同步到上游 Kafka ，Flink 从 Kafka 承受音讯进行流式计算，整个体系造成一个高效、易用的实时计算平台，实现银行各类业务经营情况的实时统计，并在可视化大屏进行展示。通过海量金融数据变动的在线捕捉和实时剖析，为银行各级管理人员提供业务决策依据，晋升服务效率。 将来场景摸索分布式实时 ODSTiDB 数据库具备大规模数据平台的服务能力，在数据层面实现 OLTP 零碎与 OLAP 零碎的闭环，集成 TiFlash 列式存储引擎之后，曾经成为真正的 HTAP 数据库（在线事务处理 OLTP + 在线剖析解决 OLAP），既能够作为数据源的业务数据库，进行业务查问的解决，又能够作为实时 OLAP 引擎，进行剖析型场景的计算。浙商银行外部有多个 OLTP 异构数据库，以 DB2 和 MySQL 为主，还有局部的 Oracle 和 SQL Server，各类异构数据库之间短少高效的数据同步伎俩，逐步造成了数据孤岛的状态。为应答各类业务对实时数据的需要，浙商银行打算在现有平台根底上进一步扩大，基于 TiDB 构建分布式实时 ODS（Operational Data Store，即时操作型的数据汇合），实现异构数据库中各类数据的准实时同步。TiDB 的增量数据同步工具 TiCDC 能够为上游数据生产端提供实时、高吞吐、稳固的数据订阅服务，通过凋谢数据协定与 MySQL、Kafka、Pulsar、Flink、Canal 等多种异构生态对接，满足大数据场景中对各类数据的利用与剖析需要。 ...

2020 年 12 月 5 日，TiDB 性能挑战赛完满落下帷幕。本次性能挑战赛次要围绕”固定 Workload 优化”和“解决高难度性能优化 Issue ” 两类赛题来进行，旨在通过具体的开发与我的项目实战，激励更多的开发者参加到 TiDB 整体的我的项目设计及倒退路线中，晋升本身技术实力，实现技术与我的项目翻新。 此次参赛对象包含：TiDB 客户、开发者、合作伙伴等，共 17 支队伍报名参赛，较量最终以优化成绩（性能晋升百分比）、小组 PR 总分（小组开发的相干代码被胜利合并到我的项目主分支提交对应比赛 PR 取得的积分）和现场问难完成度进行排名。最终有 7 组队伍进入决赛，在历时 3 个小时的缓和问难后，评比出前三名以及优秀奖，共计颁发 12 万元现金处分，以及价值 16500 美元的 TiDB Cloud 资源处分，比赛最终排名如下： 在推出的比赛打卡流动中，LGTMV587、X-Team、史莱克战队始终继续更新我的项目进度，在社区打卡、提交周报，被评为 “不间断打卡王”，取得了技术书籍《Chaos Enginerring》或《Database Internals》的处分。还有的小伙伴甚至都没有接触过 Rust，从头开始学起；还有的小伙伴通过本次性能比赛，取得了新的工作机会。 本届赛事在赛题设计方面融入了前沿的技术与利用方向，对数据库性能晋升有极高的要求，但问难我的项目的品质却远超预期。正如本次流动的发起人之一、 PingCAP 社区生态事业部负责人姚维所说：“数据库的性能调优始终被誉为‘皇冠上的明珠’，是该畛域最高技术水平的代表。所以最开始发动我的项目的时候也是没什么底的，但最初大家的成绩远远超出我的预期！” 优良我的项目展现 让咱们来看下这些优良团队的我的项目展现，包含他们的我的项目简介和参赛感触，看看哪些 idea 也能给你带来启发~ 第一名战队：huang-b Issue 链接 https://github.com/pingcap/tidb/issues/14441https://github.com/pingcap/tidb/issues/206 我的项目简介 huang-b 战队抉择的是一个高难度 issue。优化思路是应用 Shuffle 算子来实现 MergeJoin 算子和 Stream Aggregation 算子的并行化，在数据源无序的场景下，获得显著的性能晋升。后续将会思考如何对现有的 Shuffle 算子进行革新，打消其中存在的性能瓶颈，以期进一步晋升基于 Shuffle 的一系列并行算子的性能。其中，Shuffle Merge Join 的优化成果，最好的状况下 2 个 worker 的运算工夫仅为串行版本的 56.5%。 ...

TiDB Hackathon 是由 TiDB 社区主办，专属于寰球开发者与技术爱好者的顶级挑战赛事，通过开发与利用实战，激励开发者基于 TiDB 及上下游生态我的项目实现技术与商业翻新。 自 2017 年开办以来，TiDB Hackathon 在过来的三年连获好评，吸引了寰球 800+ 技术爱好者参加，先后诞生了 Unified Threat Pool、TiDB-wasm、TiDB 跨数据中心解决方案等一些列高质量我的项目，曾经成为寰球数据库技术畛域的出名赛事。 本届大赛主题为「∞」，参赛我的项目可围绕 TiDB 组件或联合 TiDB 生态周边（包含：TiKV、ChaosMesh®、Backup & Restore（BR）、TiDB Data Migration（DM）、Dashboard、Flink、ES 等上下游社区、用户&企业业务场景等）进行创作，用最硬核的技术和最炸裂的创意去发明有限可能。 赛事亮点奖金加码： 除了金额丰富的一二三等奖，本次大赛还将联结赞助商推出特别奖，以及增设最佳人气奖，欢送小伙伴们围观 Demo 现场投出你心中最佳的我的项目。 寰球联动： 去年北上广三地联动 Demo 的场景还历历在目，往年 TiDB 将更进一步，联动寰球开发者共享代码狂欢。 我的项目落地： 通过 TOC（Technical Oversight Committee） 投票表决的优良我的项目将在大赛完结后进入 TiDB Incubator 持续孵化，成为真正落地的社区我的项目。 参赛对象本届赛事面向寰球的数据库爱好者、 TiDB 用户、TiDB 生态合作伙伴及集体开发者凋谢报名，预计公开招募 60 组参赛团队，如果你相熟 Rust、Go 语言，把握分布式系统的基本原理，理解 TiDB 设计与实现，赶快退出吧。 大赛日程报名及提交我的项目设计 RFC2020 年 12 月 15 日- 2021 年 1 月 10 日 ...

TiDB 作为一款高效稳固的开源分布式数据库，在国内外的银行、证券、保险、在线领取和金融科技行业失去了广泛利用，并在约 20 多种不同的金融业务场景中撑持着用户的要害计算。在TiDB 在金融行业要害业务场景的实际（上篇）中，咱们介绍了 TiDB 在银行外围交易场景的利用，本篇文章将次要分享 TiDB 在外围外围的要害业务场景的实际。 TiDB 在领取业务中的实际 咱们在外围外围的要害业务场景也有很多的案例，例如当初比拟典型的在线领取业务。TiDB 次要涉足的领取畛域包含商业银行的网联/银联领取业务的联机交易数据库，第三方领取公司的挪动支业务外围领取零碎。通过 TiDB 提供的大规模吞吐，高性能大并发联机交易，多核心多活容灾，弹性扩大机制来撑持： 商业银行侧，来自网联/银联无卡的大并发领取交易指令和领取报文数据处理；第三方领取侧，来自挪动领取 App， 商户挪动 POS，领取场景嵌入式的领取业务零碎后盾的交易指令和领取报文解决；领取交易的联机处理类，次要为领取钱包数据的解决，领取交易数据联机插入与更新，交易状态实时查问，交易历史记录和账单查问；领取交易中的费率等计算；领取过程中的反洗钱零碎的数据汇聚及规定计算。自 2018 年投产以来，三年的工夫里 TiDB 稳固的反对了北京银行的网联领取和银联无卡领取的外围零碎，采纳了北京同城+西安两地三核心的多活容灾构造，顺利的度过了两次双十一，比拟好的撑持这个业务。另外，咱们在包含天翼领取的领取结算、账单、反洗钱平台，宝付的领取数据汇聚和日本排名第一的领取公司 PayPay 的联机领取外围及领取钱包外围平台，都有了具体的落地案例。 TiDB 在互联网理财业务中的实际 TiDB 次要落地股份制商业银行财产治理业务条线中的在线理财业务，通过 TiDB 提供的大规模吞吐、高性能大并发联机交易、多核心多活容灾以及弹性扩大机制来撑持理财业务中的： 理财交易的联机事务交易外围解决；理财交易系统的日间及日终的数据批量计算；理财交易系统数据的批量计算输入到监管报送，数仓等上游业务零碎；两核心多活容灾部署，提供高等级业务连续性保障。往年上半年，咱们和光大银行实现了理财交易外围库和联机批库交易的投产工作，比拟好的撑持了整个光大银行理财业务的外围联机交易的解决以及日间和日终的数据批量计算。此外，咱们也在北京银行的理财销售平台和微众银行企业同业的理财交易流水有了相干的场景落地。 TiDB 在实时风控业务中的实际 咱们还有一大类要害的金融利用场景是实时风控业务。跟传统的风控不一样，随着互联网化的业务场景增多，银行和泛金融机构对于实时风控的要求是十分高的。TiDB 目前在风控业务中的实时风控数据汇聚、存储、治理、加工、计算场景方面曾经有多个落地实际。通过 TiDB 分布式存储外围机制，应答海量数据的实时写入，同时分布式计算层以及行列混合引擎的设计可能针对风控指标的点查计算和批量汇总统计计算提供实时处理能力，将传统基于大数据伎俩的 “T+1” 风控业务解决能力间接晋升到 “T+0” 级别，如高达秒级的风控数据计算查问。 在金融业务场景方面，咱们有包含北京银行线上业务风控模型治理平台、微众银行 CNC 反欺诈零碎、天翼领取反洗钱平台、拉卡拉金融实时风控平台等一系列的场景落地。同时在互联网及电商业务场景中，包含像东南亚出名电商 Shopee 的风控平台，小红书反欺诈零碎及实时风控平台、拼多多风控平台等都有了一些落地。 TiDB 保险行业典型场景 除了银行业务之外，TiDB 也广泛应用在保险行业。在保险行业，次要在前台、中台、后盾三大畛域有投产业务。 在前台，次要是偏差于互联网和挪动端联机交易这一侧，包含保单的投保、财产增值、会员流动等一些在线联机交易的撑持。咱们在去年胜利的反对了安全产险暖宝保的业务，在很短的工夫内实现了整个集群的投产上线以及安全财神节的一个顶峰交易。 在中台，业务次要波及到以中台业务群为前端的后盾的数据撑持，包含像中台的微服务化、单元模块革新和业务的革新工作，TiDB 可能通过云原生的架构比拟好的适配微服务的应用环境，打消利用对分布式数据存取框架的依赖，无需引入数据中间件，并且可能做到在线弹性扩大。咱们在安全人寿的“金管家”业务和安全产险的“询价出单”业务中都有相干的落地。 在后盾，因为 TiDB 自身超大规模的海量数据存储架构以及具备批量数据的解决能力，咱们在认证、领取、结算、包含后面提到的风控类业务，都有若干的案例落地。在这类业务中，比拟偏差于实时的 OLAP 剖析，波及到 TiDB 提供多种上游数据源汇聚计划。 如何从原有架构迁徙到 TiDB 从金融行业，传统的业务迁徙到 TiDB，有几点想跟大家分享一下。 TiDB 的整体架构是多核心的构造，尤其是对于外围交易和要害业务场景来说，这个是刚需。咱们也是在包含北京银行、光大银行的两个外围交易库下面实现了多核心的架构。 ...

作为 TiDB 在「面向未来的数据库」路线上具备里程碑意义的版本，TiDB 4.0 在稳定性、易用性、性能、云原生等各个方面都有着微小的提高。新增的个性（如实时的强一致性、Severless 等）让 TiDB 产品可能反对更多元的业务类型；通过反对 TLS、减少官网组件管理工具 TiUP、提供可视化 Dashboard 及分布式备份工具 BR(Backup&Restore) 等形式，TiDB 4.0 在平安、生态以及性能加强下面都有了很大的晋升。越来越多的用户实现了 TiDB 4.0 的降级，并将 TiDB 在更多的场景中落地。行业内对于 TiDB 人才需求比拟旺盛，感兴趣的同学能够查看 TiDB 生态企业的优质职位，对于 TiDB 4.0 培训课程的呼声也继续走高。 在 TiDB 资深技术专家近半年的精心打磨下，TiDB 4.0 根底课程于今日陆续上线 PingCAP University（university.pingcap.com）。与此同时，PingCAP University 特发动「21 天 4.0 追“剧”挑战」，帮忙同学们疾速把握 TiDB 4.0 根底运维常识，还能赢取丰盛的社区大礼???? 欢送大家点击【链接】，进入 21 天 4.0 追“剧”挑战报名通道（截止工夫 2020 年 12 月 14 日 24:00）。 TiDB 4.0 课程 21 天定制学习打算相比 TiDB 3.0 课程，TiDB 4.0 课程做了如下降级： 优化课程学习曲线：TiDB 4.0 课程共设计了 3 个课程版本，别离为：???? 面向初学者的 101 版本 ...

随着云原生技术的迅猛发展，IT 基础设施正在产生微小改革，许多企业都将其架构迁徙至云原生平台，通过云原生技术，使得企业在私有云、公有云和混合云等云环境中，构建和运行利用变得更加容易，更能充分利用云环境的劣势。 作为晚期的云原生技术布道者与实践者，PingCAP 联手 CNCF、VMware 、网易数帆与阿里云，独特举办 2020 Cloud Native Day（2020 云原生生态大会）。为期两天的线上主题分享，您将有机会听到云原生领军企业和组织分享的云原生策略与实际，分析云原生技术带来的挑战和时机，推动云原生技术与企业 IT 的交融，更有来自头部用户的技术实际和翻新分享。 PingCAP 重磅议题领先剧透 Is Shared-nothing dead？云原生数据库设计新思路 黄东旭 | PingCAP 联结创始人兼 CTO 云计算从 AWS 初创时的牛刀小试到现在微小的行业和生态，显现出不可逆转的趋势。将来所有都会在云上，云上生态也须要新的根底软件。本次演讲将系统化剖析云扭转了什么？云基础设施和软件交融有哪些新方向？ TiDB Cloud 可观测性 郑佳金 | PingCAP DBaaS 工程师 TiDB Cloud 依靠于私有云提供开箱即用的云数据库托管服务，通过程度扩大领有近乎有限的存储容量和计算能力，反对多云多租户。本议题次要分享如何在云上监控多个 TiDB 与 Kubernetes 集群，以及通过监控、报警、日志 Demo 疾速把握 TiDB 可观测性。 Chaos Mesh® 在网易伏羲公有云的自动化注入实际 张慧 | 网易伏羲实验室高级测试工程师 网易伏羲实验室是国内首家业余游戏 AI 钻研机构，为了研究员可一站式实现模型的算法开发调试、训练调参优化、在线服务公布等流程，网易伏羲打造了基于 K8S 的公有云平台——丹炉。在简单的云平台下如何保障系统的稳固运行？混沌工程带给了咱们哪些益处？如何抉择适合的故障注入形式？如何应用 Chaos Mesh®️ 联合数据自动化的运行？心愿此次分享能给大家带来启发。 ???? 会议工夫：12 月 16-17 日线上直播 ???? 报名形式：点击【链接】立刻报名~ ...

TiDB 作为一款高效稳固的开源分布式数据库，在国内外的银行、证券、保险、在线领取和金融科技行业失去了广泛利用，并在约 20 多种不同的金融业务场景中撑持着用户的要害计算。本篇文章将为大家介绍分布式关系型数据库 TiDB 在金融行业要害应用领域的实际。 金融要害业务场景银行的业务零碎非常复杂，包含从外围上的账户、账务、结算等业务到外围的各种存、贷、票、汇以及面向互联网场景的各类金融业务。 随着科技的倒退，整个银行的外围交易系统走在本人的一个演进路线上，从传统的集中式利用构造逐渐向服务化、分布式这样的体系在演进。在国内，曾经有若干家在科技方面比拟当先的银行机构启动了对于外围的革新工作，在他们整个外围交易利用以及背地的数据处理层引入了十分多分布式的技术来撑持他们业务的倒退。在将来，整个倒退方向会更多的向单元化、服务化倒退，并且一些利用撑持的框架，例如云、微服务、将来的 serverless 等，都会逐步的向外围交易引入。 分布式外围零碎架构对整个数据库有以下几点比拟明确的要求： 平安，稳固，牢靠；提供分布式计算与分布式数据管理及在线弹性扩大能力；提供高并发，低提早，大吞吐的数据库解决能力；反对联机交易及批量(日间/终) 批量混合负载；反对外围上的报表和数据报送业务负载；提供牢靠和高性能的分布式联机交易事务；须要反对至多达到 “两地三核心” 的双核心多活及多核心容灾保障能力；RPO = 0, RTO 要达到监管及银行科技部门对外围零碎的高可用要求；外围业务利用开发/革新难度低；欠缺与便捷的运维治理能力。现有架构痛点目前，很多银行采纳的外围零碎数据库计划次要为传统的集中式数据库架构和基于 MySQL 的分库分表计划，但无论是集中式数据库架构，还是基于 MySQL 的分布式数据库架构，都会存在一些问题。集中式数据库架构次要有以下几点问题： 重大依赖专有高端硬件；无奈弹性横向扩大；与新一代分布式服务化外围利用架构匹配度低；建设及保护老本昂扬；DB2 / Oracle 数据库技术锁定；无奈利用云计算体系倒退成绩。基于 MySQL 的分布式数据库架构也存在以下几点问题： 数据库分布式中间件成熟度与可靠性仍须要考验；利用侵入水平高，革新复杂度大；利用模型和数据模型的锁定，就义灵活性；批量负载解决能力限度；分布式事务能力低下，须要人为利用开发侧和布局侧深度躲避；强一致性保障的危险；不足弹性扩大能力和在线扩大主动均衡的能力；MySQL 高可用技术的危险；两地三核心同城多活复杂度。基于 TiDB HTAP 架构的银行外围数据库解决方案计划一：TiDB 外围交易系统撑持架构第一个是比拟含糊其辞的计划，以 TiDB 作为外围交易库的主库。 在这种形式下，整个 TiDB 近似传统单机集中式数据库的拜访模式与业务利用开发模式，对利用的拜访是通明的。同时，无论是利用模型、数据模型还是整个事务交易模型，不须要做人为的切分。因为在外围交易利用的倒退过程中，除了以账户为角度，咱们还会以用户视图为角度，因而简略的通过找到用户的账户分片去做切分的话，实际上是就义了整个外围交易的灵活性。 另外以 TiDB 作为主库，内置的多核心、多活容灾的机制也简化了部署的复杂性、治理复杂性和老本；并且齐全的分布式联机交易事务反对，不须要利用干涉和提前锁定事务处理布局，用户基本上在 TiDB 上做联机交易的过程当中，跟单机数据库的应用是一样的；另外 TiDB 在后盾提供了一个动静的调度机制，所以在线的进行节点的扩容，齐全不会影响业务，无论是后盾数据均衡，还是外部引擎之间的负载平衡的主动调配，都是在引擎外部本人做的，不须要用户在利用侧有特地多的关注。 以 TiDB 作为外围交易库的主库，次要有以下几点价值： 在外围零碎数据库侧分布式革新大幅度降低革新难度与危险；业务模型和数据模型无需反向适配数据库架构；通明的计算和数据管理分布式，升高保护复杂度与老本；吞吐量及性能能够随在线横向通明扩大；规范 SQL, 分布式事务，多表简单关联计算，联机与批量混合负载解决能力，保障业务灵活性及适配分布式外围利用；内核反对强统一数据局部机制及高可用机制 (RPO=0,RTO <30s）；内核反对多核心多活容灾机制。长亮外围交易系统测试咱们与城商行一级的零碎做了比拟残缺的对接，包含长亮科技，咱们在他的外围交易系统上，包含账户、账务、贷款、发卡、现金管理、资产负载等这些外围模块做了充沛的适配。 从性能、正确性、交易的性能等方面做了充沛的适配和优化，实现了 2000 多个外围交易的功能测试，包含全量的近 200 个批处理测试。接下来，咱们正在跟长亮科技打算进行 V8 版本对接测试和基于 ARM 国产化平台的测试。 ...

在生产环境中，时常会因为磁盘故障、误操作等起因呈现文件系统的谬误。Chaos Mesh 很早就提供了注入文件系统谬误的能力。用户只须要增加一个 IOChaos 资源，就可能让对指定文件的文件系统操作失败或返回谬误的数据。在 Chaos Mesh 1.0 之前，应用 IOChaos 须要对 Pod 注入 sidecar 容器，并且须要改写启动命令；哪怕没有注入谬误，被注入 sidecar 的容器也总是有较大的性能开销。随着 Chaos Mesh 1.0 的公布，提供了运行时注入文件系统谬误的性能，使得 IOChaos 的应用和其余所有类型的 Chaos 一样简略不便。这篇文章将会介绍它的实现形式。 前置本文的内容假设你曾经把握以下常识。当然，你不用在此时就去浏览；但当遇到没见过的名词的时能够回过头来搜寻学习。 我会尽我所能提供相干的学习材料，但我不会将它们提炼和复述，一是因为这些常识通过简略的 Google 就能学到；二是因为大部分时候学习一手的常识成果远比二手要好，学习 n 手的常识成果远比(n+1)手的要好。 FUSE. Wikipedia, man(4)mount_namespaces. man, k8s Mount propagationx86 assembly language. Wikipediamount. man(2) 特地是 MS_MOVEMutating admission webhooks. k8s Documentsyscall. man(2) 留神浏览一下调用约定ptrace. man(2)Device node, char devices Device names, device nodes, and major/minor numbers浏览与 TimeChaos 相干的 文章 对了解本文也有很大的帮忙，因为它们应用着类似的技术。 此外，我心愿在浏览这份文档时，读者可能被动地思考每一步的起因和成果。这之中没有简单的须要头脑高速运转的常识，只有一步一步的（给计算机的）行动指南。也心愿你可能在大脑里一直地构思“如果我本人要实现运行时文件系统注入，应该怎么做？”，这样这篇文章就从单纯的灌输变为了见解的交换，会乏味很多。 ...

TiDB 应用 Prometheus 和 Grafana 提供了十分具体的监控指标。在遇到各种性能或稳定性问题时，这些监控个别是问题的要害线索。但详尽的细节监控指标应用门槛较高，刚入门的 TiDB DBA 可能难以上手，例如： 如何疾速理解以后集群最耗时的是哪类操作？发现写入耗时很长，如何进一步定位起因，应该查看哪些监控项？监控项这么多，它们之间的关系是什么？TiDB 4.0.7 起提供了一个新性能，能够将数据库各个外部流程的耗时监控按父子关系绘制为关系图，帮忙用户疾速以另一种维度理解集群状态。 简介监控关系图是在指定的工夫范畴内，将各个监控项按父子关系绘制的关系图。图中每个方框节点代表一个监控项，蕴含了以下信息： 监控项的名称监控项的总耗时监控项总耗时和查问总耗时的比例父节点监控的总耗时 = 本人的耗时 + 孩子节点的耗时，所以有些节点还会显示本人的耗时和总耗时的比例。 例如上面监控节点示意：tidb_execute 监控项的总耗时为 19306.46 秒，占总查问耗时的 89.4%，其中自身的耗时是 9070.18 秒，占总查问耗时的 42%。将鼠标悬停在该方框上，能够看到监控项的正文阐明，总次数，均匀耗时，均匀 P99 耗时等更多该监控的信息。 每个节点的大小和色彩深浅，与监控项本人的耗时占总查问耗时的比例成正比。个别在这个图中能够重点关注耗时较多的监控节点，而后顺着父子关系向下梳理。具体介绍请参考官网文档。话不多说，来看两个简略的示例吧。 示例 1最近新上线一个业务后，原来的集群响应忽然变慢了很多，小明看服务器 CPU 都挺闲暇的呀，而后抓了一个监控关系图如下： 能够很快发现，上图中： tidb_query.Update 示意 update 语句的执行耗时占总查问耗时的 99.59%。tidb_execute 示意 TiDB 的执行引擎自身耗时占 68.69%tidb_txn_cmd.commit 示意事务提交的耗时占总耗时的 30.66%tidb_kv_backoff.txnLock 示意事务遇到锁抵触的 backoff 总耗时占 15%，这要比发送 prewrite 和 commit 的 tidb_kv_request 的耗时高很多。到此，能够确定 update 语句存在重大的写抵触，能够依照 乐观事务模型下写写抵触问题排查 进一步排查抵触的表和 SQL 语句，而后和业务方沟通从业务上防止写抵触。 示例 2最近须要导入一批数据到 TiDB 集群，导入速度有点慢，小明想看看零碎当初慢在哪儿，而后看能不能优化下，他抓了一个导入数据时的监控耗时关系图如下： ...

本文转载自【申耀的科技察看】微信公众号，作者跨界的申斯基。毫无疑问，目前寰球根底软件行业有两个重要的趋势：一方面是“软件当初吞噬所有”，每一家公司都正在变成软件公司；另一方面是“开源也在吞噬所有”，越来越多的公司也都在拥抱开源，并应用开源软件。 开源分布式数据库，就是在这样的背景下，成为全面云化时代匹配企业数字化转型的最佳抉择。数据显示，到 2021 年传统商业数据库市场会降落 20% 至 30%，而与此相应的则是云数据库的迅猛增长，依照 Gartner 预测，到 2023 年寰球 3/4 的数据库都会跑在云上。 而成立于 2015 年 PingCAP，则是在这一波开源和云数据库浪潮中奔跑进去的优良代表之一。日前，PingCAP 发表正式实现 2.7 亿美元的 D 轮融资，更是再次发明了寰球数据库历史上的新里程碑。 那么，这家仅仅成立 5 年的企业级开源分布式数据库公司，为何频频受到投资人的疯狂“追捧”？在这背地，它到底有哪些独特的技术劣势和外围竞争力？更为重要的是，PingCAP 在中国根底软件畛域的冲破与翻新之路，又给业界带来了哪些重要的价值与启发呢？ 企业级开源软件大时代 咱们晓得，没有一个企业走向胜利的路线是平坦而不波折的，同时它也很难从教科书上找到“规范”的答案。换句话说，必须要有去采摘悬崖边那朵玫瑰的勇气，才有资格拿到通往胜利路线的通行证。 而回顾 PingCAP 过往 5 年的倒退历程，无疑就是上述这段话的最佳印证。始终以来，在中国科技产业的倒退过程中，外围根底软件畛域始终是一大“短板”，特地是在数据库市场，因为起步较晚，加上技术上也没有重大突破，因而也很难取得市场和客户的信赖，导致这个市场长期以来都被国外品牌所“垄断”。 如何突破这个瓶颈呢？PingCAP 的做法是，从守业就将“开源”当做公司的外围策略来推动，因为他们深信开源是当今根底软件畛域获得世界范畴内胜利的最佳门路，其外围产品 TiDB 也保持做新一代分布式开源关系型数据库，而历经5年工夫的打磨，以 TiDB 为代表的新一代分布式“NewSQL”数据库得以诞生，PingCAP 由此也成为寰球第一批用新的模式、新的思维、新的形式在开源分布式数据库赛道中跑进去的代表性公司。 在 PingCAP 创始人兼 CEO 刘奇看来：“咱们始终保持做开源，最初这变成了 PingCAP 的一个标签，变成了一个基本不可能撕下来的标签。” 事实上，PingCAP 不仅是这么说的，也是这么做的。 例如，TiKV 最后是由 PingCAP 团队在 2016 年 1 月作为 TiDB 的底层存储引擎设计并开发，第一版于 2016 年 4 月开源，2018 年 8 月被 CNCF 基金会发表接收为沙箱云原生我的项目，并在  2019 年 5 月从沙箱升级至孵化我的项目；2020 年 9 月，TiKV 成为 CNCF 正式毕业我的项目，这也是目前惟一位列国内开源社区前列的由国人主导的数据库我的项目。 ...

车好多团体系国内领军的汽车生产服务一站式平台，旗下领有瓜子二手车、毛豆新车、车好多车后三大外围业务。业务挑战车好多团体关注 TiDB 始于 2018 年初，像大多数公司一样，公司倒退初期为了疾速适配业务开发，大部分数据都存储在 MySQL 中。但随着业务疾速倒退，存量数据越来越多，咱们在 MySQL 面临着如下痛点: 业务拆分简单公司业务倒退快，单实例的 QPS 和数据存储会超出预期，这时候须要对业务线实例进行拆分。 每次业务线拆分须要从数据产生端 (APP) 到数据流转端 (CDC) 最初到数据仓库(DW)一起配合调整; 如果波及到多方同时应用雷同库表，还须要多个利用的负责人协调; 同时一些脚本类程序可能在迁徙时被疏忽，局部业务数据会受到影响。 每次业务线拆分的周期大略在 2-4 周，消耗人力。 分库分表侵入业务业务倒退到肯定水平之后，一些数据表的数据量超过千万级别，惯例做法是分库分表。这里有几个可能遇到的问题: 分布式事务不好解决；二级索引无奈创立；分库分表的设计是否反对二次扩容；跨库 join 无奈操作；后果集的排序合并难度大。大表构造批改艰难咱们公司的业务模式变动快，为了疾速响应业务，表构造常常调整。在对一些数据在百万级别以上的大表做 DDL 的时候，会借助第三方工具，如 pt-osc。批改过程中须要先复制一份长期表，这种形式批改的工夫较长，对存储空间、IO、业务有肯定的影响。 为什么抉择 TiDB面对以上痛点，咱们开始思考对数据库的架构进行降级革新，咱们依据业务方的诉求，将一些常见数据库技术计划，做了一些比照: 数据库类型长处毛病MySQL 分库分表1. 依据 ID 查问的层面基本上无多余工作量。2. 短期技术实现成本低。1. 库表数量线性增长，运维压力大，按百万级别数据量分表计算，每年增长表的数量至多 30 张，且单表容量依然较大。2. 分库分表在代码层实现需改变代码。3. 如引入分库分表中间件，则须要投入专门人员。MongoDB1. 技术比拟成熟。2. 大数据量下，可通过分片进行扩大。1. 业务须要全副重构，短期内无奈实现。2. 文档型数据库，须要业务来控制数据较验。ElasticSearch搜寻功能强大（多二级索引）。1. ElasticSearch 写入性能稍差，遇到大量写入操作时候，可能提早。2. 无 schema 治理，长期保护老本较高。HBase1. 技术比拟成熟。2. 一般依据 rowkey 查问，无工作量。3. 可横向扩大。1. 无奈通过 rowkey 间接获取数据的场景，都须要额定开发，接口通用性较低。2. 不反对二级索引。3. 协定与现有程序不统一，须要从新开发相干读写程序。HBase+phoenix1. 底层 kv 存储复用 HBase，存储引擎的稳定性强。2. 可横向扩大。1. SQL 语法小众。比方只有 upsert，没有独自的 insert 和 update。2. Phoenix 的事务性能依赖开源的 percolator 实现，可信度略低。事务还是一个比拟谨严的技术，Phoenix 社区和 Google 也没能查到太多事务相干的信息。HBase+ES1. HBase 作为 OLTP 的记录存储，ES 作为 HBase 的二级索引。2. 兼顾了 HBase 的长处（疾速的 kv 能力，海量存储能力，可变字段能力）和 ES 的长处（弱小的二级索引能力）。1. 不反对事务。2. HBase 和 ES 两端的数据统一保障难度高。TiDB1. 齐全兼容 MySQL 协定，业务层简直不须要改变。2. 分布式存储，节点有限扩容，高可用。3. 完满代替 MySQL 分库分表。4. 大表 DDL不影响业务。5. 反对事务，隔离级别为'快照级别隔离' [见附录]。6. 可兼容 CDC 链路。1. 资源需要较高。2. 无触发器、存储过程、某些语法不兼容。TiDB 具备程度弹性扩大，高度兼容 MySQL，在线 DDL，一致性的分布式事务等个性，合乎车好多局部数据量大，业务变更频繁，数据保留周期长等场景。 咱们通过 TiDB 的内部测试后，确认能够满足现有业务需要。咱们最终抉择了 TiDB 做为这类需要的数据存储。 ...

王贺看起来是一个不走寻常路的大三学生，从小就喜爱计算机，对于很多大学才开始接触编程的同学来说，高三就能够本人做一个 Linux 发行版无疑是同龄人中的佼佼者了。 明天就来理解一下 TiDB Committer，DDL SIG 的 xhebox 的奉献之路。 过后怎么想到要本人做一个 Linux 发行版呢？开始接触 Linux 的时候我感觉 glibc 太大了，下载下来有几十 MB 所以想换掉它。过后正好接触到了除了 glibc 以外的 libc，我就萌发了本人做发行版这个想法，甚至还想把 GNU 所有的货色都换掉，尽管最初失败了，但发行版还是做了下来。 我从小就喜爱折腾这些货色，小学的时候用 Discuz 搭建过网站，高中时折腾苹果零碎，这些都是因为趣味所以自学的，也给我高三做 Linux 发行版打下了根底。我也是那个时候开始理解到 Go，我的 Linux 发行版的包管理器就是用 Go 写的，最近也开始在学习 Rust。 你做的 linux 发行版当初能够下载到吗？以前是能够在 GitHub 上下载，当初不行了，我没有保护二进制包管理器，如果他人想用的话恐怕须要见到我自己，我能够用硬盘复制一份：）次要起因是保护二进制包十分耗时间，以前有 600 个包，当初被我削减到只有 300 个。我平时上课做试验也没有这么多工夫， 几百个包都是手动编译，如果开源再保护，那可能没方法做其余事了。 你是怎么和 TiDB 结缘的？第一次理解 TiDB 是 TCP 我的项目（Talent Challenge Program），在这之前我没有接触过数据库。有一天正好看到群里在发这个流动的信息，感觉挺有意思，不过这个流动须要 TiDB Contributor 能力参加，于是我就给 TiDB 提了一个 PR，在成为 Contributor 之后我就开始正式的退出了这个我的项目。 加入过其余社区的流动吗？假期的时候我加入过快手的 KCode，次要较量内容是读文件去计算 QPS。不过我加入完热身赛就不做了，到了决赛和半决赛会加一些限度，赛程前面比拟偏差 IO 优化。我感觉我不是很善于做比赛或算法之类的较量，更偏差学习和入手能力，所以更适宜 TCP 这样的我的项目，本人施展的空间更大。 ...

本文依据黄东旭在 PingCAP D 轮融资线上发布会的演讲实录进行整顿。 TiDB 的当初和将来大家好，我是黄东旭，是 PingCAP 的联结创始人和 CTO，这是 PingCAP 成立以来的第一次发布会，我想跟大家简略聊聊 TiDB 在产品和技术上的更新。思考到线上的很多观众不肯定是有很强的技术背景，我将尽我所能将技术的局部说得让大家都可能了解。 在讲正题之前有一个小故事，咱们做根底软件的产品经理去跟客户聊需要的时候，客户常常都会说：对于数据库，我的要求特地简略、特地根底、十分奢侈，我不要求很多性能，平安稳固是必须的，最好能高可用，性能肯定要好，如果数据量大了，能实现弹性伸缩就更好了；另外，最好别让我学太多新货色，用起来跟过来应用的产品差不多，这就是一款完满的数据库产品。 就像大家在家里用自来水一样，咱们对自来水的需要就是拧开水龙头水就能进去，然而背地自来水厂是怎么解决的大家不必晓得，咱们只须要依据理论状况应用冷水或者热水就好。然而从技术的角度来说，方才相似冷热水这个十分奢侈的根底需要，类比一下放到数据库的世界这就是一个图灵奖级别的根底需要，略微解释一下图灵奖是计算机行业学术界最顶级的，相当于计算机界的诺贝尔奖。 这里有两位行业泰斗级的人物，右边 Leslie Lamport 在 2013 年钻研相干问题拿了图灵奖，左边这位跟咱们挺有缘的，发型跟（咱们的 CEO）刘奇同学挺像，他是 UC 伯克利分校的一名传授，也是驰名 CAP 定理的提出者，PingCAP 中的 CAP 就是来源于此。尽管看上去这个需要是一个很奢侈的需要，然而这是一个值得去花很长时间钻研，在技术畛域很有挑战，也是一个很前沿的钻研畛域。 在聊数据库之前，我想带大家回顾一下十年前的电子产品，回顾一下咱们当年的生存，大家回忆一下十年前咱们手上的数码产品有哪些，比方咱们打电话有诺基亚，拍照有数码相机，也有用来做导航的独立设施 GPS，听歌用的 MP3 等等，品种繁多。 咱们再来回顾一下这十年，这些货色如同在咱们的生存中慢慢消失掉了，一台智能手机把很多这些碎片化的货色对立了起来，我感觉这背地一个很重要的点就是咱们对于对立用户体验的谋求驱动了整个科技界产品产生天翻地覆的改革，当初一台智能手机根本解决了咱们生存中百分之七八十的数字化生存场景的需要。 TiDB 是一个 HTAP 零碎接下来进入正题，PingCAP 是做数据库的厂商，如果咱们拉一条数轴来看，右边的业务是更偏实时在线的业务，如果这条数轴的左边是离线业务的话，依照这个数轴来看，数据库这个产品大家可能印象中是在右边的，一些典型场景，比方像 Hadoop 或者一些数据仓库、报表是在左边。 再看一个具体的业务场景，假如是一个公司要打造电商平台的 IT 零碎，梳理一下当初电商平台外部有各种各样的利用和场景，咱们依照这些场景放到这个数轴上，右边是在线，左边是离线，咱们看到比方交易、订单治理、明细查问，这可能是偏在线的业务，用户用手机随时能够关上看；左边离线业务更像是外部经营人员，比方老板查看去年赚了多少钱，这种报表可能是一个更偏离线的业务。 大家有没有发现两头有一些实时的报表，实时的促销调价，热销产品的举荐，你放在右边不适合，放在左边如同也不太对，所以两头局部是一个比拟含糊的状态，这是一个业务的语言，比方咱们把这个业务放到这条轴下来看，比如说我是电商平台的技术人员，业务人员通知我，咱们下面这些需要，这些需要翻译成技术的语言会变成什么样子呢？ 就变成了各种各样的 OLTP 数据库和 OLAP 数据库和数据仓库，比方像 ClickHouse、Greenplum，像离线的数据仓库 Hadoop、HIVE，有很多同学不理解这些名词没关系，我只是想展示一下，业务需要翻译成技术语言，通常须要一系列简单的数据技术栈来撑持。 可能有很多观众学过计算机技术，我记得我在上大学的时候，咱们有一门课是叫数据库系统，老师上课的时候教我数据库就是增删改查，就是存数据、取数据的一个零碎、一个软件，几个要害的命令 INSERT\SELECT\UPDATE\DELETE，我回顾了一下好象也没有教哪些场景是 OLTP 的场景，哪些是 OLAP 的零碎，并没有这么简单。 数据库应该就是存数据、取数据理所当然，就像水龙头一样一拧开就出水，我还顺便查了一下 database 的定义，在维基百科下面的定义其实并没有说 OLTP 的 database 或者 OLAP 的 database。 ...

「咱们曾经用起来了」，是咱们最喜爱听到的话，简简单单几个字的背地代表着沉甸甸的信赖和托付。从明天开始，咱们将通过「置信凋谢的力量」系列深度案例分享，从业务的角度，看看一个数据库为各行业用户带来的业务价值。 本篇文章将介绍 TiDB 在 360 网盾业务、智慧商业业务、广告物料数据业务等外围场景的利用与实际。 以科技为驱动力，让世界更平安更美妙360 公司创建于 2005 年，是中国当先的互联网和平安服务提供商，先后推出 360 安全卫士、360 手机卫士、360 平安浏览器等平安产品。 随着全社会、全行业数字化水平的深入，“大平安”时代减速到来，360 以“让世界更平安更美妙”为使命，致力于实现“一直发明黑科技，做全方位守护者”的愿景，随之而来的业务倒退也更加全面，包含：政企服务、金融科技、直播、集体服务、智能穿戴等多方面业务。 业务挑战网盾业务360 网盾是一款收费的上网爱护软件，能够拦挡木马、欺诈网站等等爱护消费者不受到病毒及虚伪网站的欺诈。它的运行机制是会针对每一条 URL 进行剖析，通过网址检测零碎判断后，可能精准辨认出该 URL 属于哪个类别。对有问题的 URL 公布到云，其余平安服务商就能够通过订阅云服务，来检测相干的 URL 是否平安，以向本人用户提供更加平安的网页内容服务。 目前整个网盾业务外围场景能够分为以下四个局部： 网址威逼监测：每天入库 1 亿条数据，8 亿多资源链接数据；关联剖析场景：进行大规模歹意网址、黄赌毒等网站的关联剖析；高速返回：897 亿条数据表，每个场景 100+ 条数的查问须要在 5 秒内返回；人工经营剖析：每天每个人一直重复查问统计、剖析。针对业务爆发式增长的数据量，读写上 MySQL 曾经呈现瓶颈。例如磁盘空间，尽管能够通过分库分表的形式，拆分进去，但这对业务和 DBA 来说都是不小的工作量；最苦楚的无异于这些大表的改表，对一张大表执行 DDL 的代价是十分大的。总的来说，MySQL 曾经无奈满足网盾业务需要，这对负责底层数据平台撑持的 360 云平台技术团队提出了新的选型需要。 360 云平台负责对 360 团体各大业务线提供服务反对，波及的数据库反对计划有：MySQL、Redis、MongoDB、ElasticSearch、Greenplum、PiKA。在通过充沛的市场调研后，360 云平台团队决定引入 TiDB 来满足业务这一需要。 整体架构如上，应用 TiDB 的业务次要有两种： 原有 MySQL 业务迁徙。因单机磁盘受限，导致单实例磁盘无奈撑持爆炸式增长的数据量，数据比拟重要，须要备份和反对 7*24 小时的复原。这类业务通过 DM 套件来实现无障碍迁徙，1TB 的导入工夫在 16 小时，如果是比拟大的数据源，且 TiDB 是全新集群，能够应用 TiDB Lightning 进行数据导入，速度能够达到 100G/小时。全新的业务。全新的业务目前全副都会放到 TiDB 中，这种业务数据量个别都会比拟大，目前网盾业务有多张表都过 10 亿级别，其中有张表达到了 100亿+。智慧商业业务360 智慧商业依靠笼罩用户全场景的互联网产品，为企业提供全生命周期服务。通过智能营销、企业服务、翻新平台等多元业务布局，满足多维增长需要，全面连贯用户与企业，打造共生共长的智慧商业生态，其中互联网广告是流量商业变现的重要途径之一，也是 360 团体重要的营收起源，其中波及企业服务平台、广告主投放、算法策略、数据工程等多个方向。广告投放过程中实时/离线报表业务以及广告物料投放对广告主来说是最重要、最外围的业务。 ...

他是第一期 Talent plan 的学员，也是第一期易用性挑战赛优良参赛选手，领有多个身份的他成为了 TiDB 新晋 Committer，他就是来自 Execution SIG 的马钰杰（mmyj）。 他是游戏云玩家，也喜爱钻研电子产品，总是第一工夫动手，也逃不过第一工夫吃灰。目前在星火网校做后盾开发，工作中接触最多的语言是 Golang。他自称是个典型的程序员，但在采访的间隙忽然让我稍等他一下，去给女友煮汤圆，着实让小编酸了一把～ 明天，让咱们来看看 mmyj 在 TiDB 社区的心路历程吧！ 第一次奉献 TiDB，感触如何？2019 年 10 月，我第一次据说 TiDB，也是第一次接触到开源，之前并没有特地关注这个畛域。因为公司应用 golang，所以我想找一些 golang 的我的项目学习，起初无心中在 GitHub 上发现了 TiDB 的文档和源码浏览流动，这让我参加社区失去了很大帮忙。我还记得第一个 PR 是 execution 向量化的流动。 过后感觉学习的门槛不高，正好那段时间有易用性挑战赛，就尝试加入了。最开始的时候会有点不知所措，不晓得如何提交 PR 能力被驳回。不过社区小伙伴都很急躁，逐步的我也就适应了奉献流程。 为什么会继续给 TiDB 奉献？我在易用性挑战赛花了挺多工夫，一上班八点多到家就开始做 issue。除了有周边能够兑换，我对 Reviewer 也很向往，感觉 Reviewer 是我致力的一个方向。我很感激 Execution SIG 的 mentor 给了我很多帮忙，我也心愿本人能够反哺社区，像过后 mentor 们帮忙我一样，领导社区的同学来奉献回馈社区。 有一次我印象特地粗浅，过后我有一个问题不太明确，立元就给我画白板来解释，惋惜我过后太害羞，胆怯麻烦他所以不好意思开摄像头，如果是当初我肯定会更大胆的和导师交换。 TiDB 社区气氛很好，我心愿能够把这份善意传递上来。 奉献过程中遇到过艰难吗？中途是否想过放弃？有一个 PR 我断断续续做了很久，优化灵感的起源是一篇论文，我先花一个月工夫看完了论文，而后再花一个月工夫看 TiDB 代码，钻研怎么批改能力达到论文的成果。难点在于，这个 PR 有很多优化的小点，把所有优化点都做完，整个阵线就须要拉的很长。 在学习 Talent plan 课程的过程中也遇到了一些艰难，因为课程的学习是在已知的框架内找一个未知的答案，对我来说是一个挺有挑战的事件。过后卡在优化器局部，不过最初我也没有寻求导师的帮忙，本人去看 TiDB 源码找到了答案，感觉是有一点小舞弊了哈哈。 ...

「咱们曾经用起来了」，是咱们最喜爱听到的话，简简单单几个字的背地代表着沉甸甸的信赖和托付。从明天开始，咱们将通过「置信凋谢的力量」系列深度案例分享，从业务的角度，看看一个数据库为各行业用户带来的业务价值。 本篇文章将介绍 TiDB 联手中通科技打造全场景全链路数字化平台服务的故事。 洞悉包裹的每一段旅程不负身边的每一份守候下单秒杀，到收货开箱，置信大多数人对于“双十一”这个非凡期间的快递物流体验相当相熟。从下单后的『望穿秋水』到包裹的『全流程追踪』，最近几年，快递再不是以前“肩扛手提的黑盒子”，电子面单、自动化分拣、智能机器人、全链路数字追踪等数字化技术的加持下，快递业正在酝酿一场能够预感的全新变质。 中通快递成立于 2002 年，通过十余年的倒退，目前整体业务规模达到了世界第一，也是第一个达成年百亿业务量的快递企业，去年的双十一更是实现了订单量超过 2 亿的佳绩。中通科技是中通快递旗下的互联网物流科技平台，领有一支千余人规模的研发团队，秉承着“互联网+物流”的理念，与公司的策略、业务严密的连接，为中通生态圈的业务打造全场景全链路的数字化平台服务。 业务挑战快递的生命周期简略的介绍能够分为五个字，收发到派签。 整个物流的全链路中依照这样的流程会拆解成多个要害节点，在每个要害节点会产生大量的数据，对每个要害节点每一个数据快递公司都会进行相干的剖析，包含时效的监控（比方快递的流程跟踪、快递在快递收发点停留时间等等）。原来的架构大量的数据统计分析依赖于在 Oracle 上建好多存储过程，但随着数据量越来越大，存储和计算的问题越来越显著，单纯靠降级 Oracle 的硬件无奈从根本上解决问题，并且随着硬件的一直降级，老本也越来越高。 近几年，快递行业的业务量突飞猛进，随着业务倒退带来的数据量激增，中通遇到了以下问题： 寄存在 Oracle Exadata 一体机数据周期越来越短，分库分表的设计满足不了时效需统计分析依赖存储过程，零碎的扩展性和可维护性不高。业务顶峰期间单机遇到性能瓶颈，故障危险较高，数据同步 T+1 的剖析时效不够。如何升高 TCO。业务倒退快、数据量激增，能寄存在 Exadata 一体机数据周期越来越短，业务方对数据周期需要回升。业务顶峰单机性能瓶颈，单点故障危险高，数据同步 T+1，剖析时效不够。测试 HBase、Kudu 建设实时数仓，和现有技术栈难以兼容，并且不能很好撑持业务端多维度的 query。面对这些需要，中通快递新构建的 IT 零碎除了要兼容过来的 IT 架构，更要具备敏捷性，要可能更快响应业务倒退的需要，并且还能更好地推动将来业务的倒退。在要害业务上的反对上，底层的数据库须要满足强统一分布式事务，反对高并发读写，提供灵便的在线扩大能力，并且能够与 Spark 技术生态严密交融，反对大宽表的建设，反对多维度的查问剖析。 Why TiDB依据中通理论业务状况和技术痛点，构建了 TiDB 数据库集群，实现了多个利用零碎生产数据的实时写入，借助 TiSpark 实现了数据实时剖析，汇总数据，同时下层利用提供了标准化的 API 接口，给业务经营人员和快递人员提供了灵便的查问界面，满足了实时、便捷、精确的查问服务申请，抉择 TiDB 具体起因如下： TiDB 反对在线扩大，数据按 Region 分片，有自带的调度治理组件，进行热点的调度和数据分布。强统一的 ACID 分布式事务、二级索引。能高并发写和更新，并且反对疾速响应业务方的需要、进行查问后果。技术生态与 Spark 紧密结合，反对用 Spark 疾速的做分钟级统计分析。反对大宽表的建设，反对多维度的查问剖析。解决方案订单 & 运单核心用户通过平台客户端下单后，产生惟一的快递单号作为惟一身份标识。快递除了订单号，还会有很多属性信息，如：邮寄人、邮寄人手机、邮寄人地址、收件人、快递类型等信息。生成快递订单后，用户的邮寄物品才会成为“快递”。 当快递收回后，快递员从收件、扫码、转运等快递的流转事件、地点、工夫信息都将会不定期推送至零碎。快递流转信息不仅能够是简略的量化数据，也能够是描述性文字、地理位置等非凡信息。零碎须要将流转信息记录成快递的监控数据，同时批改快递状态、实时地位等，从而实现包裹的『全流程追踪』。 在中通快递传统的 IT 体系架构里，大量的数据统计分析依赖于 Oracle ，但随着数据量越来越大，存储和计算的问题越来越显著，单纯靠降级 Oracle 的硬件无奈从根本上解决问题，并且随着硬件的一直降级，老本也越来越高。 ...

「咱们曾经用起来了」，是咱们最喜爱听到的话，简简单单几个字的背地代表着沉甸甸的信赖和托付。从明天开始，咱们将通过「置信凋谢的力量」系列深度案例分享，从业务的角度，看看一个数据库为各行业用户带来的业务价值。 本篇文章将介绍 TiDB 助力微众银行金融外围场景的故事。 科技普惠公众，数据连贯智能从一次惊喜，到每次陪伴 咱们让美妙产生 微众银行是国内首家停业的民营银行，由腾讯、百业源和立业等多家知名企业发动设立，于 2014 年 12 月取得由深圳银监局颁发的金融许可证，总部位于深圳。停业 5 年多来，微众银行始终保持普惠金融的定位不变，踊跃使用金融科技构建普惠金融新业态、新模式，初步走出了一条商业可继续的普惠金融倒退模式。 截至目前，微众银行服务集体客户已冲破 2.5 亿人；集体经营户超过 2000 万，企业法人客户超过 150 万家，累计发放了超过 3200 亿元的贷款，反对就业人口超过 400 万。这些客户全副为民营企业，散布在 27 个省的 200 余座城市，其中，约三分之二的企业客户和 37% 的集体经营贷款客户属首次取得银行贷款，充分体现了微众银行普惠金融的定位和特色。 客户收益微众银行成立以来始终以科技作为驱动业务倒退的外围引擎，曾经具备齐全自主可控、反对亿级海量用户和高并发交易的外围零碎，已实现年均日交易超过 3 亿笔、单日交易峰值超过 6 亿笔；每账户运维老本不到行业均匀的十分之一。 从 2018 年开始调研并上线 TiDB 至今，微众银行曾经有数十个业务零碎在 TiDB 上投产，数据量从百 G 到几十 T 不等，目前也有多个重要的零碎正在 POC 或筹备投产阶段。明天这篇文章介绍两个 TiDB 撑持的比拟重要的场景： 资产证券化零碎批量场景下的 TiDB 实际。交易数据存证 TiDB 实际。面临挑战自成立之初，微众银行就十分有前瞻性的意识到底层基础设施建设对银行倒退的重要性，抉择了建设分布式架构 IT 基础设施的路线。基于便宜通用的硬件设施和各类开源的软件产品，微众建设了基于单元化的松耦合、可扩大的分布式架构。 为了实现业务规模的程度扩大，微众银行设计了基于 DCN 的分布式可扩大外围架构，从而即实现了整体扩展性，也保障了单 DCN 数据库层面架构的简洁性。DCN，即 Data Center Node(数据中心节点)，是一个“自蕴含单位”，包含了残缺的应用层，接入层和数据库，每个 DCN 承载规定数据量的用户。能够艰深的了解为，一个DCN，即为一个微众银行的线上的虚构分行，这个虚构分行只承载微众银行某个业务的一部分客户。 ...

「咱们曾经用起来了」，是咱们最喜爱听到的话，简简单单几个字的背地代表着沉甸甸的信赖和托付。从明天开始，咱们将通过「置信凋谢的力量」系列深度案例分享，从业务的角度，看看一个数据库为各行业用户带来的业务价值。 本篇文章将介绍 TiDB 助力中国电信翼领取金融外围场景的故事。 餐饮娱乐 、投资理财、商户服务......让大家纵情享受平安、便捷的金融新生存。中国电信翼领取（以下简称：翼领取）成立于 2011 年 3 月，是中国电信旗下的经营领取和互联网金融的业务品牌，是中国人民银行核准的第三方领取机构，是中国证监会核准的基金领取结算机构，反对各类线上线下民生领取利用，始终致力于为集体、企业提供“平安、便捷、时尚”的领取解决方案。 2019 年翼领取月活用户 5000 万，每月 2.3 亿笔交易，年交易金额超 1.75 万亿。目前累计接入华润、永辉、苏宁小店、物美、中百等超 800 万家线下商户门店及苏宁易购、京东、天猫、饿了么、中粮我买网、美团等 170 余家线上电商。 客户收益面对业务快速增长及强烈的市场竞争压力，翼领取技术团队抉择 TiDB，对业务零碎尤其是领取零碎数据库进行革新降级。通过不懈努力，反洗钱零碎效率晋升 5 倍，对账平台性能晋升 2 倍，而解决工夫缩小 ⅔ ！目前，翼领取业务层以及外围平台层都采纳 TiDB 提供服务。 咱们对系统的革新降级，不仅达到了监管部门的要求，也让财务部门经营的解决能效失去了很大的晋升，还大大降低了技术团队的工作复杂度。新零碎上线当前，咱们对 TiDB 的体现比较满意。 ——翼领取基础架构技术团队风控监管：反洗钱零碎超过监管要求，实测结果显示：整体批处理性能进步了 3 倍以上，工夫也缩短至原来的 ⅓，平台整体无效解决能力晋升到 5 倍以上。搭档结算：对账平台解决工夫缩小 ⅔ ，性能进步 2 倍，就常常应用的三种模式来看：银联支付宝，以前应用 MySQL 用时两分钟，当初应用 TiDB 只有 40 秒，性能进步了 300%；银联无卡领取，应用 MySQL 用时 3-5 分钟，TiDB 用时 1-2 分钟，性能晋升 200% - 300%；微信领取，MySQL 用时 3 分钟，TiDB 约 1 分钟，性能晋升 300%。集体账单：无效改善应用体验，减少了用户活跃度，解决了原有分库分表在容量、存储周期、查问效率等方面问题：当初应用 TiDB 单表数据量近 100 亿，原来 MyCAT 只能依照月来分表，单表存储容量下限为 1 亿；存储周期能够借助 TiDB 线性扩大能力缩短至 3 - 5 年，甚至更长，原来 MySQL 只能存储半年；QPS 晋升 50 %，提早升高 20-30%，胜利应答 525 大促。面临挑战优异成绩的得来，向来都不是一帆风顺。在我的项目启动之初，单方团队就面临了不小的难题。 ...

社会数字化、智能化的倒退过程中，海量的数据带来微小挑战，各行各业都在减速数字化转型，越来越多的企业意识到数据基础设施是胜利的要害。然而，作为数据基础设施的外围，传统数据库例如 MySQL 面临性能和容量瓶颈，通过中间件实现的分库分表计划复杂度高，同时带来昂扬的运维老本。 作为一款企业级 NewSQL 数据库，TiDB 采纳计算、存储拆散的架构，能够依据业务须要进行弹性的扩大，应答更加实时和智能的数据利用需要。TiDB 提供 Data Migration (DM) 生态工具，帮忙用户实现从 MySQL 到 TiDB 数据迁徙，无效升高迁徙老本和危险。 DM 是由 PingCAP 研发的一体化的数据迁徙工作治理平台，反对从 MySQL、Aurora或 MariaDB 到 TiDB 的全量数据迁徙和增量数据复制。DM 2.0 版本现已正式公布，新增高可用、乐观协调模式下的分库分表合并迁徙等企业级个性，同时带来一系列易用性的晋升，确保用户的原数据库能够平滑地切换到 TiDB，齐全不必放心迁徙带来的故障与数据失落。 DM 2.0 新个性数据迁徙工作的高可用DM 2.0 提供数据迁徙工作的高可用，局部 DM-master、DM-worker 节点异样后仍能保证数据迁徙工作的失常运行。 当部署多个 DM-master 节点时，所有 DM-master 节点将应用外部嵌入的 etcd 组成集群。该 DM-master 集群用于存储集群节点信息、工作配置等元数据，同时通过 etcd 选举出 leader 节点，该 leader 节点用于提供集群治理、数据迁徙工作治理相干的各类服务。若可用的 DM-master 节点数超过部署节点的半数，即可失常提供服务。 当部署的 DM-worker 节点数超过上游 MySQL/MariaDB 节点数时，超出上游节点数的相干 DM-worker 节点默认将处于闲暇状态。若某个 DM-worker 节点下线或与 DM-master 产生网络隔离，DM-master 能主动将与原 DM-worker 节点相干的数据迁徙任务调度到其余闲暇的 DM-worker 节点上并持续运行。 ...

前言咱们之前在生产环境上遇到过很多起由操作系统的某些特色引起的性能抖动案例，其中 THP 作案次数较多，因而本文将和大家分享 THP 引起性能抖动的起因、典型的景象，分析方法等，在文章的最初给出应用THP 时的配置倡议及敞开办法。 THP（Transparent Huge Page） 简介世界并不是非黑即白的，THP 也是内核的一个重要特色，且继续在演进，其目标是通过将页表项映射更大的内存，来缩小 Page Fault，从而晋升 TLB （Translation Lookaside Buffer，由存储器治理单元用于改良虚拟地址到物理地址的转译速度）的命中率。联合存储器层次结构设计原理可知，当程序的访存局部性较好时，THP 将带来性能晋升，反之 THP 的劣势不仅丢失，还有可能化身为恶魔，引起零碎的不稳固。遗憾的是数据库的负载拜访特色通常是离散的。 Linux 内存治理回顾在陈说 THP 引起的负面景象前，先来和大家一起回顾下，Linux 操作系统是如何治理物理内存的。对于不同的体系结构，内核对应不同的内存布局图。其中用户空间通过多级页表进行映射来节约映射管理所需的空间，而内核空间为了简略高效采纳线性映射。在内核启动时，物理页面将退出到搭档零碎 （Buddy System）中，用户申请内存时调配，开释时回收。为了关照慢速设施及兼顾多种 workload，Linux 将页面类型分为匿名页（Anon Page）和文件页 （Page Cache），及 swapness，应用 Page Cache 缓存文件 （慢速设施），通过 swap cache 和 swapness 交由用户依据负载特色决定内存不足时回收二者的比例。为了尽可能快的响应用户的内存申请需要并保证系统在内存资源缓和时运行，Linux 定义了三条水位线 （high，low，min），当残余物理内存低于 low 高于 min 水位线时，在用户申请内存时通过 kswapd 内核线程异步回收内存，直到水位线复原到 high 以上，若异步回收的速度跟不上线程内存申请的速度时，将触发同步的间接内存回收，也就是所有申请内存的线程都同步的参加内存回收，一起将水位线抬上去后再取得内存。这时，若须要回收的页面是洁净的，则同步引起的阻塞工夫就比拟短，反之则很大（比方几十、几百ms 甚至 s 级，取决于后端设施速度）。除水位线外，当申请大的间断内存时，若残余物理内存短缺，但碎片化比较严重时，内核在做内存规整的时候，也有可能触发间接内存回收（取决于碎片化指数，前面会介绍）。因而内存间接回收和内存规整是过程申请内存门路上的可能遇到的次要提早。而在访存局部性差的负载下，THP 将成为触发这两个事件的幕后黑手。 最典型特色 —— Sys CPU 使用率飙升咱们在多个用户现场发现当调配 THP 引发性能稳定时，其最典型的特色就是 Sys CPU 使用率飙升，这种特色的剖析比较简单，通过 perf 抓取 on-cpu火焰图，咱们就能够看到咱们服务所有处于 R 状态的线程都在做内存规整，且缺页异样处理函数为 do_huge_pmd_anonymous_page，阐明以后零碎没有间断 2M 的物理内存，因而触发了间接内存规整，间接内存规整的逻辑是很耗时的，是导致 sys 利用率升高的起因。 ...

环境一共 4 个 TiKV 实例，CPU 数量每个实例 30-40 核不等。 须要特地阐明的是 TiKV 都是机械硬盘，不是 SSD！ 插入数据插入数据量 80000 条左右，只有两个字段。 单线程批量插入 能够看到单线程批量 insert 效率非常低，OPS 只有 100 左右，80000 条记录插入花了差不多 13 分钟。 这个过程中 TiKV 实例的 I/O 比拟缓和。依照 TiKV 的文档，IO Util “个别到 80% - 90% 就须要思考加节点”。 虽说 TiKV 是专门针对 SSD 开发的，但机械硬盘真的就这么不堪吗？俺不甘心，所以试了下多线程批量插入。 多线程批量插入别离尝试了 3 线程、10 线程、50 线程的批量插入，后果喜人： 如上图所示，50 线程的状况下 OPS 间接回升到 2K，80000 条记录的插入工夫缩短到了不到一分钟。 与此同时 IO Util 的使用量： 尽管 IO Util 的值在 80% 左右能够说是到了瓶颈，但线程的减少貌似并没有带来更大的压力晋升。资源耗费的减少体现在了 CPU 上： ...

提到如何动静追踪过程中的零碎调用，置信大家第一工夫都能想到 strace，它的根本用法非常简单，非常适合用来解决 “为什么这个软件无奈在这台机器上运行？” 这类问题。但如果须要分析线上服务 （特地是提早敏感型）的某些零碎调用的提早时，strace 则不那么适合，因为它引入的开销会十分大，从性能剖析巨匠 Brendan Gregg 的测试后果得悉，被 strace 追踪的指标过程的运行速度会升高 100 倍以上，这对生产环境来说将是个劫难。 那么是否有比拟好用的工具用在生产环境上呢？答案是必定的，上面将介绍两款工具的常用命令，不便大家须要时查阅。 Perf家喻户晓，perf 是 Linux 零碎下十分弱小的性能工具，由 Linux 内核开发人员在一直演进和优化。除了能够剖析 PMU (Performance Monitoring Unit) 硬件事件，内核事件等通用性能外，perf 还提供了其余“子模块”，比方 sched 剖析调度器，timechart 依据负载特色可视化零碎行为，c2c 剖析可能存在的 false sharing （RedHat 在大量 Linux 的利用上，测试过这套 c2c 的开发原型，胜利地发现了很多热点的伪共享缓存行问题。）等, 而 trace 则可用于剖析零碎调用，其性能十分弱小，并保障了能够承受的开销—— 运行速度仅加快 1.36 倍(dd 作为测试负载) 。咱们一起看下几个罕用的场景： 调用 syscall 数量的 top 排行榜 perf top -F 49 -e raw_syscalls:sys_enter --sort comm,dso --show-nr-samples 从输入能够看到在采样期间，kube-apiserver 的调用 syscall 的次数最多。 显示超过肯定提早的零碎调用信息 perf trace --duration 200 ...

在 “所有皆可编程、万物皆要互联” 的数字时代，数据成为最重要的生产因素。作为企业 IT 基础架构外围的数据库，应该具备什么样的能力？ TiDB 是一款开源 NewSQL 数据库，实现一键程度伸缩，强一致性的多正本数据安全、分布式事务、实时 OLAP 等重要个性。与传统数据库相比，TiDB 既反对分布式 ACID 事务，具备高并发、高可用、弹性伸缩个性，并可同时解决 OLTP 和 OLAP 业务。目前，TiDB 曾经被寰球近 1000 家行业头部企业应用在生产环境。TiDB 性能比赛是由 TiDB 社区主办，专属于寰球开发者与技术爱好者的顶级挑战赛事。数据库的性能调优始终被誉为“皇冠上的明珠”，是该畛域最高技术水平的代表。本届赛事在赛题设计方面融入前沿的技术与利用方向，激励更多的开发者基于 TiDB 社区进行数据库产品与利用的翻新。在这个秋季，让咱们一起激发有限可能，攀登荣誉巅峰！ 大赛日程报名组队（9月17日 - 11月15日）实现工作与提交成绩（9月17日 - 11月15日）组委会成绩评估（11月15日 - 11月20日）现场问难（11月21日）参赛对象大赛面向寰球凋谢，企业员工、高校师生、科研单位人员及有志于翻新的开发者集体，均能够组队报名加入，尤其欢送具备以下技能的参赛者： 相熟 Rust、Go 语言，理解分布式系统的基本原理，在数据库事务、缓存治理、数据减速算法等方面具备开发教训。理解 TiDB 设计与实现，相熟 sysbench、TPC-C 等数据库性能基准测试工具。 如何参赛本次比赛提供两种类型的参题：“围绕固定 workload 优化” 与 “性能优化高难度 issue”，选手能够抉择一个优化题目组队参赛。较量最终以优化成绩（性能晋升百分比）、小组 PR 总分（胜利提交对应比赛 PR 即获积分）和现场问难完成度进行排名。具体参赛细则请点击【文末链接】查看。 大赛奖项一等奖（一名）：团队奖金 5 万元 + 参谋集体奖金 1 万元二等奖（两名）：团队奖金 3 万元 + 参谋集体奖金 1 万元三等奖（两名）：团队奖金 1 万元✨ 所有完赛选手都将取得大赛专属纪念品、TiDB 限量周边等福利哦~ ...

8 月 31 日 - 9 月 4 日，第 46 届 VLDB 会议以线上直播的形式举办（原定于日本东京召开），PingCAP 团队的论文《TiDB: A Raft-based HTAP Database 》入选 VLDB 2020 ，成为业界第一篇 Real-time HTAP 分布式数据库工业实现的论文。PingCAP 联结创始人、CTO 黄东旭获邀在会上进行演讲，分享对于论文的深度解读及在线答疑。 VLDB（International Conference on Very Large Databases）是数据库畛域顶尖的三大学术会议之一，于 1975 年在美国成立，由非盈利性机构 VLDB 基金会资助和经营，以在寰球遍及数据库技术钻研和交换作为使命。 在本篇论文中，PingCAP 重点介绍了其研发的 TiDB 作为一款定位于在线事务处理和在线实时剖析（HTAP）混合负载交融型分布式数据库产品的零碎架构和外围个性。TiDB 受 Google 公布的 Spanner / F1 论文 ，以及 2014 年 Stanford 工业级分布式一致性协定算法 Raft 论文的启发。通过 5 年多的产品研发、生产环境上线验证，获得了一系列成绩，此次被 VLDB 2020 收录也是对学术界的反哺。 HTAP（Hybrid Transactional  / Analytical Processing） 是近些年为数据库界所关注的钻研方向。HTAP 数据库须要可能同时兼具解决交易以及剖析两种作业的能力，这使得交易数据可能被实时剖析，大大缩短决策的周期，同时大幅简化平台架构。 ...

作者：韦万 TiDB 是一款分布式 HTAP 数据库，它目前有两种存储节点，别离是 TiKV 和 TiFlash。TiKV 采纳了行式存储，更适宜 TP 类型的业务；而 TiFlash 采纳列式存储，善于 AP 类型的业务。TiFlash 通过 raft 协定从 TiKV 节点实时同步数据，领有毫秒级别的提早，以及十分优良的数据分析性能。它反对实时同步 TiKV 的数据更新，以及反对在线 DDL。咱们把 TiFlash 作为 Raft Learner 交融进 TiDB 的 raft 体系，将两种节点整合在一个数据库集群中，下层对立通过 TiDB 节点查问，使得 TiDB 成为一款真正的 HTAP 数据库。 为了在列式存储上反对实时更新，咱们专门为 TiFlash 研发了新的列存引擎 Delta Tree。它能够在反对高 TPS 写入的同时，依然能保持良好的读性能。本文为大家具体解释 Delta Tree 的设计思路，欢送探讨。 整体架构Delta Tree 的架构设计充沛参考了 B+ Tree 和 LSM Tree 的设计思维。从整体上看，Delta Tree 将表数据依照主键进行 range 分区，切分后的数据块称为 Segment；而后 Segment 外部则采纳了相似 LSM Tree 的分层构造。分区是为了缩小每个区的数据量，升高复杂度，咱们前面会看到这个设计带来的微小劣势。 ...

作者介绍：许超，VIPKID 资深 DBA 工程师。本文次要分享 TiDB 4.0 版本在 VIPKID 的一个利用实际。次要波及两个局部，第一局部是当初 TiDB 在 VIPKID 的一些利用场景，第二局部是介绍一下 TiDB 4.0 给咱们带来哪些惊喜和收益。 TiDB 在 VIPKID 的利用场景首先简略介绍一下 VIPKID，VIPKID 是一家在线少儿英语教育公司，专一于服务 4-15 岁的青少儿和他们家长们，次要提供北美外教一对一授课服务，目前曾经有超过 70 万的付费用户。 场景一：大数据量及高并发写入回归主题， TiDB 在 VIPKID 的第一个利用场景是一些大数据量和高并发写入的场景，如下图所示： 举其中一个例子，咱们当初有一套教室排障的零碎，这套零碎会实时收集教室内的一些事件信息，比方进出教室还有教室内服务初始化的信息，这些信息是通过家长端还有老师端对立上报的，业务同学能够依据这些信息疾速定位到教室内的故障，并且做一些排障伎俩，比如说切换线路之类的来保障一些上课品质。 这套零碎目前 TPS 峰值在 1 万左右，每天的新增数据量大略有 1800 万，这张表只保留最近两个月的数据，目前单表有 12 亿左右，数据量其实相对来说曾经比拟大了，这种数据量如果当初放在 MySQL 里保护老本比拟高，所以咱们把这套零碎的数据整个迁徙到 TiDB。 在迁徙过程咱们做了一些小的变动，在原有表的根底上把原来的自增 ID 去掉了，在建表的时候通过指定配置做一下事后打散，防止高写入量的时候呈现写热点问题。对于热点定位，其实 TiDB 自身之前就提供了很多形式了，比方 3.0 版本其实通 information_schema.TIDB_HOT_REGIONS 这张表就能够定位，或者间接能够在 PD 里获取相应的热点 Region 信息，然而通过这种形式拿到的其实只是一个 Region ID，还须要调用具体的 TiDB server 的 API 来获取定位到具体的表或者索引。在 4.0 里，TiDB Dashboard 让热点直观地出现在咱们背后，咱们能够间接看到热点写入量、读取量等等热点信息。 ...