TiDB

2020 开年的一场疫情，打得我们措手不及，往年一直幻想着可以有一个不用开学的假期，现在开学也变得遥遥无期，原本准备的暑期实习也因为不能到现场，一个个泡汤。这个暑假，还能做点什么才不虚度光阴？ 不如了解一下“远程实习”——面向在校大学生的 Talent Challenge Program。 Talent Challenge Program 是 PingCAP 联合 TiDB 开源社区共同推出的远程实习项目，也是 Talent Plan 原有线下实训的全新升级。按照往年的计划，学完线上课程的同学会被邀请到 PingCAP 的 Office 参加为期 1 个月的线下项目实践，组队完成 TiDB 生态项目；项目实践表现优秀的会直接发放实习或校招的 offer，或者推荐给合作企业。线下实训成功举办了 4 期，不过这中间也有不少同学给出反馈建议，比如：参与线下实训门槛太高；实训时长太短，希望能够更加系统完整地跟进一个项目；线下 1 个月集中待在一个城市，机动型比较差，有时候偶尔学校或者家里有事情不方便处理等等。 同时出于疫情期间同学们的安全考虑，我们暂时放弃了线下实践课程，思考如何通过线上的方式把大家组织起来，帮助大家学习成长。因此，我们面向 TiDB 开源社区进行了为期 2 周的项目征集，共有 14 个基于 TiDB 生态的开源项目入选（详见 Selected Projects in

2019 年底，TUG 联合 TiDB 开发者社区举办了“ 我的 TiDB 听我的 ”活动，旨在听取来自 TiDB 使用者的真实呼声，并将收集到的宝贵需求融入到 TiDB 的灵魂和设计中，帮助 TiDB 更好地迭代，以更透明的方式进行版本发布。 “ 我的 TiDB 听我的 ”活动开始后受到了 TUG 成员的广泛关注，大家积极留言，累计收到关于 DDL、分区表、性能优化、KV、PD 等方面的近 40 个需求。这些建议非常务实，并且为 TiDB 4.0 的性能和易用性大幅提升做出了巨大贡献。 TiDB 4.0 GA 版本将于 6 月初发布，正是这些广泛而务实的社区需求，帮助 TiDB 更快成长、更受欢迎。 TiDB 4.0 GA 发布在即，而 TiDB 5.0 的设计已然开启。相约依旧，我们期待大家来一吐为快。正是因为您的真实反馈和吐槽，督促我们不断向前。“我的 TiDB 听我的”第二季已经拉开序幕。 活动时间 2020 年 5 月 23 日 ~ 6 月 7 日 活动内容 第一阶段：需求收集 需求收集时间：2020 年 5 月 23 ~ 30 日** 进入 TiDB 用户论坛 asktug.com 上的活动贴 ，并在活动贴里留下您对 TiDB 5.0 的需求，可以是新功能，也可以是一些小的功能或者易用性改进，比如优化某某 error message 或者 log 内容等，欢迎您畅所欲言

近日， PingCAP 与知乎达成战略合作，将从产品与技术、社区与内容以及人才培养等方面展开长期深入的战略合作，双方将充分发挥和共享各自优势，共同推动知乎全场景体验优化以及 TiDB 社区用户生态的发展。 图左：PingCAP 联合创始人、CTO 黄东旭 图右：知乎合伙人、CTO 李大海 知乎从问答起步，目前已经成长为一个综合性知识内容平台，聚集了中文互联网科技、商业、影视、时尚、文化等领域最具创造力的人群。截至 2019 年 1 月，知乎已拥有超过 2.2 亿用户，共产出 1.3 亿个回答。同时还沉淀了数量众多的优质专栏、电子书以及其他付费内容。这些万亿量级的业务数据对知乎的数据中心，尤其对实时、可靠且高效的存储和查询已读数据存在着诸多挑战。 知乎与 PingCAP 结缘已早，知乎内部一直以来都鼓励拥抱开源，并基于大量开源组件搭建了知乎的技术架构，这与 PingCAP 所坚持的开源文化不谋而合。早在 2018 年，知乎内部工程师就曾以个人用户身份为 TiKV & TiDB 社区做过重要贡献，并最终成为 TiKV 项目的 Maintainer 之一。2019 年，知乎和 PingCAP 首次联合开发 Follower Read 功能，知乎在首页个性化内容推荐的核心场景采用 TiDB 来承载海量用户的并发访问与个性化内容推荐。 2020 年，随着 TiDB 4.0 GA，知乎与

使用阿里云rds for MySQL数据库（就是MySQL5.6版本），有个用户上网记录表6个月的数据量近2000万，保留最近一年的数据量达到4000万，查询速度极慢，日常卡死。严重影响业务。 问题前提：老系统，当时设计系统的人大概是大学没毕业，表设计和sql语句写的不仅仅是垃圾，简直无法直视。原开发人员都已离职，到我来维护，这就是传说中的维护不了就跑路，然后我就是掉坑的那个！！！ 我尝试解决该问题，so，有个这个日志。 方案概述 方案一：优化现有mysql数据库。优点：不影响现有业务，源程序不需要修改代码，成本最低。缺点：有优化瓶颈，数据量过亿就玩完了。 方案二：升级数据库类型，换一种100%兼容mysql的数据库。优点：不影响现有业务，源程序不需要修改代码，你几乎不需要做任何操作就能提升数据库性能，缺点：多花钱 方案三：一步到位，大数据解决方案，更换newsql/nosql数据库。优点：扩展性强，成本低，没有数据容量瓶颈，缺点：需要修改源程序代码 以上三种方案，按顺序使用即可，数据量在亿级别一下的没必要换nosql，开发成本太高。三种方案我都试了一遍，而且都形成了落地解决方案。该过程心中慰问跑路的那几个开发者一万遍 :) 方案一详细说明：优化现有mysql数据库 跟阿里云数据库大佬电话沟通 and Google解决方案 and 问群里大佬，总结如下（都是精华）： 1

JEPaaS是一款优秀的软件平台产品，可视化开发环境，低代码拖拽式配置开发，操作极其简单，可以帮助解决Java项目80%的重复工作，让开发更多关注业务逻辑，大大提高开发效率，能帮助公司大幅节省人力成本和时间成本，同时又不失灵活性。适用于搭建 OA、ERP、CRM、HR、HIS等所有的企业信息管理系统（且适用于集团公司部署）。 一、概要介绍 支持TIDB数据库，提供了大型关系型数据库通用功能。 二、操作页面一 三、操作页面二 四、操作页面三 五、操作页面四 来源： oschina 链接： https://my.oschina.net/jepaas/blog/4459573

作者：邹建伟，北京开科唯识技术有限公司 技术专家。 一、互联网理财的兴起 在经济和科技飞速发展的趋势下，相比于以前传统的线下理财模式，互联网理财的模式，因其入围门槛相对较低，选择范围广，加上随时随地用电脑或者手机就能够进行理财，导致便捷性和灵活性的提升，从而让越来越的人们开始接受理财、乐于理财，理财的意识和投入的形态也越来越多。但随着监管制度的管控、用户规模、渠道规模、业务形态、高并发业务请求的不断增长和变化，传统的理财 IT 基础设施建设已经无法满足用户的使用体验，基于分布式系统建设新的业务系统必将破浪前行。 这次我们在中国某大型股份制银行—— G 行的互联网理财系统建设中，也是采用了分布式的数据库系统来取代传统 Oracle 数据库系统，在使用分布式数据库 TiDB 时，遇到了新技术适配的一些问题，通过迁移、开发改造和联调优化，积累了互联网理财场景中的一些分布式数据库 TiDB 的经验。本篇文章分享下在建设中遇到的问题和最终的解决方案，希望对所有准备建设和正在建设互联网理财系统的的用户有所帮助。 二、互联网理财业务简介 互联网理财最早于 2003 年就已经开展业务，主要承载基金代销、理财销售等线上业务，2018 年 4 月随着“资管新规”的发布，银行理财产品起售点由 5 万下调至 1 万，大大促进了银行资管理财业务的发展，更加激发了客户购买理财产品的热情，部分明星热销产品

作者介绍：王志刚，光大银行数据库运维主管。 大家好，我是来自中国光大银行信息科技部的王志刚，非常高兴有机会给大家分享一些分布式数据库在光大银行的应用探索。我目前在光大银行银行信息科技部负责数据库管理团队，在加入光大银行之前在三星、索尼爱立信，还有 Oracle 工作过，一直在负责数据库相关的工作。在近十年我和我的团队一直负责光大银行总行的数据库运维，这里面既包括我们的交易型数据库，也包括 MPP，还有 Hadoop 这样的大数据运维。在运维的过程中，我们一直也在思考现在的数据库有哪些问题、面临哪些风险、数据库技术的发展趋势是什么，这一点是很重要的，因为它决定了我们为什么要转向分布式，我们希望分布式能替我们解决哪些问题，它能够解决哪些问题和它不能够解决哪些问题。 我们现在运维的数据库包括商业数据库，像 Oracle、SQL Server、DB2；也有开源数据库，像关系型的 MySQL、NoSQL 数据库、Redis（KV 型），还有大数据、MPP，和分布式数据库等等。 目前运维的数据库面临哪些挑战？ 以我们的观点去看现在银行数据库面临哪些挑战呢？我们认为有下面几点。 1. 处理能力受限 很多人都认为我们现在处理能力受限，但是数据库能力受限到底瓶颈在哪里？在我们看来在高的业务压力下瓶颈主要有两点： 一是集中式存储资源的压力 。我们可以用最高端的存储，用最好的设备，但他终究是一个单点

自 4.0 RC（Release Candidate）版本发布以来，大家已经迫不及待开始抢先体验。TiDB 4.0 包含了很多重要的、有潜力的特性： TiUP 帮你更快地部署集群。 TiFlash 兼顾了 OLTP 和 OLAP。 内置 DashBoard 大幅提高可用性。 BR 和 TiCDC 补齐了快速备份和增量数据变化的能力。 …… 为了鼓励大家抢先体验 TiDB 4.0，加速 TiDB 4.0 正式版发版，捉虫竞赛应运而生。如今赛程过半，我们一起来回顾下当前赛况。 国际友人开挂一枝独秀 捉虫大赛刚一公布，来自瑞士的 Mrigger 就火线加入，提交了多个 bug。强调下 Mrigger 肯定不是“托儿”。在 Mrigger 一波提交之后，有开发同学向 TiDB Robot 诉苦，「来者何人啊？周边礼品有点兜不住了！」。不查不知道，一查吓一跳，Mrigger 就是一位专业“碰瓷”选手。他已经为 SQLite 提交了超过 170+ bug，为 CockRoachDB 提交了 50+ bug。这位苏黎世理工大学的博士后研究方向是 RDBMS 的自动化测试，找 Bug 也是事半功倍。真可谓「天不怕地不怕，就怕测试开外挂」。 截止到发稿日，Mrigger 已经提交了 21 个 P1 bug，7 个 P2 bug，稳坐第一名的宝座。 开发者社区 护场子奋起直追 在国际友人“砸场子

今天想使用Tidb官方提供的mydumper来备份AWS上的RDS集群中mysql数据库的某个表，发现报错了 [tidb@:xxx /usr/local/tidb-tools]$ sudo bin/mydumper -h xxx -u xxx -p xxx -P 3306 -t 4 -F 64 -B xxx -T xxx -o /data/test1/ ** (mydumper: 1908 ): CRITICAL **: Couldn ' t acquire global lock, snapshots will not be consistent: Access denied for user ' super ' @ ' % ' (using password: YES) 上网查了一下说是权限问题： 比如上面这位博主说的，mysql用户没有RELOAD权限，我查看了一下我这个用户。发现是有RELOAD权限的。 后来求助于tidb官方，官方给了这样的一个链接：https://stackoverflow.com/questions/20638012/backup-mysql-amazon-rds 发现也没有解决，后来就自己从mydumper官网下载一个源文件0.6.2版本的，并编译了mydumper二进制文件，成功了。 安装mydumper的步骤我的另外一个博客上写的有，可以参考一下

【合集】TiDB 源码阅读系列文章 （一）序 （二）初识 TiDB 源码 （三）SQL 的一生 （四）INSERT 语句概览 （五）TiDB SQL Parser 的实现 （六）Select 语句概览 （七）基于规则的优化 （八）基于代价的优化 （九）Hash Join （十）Chunk 和执行框架简介 （十一）Index Lookup Join （十二）统计信息（上） （十三）索引范围计算简介 （十四）统计信息（下） （十五） Sort Merge Join （十六）INSERT 语句详解 （十七）DDL 源码解析 （十八） tikv-client（上） （十九）tikv-client（下） （二十）Table Partition * 未完待续 * 由于微信推送的修改限制，以上文章内容以官网博客为准：https://pingcap.com/blog-cn/ TiDB 源码地址：https://github.com/pingcap/ 技术文档（中文）：https://pingcap.com/docs-cn/ 技术咨询可以发送邮件到 info@pingcap.com ，或扫描下方二维码，添加 TiDB Robot 为好友，有任何问题都可以问 ta 哦～ 来源： oschina 链接： https://my.oschina.net/u/4285580/blog/3689566