TiDB

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者：殷成文 2019 年 12 月 31 日，我们在 GitHub 上正式开源了 Chaos Mesh。作为一个云原生的混沌测试平台，Chaos Mesh 提供在 Kubernetes 平台上进行混沌测试的能力。本篇文章将围绕 Chaos Mesh 起源及原理等方面进行介绍，并结合具体案例带领大家一起探索混沌测试的世界。 现实世界中，各类故障可能会随时随地的发生，其中有很多故障我们无法避免，例如磁盘突然写坏，或者机房突然断网断电等等。这些故障可能会给公司造成巨大损失，因此提升系统对于故障的容忍度成为很多工程师努力的目标。 为了更方便地验证系统对于各种故障的容忍能力，Netflix 创造了一只名为 Chaos 的猴子，并且将它放到 AWS 云上，用于向基础设施以及业务系统中注入各类故障类型。这只 “猴子” 就是混沌工程起源。 在 PingCAP 我们也面临同样的问题，所以在很早的时候就开始探索混沌工程，并逐渐在公司内部实践落地。 在最初的实践中我们为 TiDB 定制了一套自动化测试平台，在平台中我们可以自己定义测试场景，并支持模拟各类错误情况。但是由于 TiDB 生态的不断成熟，各类周边工具 TiDB Binlog 、 TiDB Data Migration 、 TiDB Lightning 等的出现

GopherChina第一天小结 今天参加了Asta举办的第五届GopherChina，第一天参加完，颇有感受，晚上回来趁着还有记忆，来做一下记录。 写在前面 一早从9点开始，一天下来一共八个主题，各个主题都有自己的特色，全部听下来也是挺不容易的。这些主题有大到说框架，也有小到说具体的某个包的使用的。 一早上真心起的比上班还早，早早就过去占了个位子。之前也参加过一些技术大会，最担心的就是讲师讲说的主题变成某个公司的宣传分享。我们听众大都怀着学习的心态来的，都希望能在技术大会上得到的是一些干货，所谓干货，就是经验。就是说并不是你用Golang做了多牛逼的事情，而是你怎么用Golang做了多牛逼的事情，在做了多牛逼的事情的过程中有哪些经验只谈，哪怕只有一个经验分享，能让我们在实际工作中绕开这个坑，也或许就值回票价了。 大型微服务框架设计实践 这个是我司滴滴欢总的分享。其实之前我在内部已经听过一遍这个分享了，当时听完之后就对这个在我们外卖部门践行下来的微服务框架的思想、实现都非常感兴趣。还强烈建议其他公司的小伙伴一定要仔细听欢总这个分享。今天第二次听，PPT已经较之前内部分享的润色不少，也做了一些公司业务的脱敏处理。不过整体听完，让我对业务框架的认识又深了一层。 整个PPT大致是从框架开始说起，从框架的进化史，说到框架的风格（从配置->约定->DSL->容器化），从而引入“操作系统

行业背景 随着全球经济下行压力增大，中美贸易摩擦愈演愈烈，美国一系列的经济制裁和技术封锁使得我们有种被扼住咽喉的感觉，数据库作为基础软件中的重要一环有着很深的技术含量，在这样的大背景下国产数据库厂商开始发力，这其中分布式数据库如雨后春笋般出现，良性的竞争环境使它们都得到了长足的发展，其中不乏优秀的产品，本文主要挑选目前几个相对成熟数据库进行架构特点介绍。 分布式数据库总体架构 其实分布式数据库总体设计有两个思路和方向，一个是基于共享存储的架构（share everything），另一个是基于数据分片的架构（share nothing）。 共享存储的架构特点是底层存储共用一份数据池子，上层数据库server层可以弹性扩展，典型的案例像DB2 purescale，Oracle RAC，阿里云PolarDB等，这种架构的好处是天然适合做云数据库，比如阿里云，上层的sql引擎可以是mysql也可以是pg，而且可以无限扩展，底层的存储其实是一起的，用户申请只是申请几个上层的mysql或者pg server同时在底层存储开辟一块空间给用户，这样的话可以做到资源的弹性伸缩。这种架构的数据库其实严格意义上不能称之为分布式数据库。 数据分片架构的特点是底层数据通过一定的规则比如hash或者range让数据打散分别分布到不同的数据节点上，计算时底层多个节点共同参与计算，可以算是一种mpp并行计算的架构

作者介绍：吕磊，Better 队成员、美团点评高级 DBA，Better 队参加了 TiDB Hackathon 2019，其项目「基于 TiDB Binlog 的 Fast-PITR」获得了最佳贡献奖。 维护过数据库的同学应该都能体会，数据备份对于数据库来说可以说至关重要，尤其是关键业务。TiDB 原生的备份恢复方案已经在多家客户得到稳定运行的验证，但是对于业务量巨大的系统存在如下几个痛点: 集群中数据量很大的情况下，很难频繁做全量备份。 传统 TiDB Binlog 原样吐出 binlog 增量备份会消耗大量的磁盘空间，并且重放大量 binlog 需要较长时间。 binlog 本身是有向前依赖关系的，任何一个时间点的 binlog 丢失，都会导致后面的数据无法自动恢复。 调大 TiDB gc_life_time 保存更多版本的快照数据，一方面保存时间不能无限长，另一方面过多的版本会影响性能且占用集群空间。 图 1 原生 binlog 备份恢复 我们在线上使用 TiDB 已经超过 2 年，从 1.0 RC 版本到 1.0 正式版、2.0、2.1 以及现在的 3.0，我们能感受到 TiDB 的飞速进步和性能提升，但备份恢复的这些痛点，是我们 TiDB 在关键业务中推广的一个掣肘因素。于是，我们选择了这个题目: 基于 TiDB Binlog 的 Fast-PITR (Fast

TiDB 是 PingCAP 公司研发的开源分布式关系型数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，具备「分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活」等核心特性，是大数据时代理想的数据库集群和云数据库解决方案。 UCloud 于今年 8 月 将 TiDB 公有云化并推出 UCloud TiDB Service，当前使用的 TiDB 版本为 3.0.5 。UCloud TiDB Service 相比裸机部署性能并无损耗，提供跨可用区高可用，对监控和 Binlog 等做了改造增强，使用户可获得一键创建、按需付费、灵活扩缩容的 TiDB 服务。 UCloud TiDB Service 为什么叫 UCloud TiDB Service？这里强调 Service 是因为从公有云用户的角度来看，TiDB 运行在公有云平台上，其实是以服务的形式呈现而不是一个物理资源。 UCloud TiDB Service 是一个支持原生 MySQL 协议的，高性能、跨可用区高可用、高可扩展的，面向 Serverless 的分布式数据库服务。 兼容原生 MySQL 协议 大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。 跨可用区高可用 TiDB

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者：黄东旭 经常思考一个问题，为什么我们需要分布式？很大程度或许是不得已而为之。如果摩尔定律不会失效，如果通过低成本的硬件就能解决互联网日益增长的计算存储需求，是不是我们也就不需要分布式了。 过去的二三十年，是一场软件工程师们自我拯救的，浩浩荡荡的革命。分布式技术的发展，深刻地改变了我们编程的模式，改变了我们思考软件的模式。通过随处可见的 X86 或者 Arm 机器，构建出一个无限扩展的计算以及存储能力，这是软件工程师最浪漫的自我救赎。 值 2019 年末，PingCAP 联合 InfoQ 共同策划出品“分布式系统前沿技术”专题， 邀请转转、Pulsar、微众银行、UCloud、知乎、贝壳金服等技术团队共同参与，从数据库、硬件、测试、运维等角度，共同探索这个古老领域的新生机。 无论哪个时代，存储都是一个重要的话题，今天先聊聊数据库。在过去的几年，数据库技术上出现了几个很明显的趋势。 存储和计算进一步分离 我印象中最早的存储-计算分离的尝试是 Snowflake，Snowflake 团队在 2016 年发表的论文 《The Snowflake Elastic Data Warehouse》 是近几年我读过的最好的大数据相关论文之一，尤其推荐阅读。Snowflake 的架构关键点是在无状态的计算节点 +

公司采用mysql,mongodb,es,redis等数据库和NoSQL产品,需要集中所有数据到中间库TiDB,为以后数据仓库抽取数据做好准备. 在TiDB官网下载mydumper软件, https://github.com/maxbube/mydumper 解压后,按照官方文档 cmake . ,然后 make ,最后 make install centos 7.6版本,TiDB mydumper 0.10.0, built against MySQL 5.5.64-MariaDB 版本下,会出现下面问题: CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:363 (message): None of the required ‘glib-2.0’ found 根据官网记载,安装下面组件则可以解决该问题. Fedora, RedHat and CentOS: yum install glib2-devel mysql-devel zlib-devel pcre-devel openssl-devel 来源： CSDN 作者： jacobxian 链接： https://blog.csdn.net/jacobxian/article/details/103712806

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> tidb默认变量 SHOW GLOBAL VARIABLES like '%mem_quota%' # 查看内存使用阈值 set @@tidb_mem_quota_query = 8 << 30; -- 配置整条SQL的内存使用阈值为8GB SELECT @@tidb_mem_quota_query -- 查看当前变量 慢sql show variables like 'tidb_slow_query_file'; # 查看慢sql文件位置 admin show slow recent 10; # 查看最近10条慢sql admin show slow top 3; -- 最慢的查询记录 admin show slow top all 5; -- 包含内部SQL的慢查询记录 select query_time, query from information_schema.slow_query where is_internal = false -- 排除 TiDB 内部的慢查询 SQL order by query_time desc limit 5; # 搜索排名前5的慢SQL select query_time, query, user from information_schema.slow_query

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者介绍：陈霜，做个人吧队成员，PingCAP TiDB 研发工程师，做个人吧队参加了 TiDB Hackathon 2019，其项目「Manage many as one with SQL」获得了三等奖。 极致的易用性一直是 PingCAP 追寻的目标。在这之前，TiDB 通过兼容 MySQL，将分布式的复杂度隐藏在 TiDB 之后，将用户从复杂的分库分表方案中解脱出来，使用户可以像使用单机数据库一样使用 TiDB。 不过兼容 MySQL 只是易用性的第一步，这一步主要提升了开发人员的体验。但是对于 DBA 来说，运维一个分布式系统的难度还是不低。那么分布式数据库的运维目前到底面临哪些难题？大致有以下几个方面： 各组件状态信息分散。 运维操作需要跨节点。 运维脚本重复编写，无法标准化。 在 TiDB Hackathon 2019 之后，以上问题我们给出了一个统一的答案：用 SQL 管理整个 TiDB 集群。 用 SQL 查询集群信息 <center>图 1 查询集群系统信息</center> 在上面的示例中，我们通过 SQL 获得集群以下信息： 所有节点的拓扑信息，版本信息。 所有节点的配置信息。 所有节点当前正在处理的请求，即 processlist。 所有节点的慢查询信息。 所有节点的服务器硬件信息。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者介绍：吕磊，Better 队成员、美团点评高级 DBA，Better 队参加了 TiDB Hackathon 2019，其项目「基于 TiDB Binlog 的 Fast-PITR」获得了最佳贡献奖。 维护过数据库的同学应该都能体会，数据备份对于数据库来说可以说至关重要，尤其是关键业务。TiDB 原生的备份恢复方案已经在多家客户得到稳定运行的验证，但是对于业务量巨大的系统存在如下几个痛点: 集群中数据量很大的情况下，很难频繁做全量备份。 传统 TiDB Binlog 原样吐出 binlog 增量备份会消耗大量的磁盘空间，并且重放大量 binlog 需要较长时间。 binlog 本身是有向前依赖关系的，任何一个时间点的 binlog 丢失，都会导致后面的数据无法自动恢复。 调大 TiDB gc_life_time 保存更多版本的快照数据，一方面保存时间不能无限长，另一方面过多的版本会影响性能且占用集群空间。 <center>图 1 原生 binlog 备份恢复</center> 我们在线上使用 TiDB 已经超过 2 年，从 1.0 RC 版本到 1.0 正式版、2.0、2.1 以及现在的 3.0，我们能感受到 TiDB 的飞速进步和性能提升，但备份恢复的这些痛点，是我们 TiDB